Many important tasks do not fail while someone is actively working on them. They fail in the gaps.
A supplier has not replied yet. A report depends on numbers that arrive tomorrow. A browser session is open on one computer, while the person who can approve the next step is in another time zone. By the time the dependency clears, the original conversation is buried and nobody remembers exactly where the work stopped.
An always-on personal agent should be good at those gaps. It does not need to think continuously or keep a computer running at full power. It needs to preserve responsibility: what outcome it accepted, what has already been done, what it is waiting for, where the working materials live, and what event or decision allows the task to continue.
That is the difference between a long chat and long-term work. A long chat stores messages. Long-term work requires a durable operating state.
Long-term work needs a durable Task, not a longer chat
A conversation is useful for establishing intent. It is a poor unit of ownership.
Suppose you ask an agent to prepare a board update after finance closes the month. The useful state is not just your initial request. It includes the draft already assembled, the source documents checked, the missing figures, the person or system expected to provide them, the deadline for the meeting, and the standard the final update must meet.
In Comma, work that requires more than a quick answer becomes a Task. According to the Comma Tasks documentation, the Task can move through active work, wait in Needs Review when a human decision is required, and reach Done when the work is complete. The important idea is not the label itself. It is that the responsibility survives after the chat is no longer open.
A durable Task should always be able to answer six questions:
| Question | State that should survive |
|---|---|
| What are we trying to achieve? | The outcome, completion standard, deadline and constraints |
| What has happened? | Completed steps, material findings and relevant decisions |
| What exists now? | Drafts, files, links, tool output and other evidence |
| Why are we not continuing? | The dependency, blocker or decision currently holding the work |
| Where can the work continue? | The app, cloud computer, connected device or external runtime that has the required context |
| What resumes it? | A time, event, approval, device state or other explicit condition |
Without those answers, “I’ll continue later” is optimism. With them, it becomes a plan.
Waiting is a state, not a failure
Most useful work includes legitimate waiting. The mistake is to treat every pause as either an error or an invitation to keep polling forever.
An agent should identify what kind of wait it has entered and attach a clear exit condition:
| Type of wait | Example | Resume condition |
|---|---|---|
| Time-bound | Month-end numbers publish tomorrow | A scheduled checkpoint is reached |
| Event-bound | A customer replies with requested details | The relevant event arrives |
| Environment-bound | A file is available only on an offline Mac | The designated device becomes available |
| Decision-bound | Two acceptable plans have different trade-offs | The user chooses or approves one |
These distinctions matter because each wait calls for different behavior. A time-bound task can sleep until its checkpoint. An event-bound task can watch for a narrowly defined change. An environment-bound task should say which device or tool is unavailable rather than silently attempting the work elsewhere. A decision-bound task should return a well-framed choice to the person who owns it.
The pause should also have a bound. If the expected reply never arrives, the agent needs a fallback: remind the responsible person, ask the user whether to proceed with assumptions, or close the Task as blocked. Otherwise a background responsibility can remain technically open while becoming practically abandoned.
This is also why always-on should not mean always interrupting. The separate question of which events justify waking the agent—and which of those justify interrupting the user—is covered in When Should an Always-On Personal Agent Wake Up?. Here, the relevant principle is narrower: every pause needs an observable reason and a defined path back to work.
Resume from a checkpoint, not from a new briefing
When the wait ends, the agent should not reconstruct the assignment from scattered messages or ask the user to explain it again. It should resume from a checkpoint.
A useful checkpoint is a compact record of the working situation:
the original outcome and current completion standard;
the last meaningful action and its result;
the artifacts already created or changed;
the assumptions still in force;
the blocker that caused the pause;
the next intended action once that blocker clears;
the environment in which that action must occur.
This is working state, not personal memory. Memory may help an agent remember a person's preferences over many tasks. A checkpoint exists so one specific responsibility can continue accurately after idle time, a restart or a handoff.
The distinction prevents two common failures. First, the agent should not drag every detail from a long conversation into every future step. Second, it should not compress the task so aggressively that a critical constraint disappears. The checkpoint is selective: it preserves what the next action depends on.
Comma's underlying system reflects this pattern at more than one level. Salix Loops can checkpoint their state so a bounded background process can resume after a restart. That infrastructure is not a substitute for a well-defined Task, but it illustrates the same continuity rule: recovery should begin from known state rather than from guesswork.
Keep the work in the environment it actually needs
Long-term work rarely happens in an abstract “AI workspace.” It happens in email, documents, project tools, browsers, local files and specialist software. Continuity therefore includes the location of the work.
Comma can work across connected apps and files, a person's computer, or its own cloud computer. The Salix documentation explains that the cloud computer's storage persists between uses even though the virtual machine can sleep when it is idle. Files and tools can remain where the agent left them, and the computer can wake again when the Task needs it.
Some work must remain on a particular device. A local design file, authenticated desktop application or development environment may exist only on an attached Mac or Linux computer. Comma's agent runtime documentation is explicit about the boundary: if the designated external device is offline, the work waits or fails; Salix does not silently move it to another machine.
That limitation is a useful trust property. Automatic migration might appear convenient, but it can change available files, permissions, credentials and execution conditions. A reliable agent should make the boundary visible:
The next step needs the Mac named “Studio.” It is offline. The Task is waiting there; no work has been moved to the cloud computer.
The user now knows both why progress stopped and what will unblock it. The agent can retry when the device returns or ask whether an alternative environment is acceptable. It should not pretend that every runtime is interchangeable.
Return only the decision that belongs to the person
Human handoff is not a failure of autonomy. It is how a personal agent preserves the difference between doing work and owning consequences.
The agent should continue routine, reversible steps that fall within the assignment. It should return control when it reaches a material ambiguity, a permission boundary, an irreversible external action, or a choice that depends on the user's preferences rather than available evidence.
The handoff itself should be small. A poor handoff says, “I’m blocked—what should I do?” A useful one contains:
What changed: the new information or condition that ended the previous plan.
What is already complete: the work the agent finished before asking.
What decision remains: one precise choice, not a request to re-manage the whole Task.
What the options change: the meaningful consequence of each path.
When the choice matters: a deadline or the effect of waiting.
What happens next: the action the agent will resume after the answer.
For example: “The venue can hold the date only until Thursday. I verified the cancellation terms and prepared the booking details. Approving now commits the deposit; waiting preserves flexibility but may lose the slot. Should I submit the booking?”
Comma uses Needs Review for work that requires this kind of human decision. The Task stays intact around the question, so an answer can release the next action instead of starting a new planning session.
“Done” needs evidence and closure
A long-running Task is not complete merely because the agent has stopped taking actions. It may have timed out, exhausted a retry policy, produced a draft that still needs review, or reached the end of its permissions.
Closure should state:
the outcome requested;
the result actually produced;
the artifacts created or changed;
the checks performed;
any unresolved limitation, assumption or follow-up;
whether an external action was executed or only prepared.
This record lets the user inspect the work without replaying its entire history. It also prevents a dangerous ambiguity between “the Task is no longer running” and “the outcome has been achieved.”
Done is a workflow state, not a certificate of truth. An agent can verify that a file was created, a command succeeded or a message was sent. It cannot turn uncertain source material into certainty by changing a status. Claims still need appropriate evidence, and consequential work may still deserve human review.
A practical protocol for work that spans days
You do not need to design an orchestration system before delegating a multi-day responsibility. A good request can establish the essential contract in a few lines.
Start by naming the outcome and what “good enough” means. Identify the hard deadline and any earlier decision windows. State which actions the agent may take without asking and which ones require approval. Point it to the environment where the source material and working files belong.
Then make waiting explicit. Tell the agent what dependency is expected, when to check again, and what to do if it never arrives. Ask it to preserve a checkpoint before each pause and to return only decisions that genuinely require you. Finally, require a closure note with the output, checks and remaining uncertainty.
A compact delegation might look like this:
Prepare the final board update after finance publishes the month-end figures. Use the existing draft and workbook in the cloud computer. You may update the draft and validate totals, but ask before sending anything externally. If figures have not arrived by Tuesday noon, tell me which sections are blocked and propose the least risky fallback. When complete, return the document, the sources checked and any assumptions that remain.
The value does not come from making the prompt elaborate. It comes from giving the Task clear states to move through: accepted, working, waiting, ready for review, resumed and closed.
Frequently asked questions
What remains active while a long-running Task is waiting?
The Task retains the outcome, completed work, current dependency, checkpoint and condition for resuming. The execution environment can sleep, and no model needs to reason continuously. If a narrowly scoped Loop watches for the missing condition, it remains separate from the durable Task state that tells the agent what to do after the condition arrives.
What happens if the computer a Task needs is offline?
If the Task is assigned to an external runtime on that device, the work waits or fails until the device is available. Salix does not automatically move it to another computer. The Task should make the blocked environment and the recovery condition clear.
Is Task state the same as an agent's memory?
No. Task state describes one responsibility: its outcome, progress, artifacts, blocker and next action. Personal memory can span responsibilities and may include durable preferences. A long-running Task should be resumable without turning every working detail into permanent memory.
How should an agent wait for another person?
It should record what was requested, from whom, when a response becomes late, and what fallback applies. If an event can be monitored, it should watch for that event rather than repeatedly interrupting the user. An indefinite wait with no escalation rule is not a complete plan.
What belongs in Needs Review?
Use it for decisions or permissions that genuinely belong to the user: consequential trade-offs, ambiguous intent, irreversible external actions, sensitive commitments or new authority. The agent should attach its completed work and ask for the smallest decision that unlocks progress.
Does Done mean the result is correct?
Done means the Task has reached its declared completion condition. Confidence still depends on the quality of its sources, checks and review. A useful completion note separates verified facts, assumptions and unresolved risks.
Continuity is the product
The strongest reason to use an always-on personal agent is not that it can perform one uninterrupted marathon of reasoning. It is that it can carry a responsibility through the ordinary discontinuities of real work: sleeping computers, delayed replies, scheduled data, changed conditions and moments when a person must decide.
That continuity is built from visible state. The Task knows what it owes, the wait has a reason, the environment is named, the handoff is bounded, and completion comes with evidence. When those pieces survive the gaps, you can leave the work without abandoning it—and return without rebuilding it from the beginning.
Explore how Comma carries work across Tasks, apps and computers.