A run measured in days cannot keep its state in a context window, so long-horizon agents are workflow engines with a model attached. Durable state, checkpointing and resumability are the actual requirements. Everything difficult about them is a distributed systems problem, not a reasoning problem.
Short agent runs get away with holding everything in context. The conversation is the state, the process stays alive, and if it fails you rerun it.
None of those hold past a few minutes. The process will be restarted, the context will not fit, and rerunning from the start is either wasteful or impossible because side effects already happened.
At a glance
- Context is not storage; long runs need durable external state
- Every step must be resumable from a checkpoint
- Actions with side effects need idempotency keys
- The world changes mid-run, so facts need re-verification
- Budget must be enforced across the whole run, not per session
- Human checkpoints are a feature, not an interruption
What breaks first?
| Assumption from short runs | What replaces it |
|---|---|
| State lives in the context window | Durable store with a defined schema |
| The process stays alive throughout | Resumable steps with checkpoints |
| Failure means rerun from the start | Resume from the last successful checkpoint |
| Facts gathered early stay true | Re-verification before acting on stale data |
| Retrying a step is harmless | Idempotency keys on anything with effects |
| One budget per run is enough | Budget tracked and enforced across sessions |
The first row is the one that reframes the whole problem. Once state must be durable and structured, you are building a workflow engine, and the model becomes one component inside it rather than the thing that holds everything together.
What does durable state contain?
Not the transcript. A structured record of what has been established and what remains.
- The goal, unchanged from the start and referenced at each resume
- Verified facts with their source and the time they were verified
- Completed steps with their outputs and idempotency keys
- Outstanding work as an explicit list rather than something to re-derive
- Failures and what was tried, so a resumed run does not repeat them
- Cumulative budget consumed to date
Storing the transcript instead is the common shortcut and it fails at exactly the moment it matters, because a multi-day transcript exceeds any context window and forces summarisation that loses precisely the details a resume needs.
How does resumption actually work?
Figure 1 — Two ways a long run handles a crash
Context-held state
The process dies on day two. The context is gone with it.
Restarting means beginning again, re-doing work that already had effects, or abandoning the run. Neither option is acceptable once real actions have been taken.
Unrecoverable
Checkpointed state
The last successful step wrote its output and its idempotency key to durable storage.
A new process loads the state, sees which steps completed, and continues from there. The crash costs one step, not the run.
Resumable
Checkpoint after every step that produced an effect, not on a timer. Time-based checkpointing can lose an action that already happened, which is the one thing resumption must never do.
Why do idempotency keys matter so much?
Because resumption inherently means re-executing near the failure point, and any action performed twice is a bug.
Generate a stable key per intended action, derived from the run identifier and the step, and pass it to whatever performs the effect. A repeated call with the same key returns the original result rather than acting again.
Without this, a crash between performing an action and recording it produces a duplicate on resume. That window is small and, over a run of days with many steps, it will eventually be hit.
Watch for this
Facts verified on day one may be false by day three. An agent that checked stock levels, gathered approvals or read a policy at the start of a long run must re-verify anything load-bearing before acting on it. Timestamp every stored fact and treat anything past a defined age as requiring a fresh check rather than trusting the record.
Where do human checkpoints belong?
At the boundaries where reversal stops being possible.
Long runs make approval gates easier rather than harder, because nobody expects an immediate answer. A run that pauses for a day awaiting confirmation is behaving normally, which is not true of an interactive agent.
- Before the first irreversible action, with a summary of what has been established.
- At any escalation in scope, where the agent has concluded the work is larger than stated.
- On budget threshold, before consuming a large share of the allowance.
- On repeated failure, rather than continuing to retry across days.
Design the pause as a first-class state, not an exception. A run waiting for approval should be resumable in the same way as one recovering from a crash, since mechanically they are the same thing.
How do you manage budget across days?
Track cumulative consumption in durable state and check it on every resume, not per session.
A run split across twenty process lifetimes, each enforcing its own limit, has no effective limit at all. The budget belongs to the run, so it must live where the run’s state lives.
Wall-clock time needs its own treatment. A run that has been alive for a week without completing is usually stuck rather than working, and a maximum age is worth enforcing independently of token or step counts.
Where do teams go wrong?
Summarising the transcript as a state strategy
Compressing history to fit context loses exactly the specifics a resume needs: identifiers, exact values, which steps completed. Structured state avoids the problem rather than mitigating it.
Checkpointing on a timer
Effects happen at step boundaries, not at intervals. A timer can place a checkpoint after an action was performed but before it was recorded, which is the precise gap that produces duplicates on resume.
Treating a stalled run as a running one
Without a maximum age, a run that will never complete consumes budget and holds locks indefinitely. Stalled runs need detecting and terminating, not waiting on.
What do experienced teams do differently?
They use an existing workflow engine rather than writing one.
Durable execution, retries, checkpointing and resumability are solved problems with mature implementations. Building them again inside an agent framework produces a worse version of something that already exists, and the agent-specific part — the model deciding what to do next — slots into that machinery as one step type.
They also make run state inspectable by humans. A long-running agent is an operational object like a batch job: someone will need to see where it is, why it paused and what it has done, and a run that can only be understood by reading traces is one nobody will supervise properly.
A short glossary
- Durable state
- Structured run state stored outside the process, surviving restarts and readable on resume.
- Checkpoint
- A recorded point from which a run can resume without repeating completed work.
- Idempotency key
- A stable identifier attached to an action so repeating the call does not repeat the effect.
- Fact staleness
- The degree to which information gathered earlier may no longer be true when acted upon.
- Durable execution
- A workflow engine property guaranteeing progress survives process failure.
Key takeaways
- Long-horizon agents are workflow engines with a model attached, not larger versions of short agents.
- State must be durable and structured; the transcript is not a state strategy.
- Checkpoint after every step with an effect, never on a timer.
- Idempotency keys are mandatory, because resumption means re-executing near the failure.
- Facts gathered early must be re-verified before being acted on days later.
- Budget belongs to the run and must be enforced across sessions, not per process.
- Use an existing durable execution engine rather than rebuilding one inside an agent framework.
Frequently asked questions
Why can’t a long-running agent keep state in context?
Because a multi-day run exceeds any context window, and the process holding it will be restarted before the run completes. Once state has to survive process death and fit no fixed size, it must live in durable structured storage instead.
What should durable state contain?
The goal, verified facts with sources and timestamps, completed steps with outputs and idempotency keys, outstanding work as an explicit list, failures already encountered, and cumulative budget consumed. Not the transcript, which loses precision when summarised to fit.
When should a long run checkpoint?
After every step that produced an effect, rather than on a timer. Effects happen at step boundaries, and a time-based checkpoint can land after an action was performed but before it was recorded, which is exactly the gap that produces duplicates on resume.
Why are idempotency keys necessary?
Because resumption re-executes near the point of failure, and any action performed twice is a bug. A stable key derived from the run and step lets the receiving system return the original result rather than acting again.
How do I handle facts that go stale mid-run?
Timestamp every stored fact and define a maximum age beyond which it must be re-verified before being acted on. Stock levels, approvals and policies checked on day one may be false by day three, and acting on the record is the failure.
How should budget work across multiple sessions?
Track cumulative consumption in durable state and check it on every resume. A run split across many process lifetimes, each enforcing its own per-session limit, effectively has no limit. Enforce a maximum wall-clock age separately.
Are human approvals harder in long runs?
Easier, actually. Nobody expects an immediate answer from a multi-day process, so a run pausing for a day awaiting confirmation is behaving normally. Design the pause as a first-class resumable state rather than as an exception.
Should I build my own durable execution layer?
No. Durable execution, retries, checkpointing and resumability are solved problems with mature implementations. Use one and let the model’s decision-making be one step type inside it, rather than rebuilding workflow machinery within an agent framework.
References
- Anthropic. Model Context Protocol documentation, covering the tool layer through which long-running agents perform effects.
- Liu, N. F., et al. Lost in the Middle: How Language Models Use Long Contexts. arXiv:2307.03172. Why summarised transcripts degrade as a state mechanism.
- OpenTelemetry. Traces and spans, relevant to instrumenting runs that span many process lifetimes.
