Most useful work does not fit into one uninterrupted session. A task waits for an approval, a dependency registry is temporarily unavailable, a preview takes longer than expected, or another person changes the priority. In each case, the agent needs to stop without turning the next attempt into a fresh guess.

This is why recovery is a core property of agent infrastructure, not a convenience feature.

Retrying is not resuming

A retry says, "Run this operation again." Resumption says, "Continue the task from a known state without repeating work that may already have had an effect."

The difference is easy to miss until an agent touches an external system. A request to create a ticket may have succeeded even though the network response was lost. A deployment may be active even though the local process exited. A migration may have completed one step and failed at the next. Blindly repeating these actions can create duplicates, overwrite a correct state, or make recovery more difficult.

Long-running tasks need a durable record of what was attempted, what was observed, and what remains unknown. They need identifiers that can be checked against external systems, actions designed to be idempotent where possible, and explicit pauses where an action cannot safely be repeated.

A pause should be a legible state

There is a large difference between "the agent stopped" and "the task is waiting for review of a deployment preview." The second statement tells a person what happened, what is needed next, and what artifacts to inspect. The first forces them to reconstruct the situation from logs and conversation.

Useful pause states are specific:

• blocked on a missing or expired credential;
• waiting for a named approval with a defined scope;
• paused after a retryable external failure;
• awaiting a dependent task or service;
• ready for review with evidence attached;
• halted because an assumption was invalidated.

The runtime should preserve this state with the task rather than relying on the model to remember it later. When the task resumes, it can refresh the assumptions that may have changed: the branch revision, environment availability, approvals, resource budgets, and the state of any external action.

Durable work requires a recovery plan

Not every task needs a formal runbook. But consequential tasks should be designed with recovery in mind before they begin.

For an engineering change, that may mean using a branch, committing meaningful progress, and recording which checks were run. For an external workflow, it may mean storing an operation identifier, writing a draft before sending, or making the final action require approval. For a data operation, it may mean defining a checkpoint and a rollback path rather than treating the process as one opaque command.

This design protects people as much as systems. An engineer returning to a paused task should not have to guess whether the agent already sent a message or altered a record. A reviewer should not have to grant a new approval because the system cannot tell whether the old one was consumed. A new agent should not inherit stale authority just because it inherited a summary.

Freshness is part of recovery

Resuming a task does not mean treating every stored fact as current. Some parts of the task are durable; some need to be checked again.

The objective may still be valid, but the branch could have moved. A test result may have been correct for the original revision but stale after a dependency update. A deployment URL may no longer describe the running application. A connector grant that was appropriate yesterday may have expired or been revoked after a policy change.

The runtime should distinguish these cases instead of presenting a paused task as a frozen, perfect snapshot. On resumption, it can check the workspace revision, refresh resource availability, validate unconsumed approvals, and mark evidence that no longer corresponds to the current state. This does not have to be intrusive. It is simply an acknowledgement that the environment continues changing while the task waits.

The same discipline protects against confused retries. If an external operation has a stable identifier, the agent can query its state before issuing another request. If an action cannot be made idempotent, the task can pause for review rather than guessing whether duplicate execution is harmless. A recovery path that refuses to fabricate certainty is more useful than one that moves quickly in the wrong direction.

Recovery exposes the real unit of work

When a task can pause and resume cleanly, it becomes clear what the system actually treats as durable: the objective, the workspace, the permissions, the evidence, and the outstanding decision. These are the parts that survive a model restart, an operator handoff, or a transient outage.

That is a better unit of work than a long conversation. It respects the fact that real systems change while tasks are in flight, and it gives both humans and agents a way to continue without pretending those changes did not happen.

Reliable agentic software will not be defined by agents that never stop. It will be defined by systems that know how to stop without losing the thread.