Long-running agents will fail mid-task. A worker restarts, a sandbox expires, or a tool call stalls. The system should recover without losing the task or repeating a side effect.
State should outlive the container
The design is simple: keep task state outside the worker, use the worker for bounded execution, and make recovery a normal path.
Store intent, tool results, checkpoints, approvals, and completion evidence in a durable record. A replacement worker can then resume from a known state instead of reconstructing the task from a stale conversation.
The durable record is an event stream
For most agent tasks, the useful unit of persistence is not a giant serialized prompt. It is an append-only record: task intent, selected context, tool calls, tool results, approvals, checkpoints, and explicit completion evidence. That record supports inspection, replay, and recovery. It also forces a healthy question at every boundary: what would a new worker need to continue safely?
Effective harnesses for long-running agents need clear recovery boundaries, externalized context, and verification rather than an assumption that a single run will stay alive indefinitely.[2] A restart should be a normal control path, not an exceptional rescue operation.
Idempotency is the quiet requirement
Resumption is dangerous when a repeated tool call creates a second ticket, re-sends a message, or applies a configuration change twice. Tool contracts should therefore expose idempotency keys, readable state, and an explicit distinction between an attempted action and a verified effect. This is distributed-systems discipline applied to agents.
Sandboxes should be disposable
A sandbox is valuable because it limits blast radius. It should have a short lifetime, narrow permissions, isolated credentials, and no claim to be the authoritative store of project memory. If a run needs a secret, issue the least-privileged credential for that action and keep the policy decision outside the sandbox.
The multi-agent research system described by Anthropic also treats coordination and context management as system design problems, not simply model-prompt problems.[3] That framing is useful even for a single agent. Reliability comes from the contracts around the model: state ownership, handoff boundaries, tool semantics, and proof of completion.
A practical checklist
- Persist intent, evidence, checkpoints, and approvals outside the worker process.
- Make every consequential tool operation idempotent or explicitly detectable on retry.
- Give each sandbox only the credentials and network access required for its current action.
- Test recovery deliberately: kill a worker at each boundary and verify that the next worker resumes without repeating side effects.
- Treat “done” as a verified external state, not a model-generated conclusion.
The point of failure is not failure
An agent platform does not become reliable by keeping one container alive forever. It becomes reliable when losing a container does not lose the task. Durable state gives the system a memory it can trust; disposable execution gives it a failure boundary it can afford.
Sources and further reading
[1] Anthropic — Managed agents
Tags
