Discussions of durable agents often start with a simple promise: after a crash, the system resumes where it left off. That promise is useful, but it is not precise enough for a system that accepts a user request at one moment, schedules work later, makes model calls, invokes tools, and lets the user steer the work while it is running.
The practical question is not “is the agent durable?” It is: which facts must survive, and which work should be restarted?
The answer is a split that is easy to miss:
Make the user’s intent durable before execution starts. Treat the process that executes it as replaceable.
That boundary separates a reliable long-running agent from an expensive chat loop with a database attached.
Durable execution is not one thing
“Durable execution” covers several different requirements. A system might persist a workflow checkpoint, save conversational messages, remember facts across sessions, or retain a tool result. Those are useful capabilities, but they do not answer whether the agent can safely accept a new request when no worker is available, or whether it may repeat an unfinished provider call after a process restart.
The distinction matters because model turns are not ordinary deterministic functions. A replay can produce a different answer. A tool call may have changed the outside world. A user may have sent another instruction while the system was down. Treating all of those as a single resumable “run” hides the decisions that actually determine reliability.
Anthropic’s account of long-running application development emphasizes decomposing work and passing structured artifacts across sessions. LangGraph’s persistence documentation frames checkpoints as a basis for resumption, fault tolerance, and human oversight, while Anthropic’s context-engineering guidance describes compaction and structured note-taking for long-horizon work. Together, these sources motivate a more precise question: what does each persisted record actually mean?
The admission–execution split
Virillio Code Editorial proposes the following admission–execution model for reasoning about long-running agents. It is an architectural framework, not an industry-standard durability taxonomy.
- Layer: Admission — What it owns: The user’s requested work, identity, delivery policy, and ordering — Must survive a process restart?: Yes — Example question: “Was this prompt accepted?”
- Layer: Execution — What it owns: A local coordinator that decides whether work should run now — Must survive a process restart?: No — Example question: “Which process is draining this session?”
- Layer: Provider turn — What it owns: A single request to a model and its associated tool loop — Must survive a process restart?: Usually not without an explicit recovery design — Example question: “May we call the model again?”
- Layer: Projection — What it owns: The visible transcript, state changes, and durable artifacts — Must survive a process restart?: Yes — Example question: “What can a user or future turn safely rely on?”
The first layer is the important one. Before waking a worker, the system writes an input record that says, in effect: *this exact request has been accepted for this session, with this delivery mode, at this point in the order.* Only after that durable write succeeds should it signal a local executor. In this proposal, the wake mechanism is idempotent: duplicate signals only ask an executor to re-check eligible work; they do not create a second admitted input or authorize a second model turn.
That signal is advisory. It can be coalesced, delayed, or lost; the durable inbox remains the source of truth. Automated post-crash progress still requires a separately designed recovery scanner or explicit drain-start path that inspects the inbox. The admission record alone does not promise that a new process will resume provider work. This is closer to a write-ahead queue than to a guarantee that a particular in-memory loop will live forever.
Why an execution coordinator should be replaceable
In this proposed design, an active agent uses one coordinator to prevent duplicate drains for the same session, combine repeated wakeups, and allow unrelated sessions to run concurrently. That coordinator is valuable, but it can remain process-local when clustered execution is out of scope.
Trying to make the coordinator itself the durable unit often creates a misleading abstraction: a “run” appears resumable even though the system has not defined what happens to an in-flight model request, a partially completed tool sequence, or a user interruption. The durable unit should be the input and the resulting state transitions—not an optimistic label for a live loop.
This leads to a useful operational rule:
An idempotent advisory wakeup may be retried. A provider turn must not be replayed without an explicit recovery policy.
That retry rule applies only when a wakeup does nothing beyond asking the current process to inspect durable eligibility. If a wake handler creates execution identity or performs side effects, duplicate delivery is not automatically safe. A model turn can consume money, invoke tools, and produce a different continuation if replayed. Safe recovery therefore needs an explicit policy: record enough information to reconcile an exact retry, treat the turn as failed and ask for a new action, or build idempotent tool semantics that make replay acceptable. “Resume the run” is not a policy.
Keep user steering durable too
Long-running agents are rarely single-shot. A user may add a clarification while an agent is reviewing files, queue a task for later, or cancel work entirely. Those inputs need durable admission just as much as the first prompt.
The key is to model delivery deliberately. A *steer* can be eligible at the next safe model-turn boundary. A *queued* request can remain pending until the agent would otherwise become idle. The exact vocabulary can vary, but the distinction prevents a common failure mode: either every new message interrupts work arbitrarily, or every message is ignored until the agent eventually stops.
This is where structured, durable state becomes more valuable than a giant prompt transcript. The transcript tells a model what happened. The inbox tells the runtime what it is allowed to do next.
A practical design checklist
Before calling an agent “durable,” test these questions:
- Admission: Is a user request written durably before a worker starts?
- Identity: Can an exact client retry be distinguished from a conflicting reuse of an identifier?
- Ordering: Does the system define when a new input becomes visible to the model?
- Coordination: Can another process discover pending work without relying on a lost in-memory callback?
- Provider recovery: Is replay of an in-flight model turn explicitly designed, rather than assumed?
- Tool semantics: Which tool calls are idempotent, compensatable, or strictly one-shot?
- Projection: Are user-visible messages and durable state transitions clear enough to audit after a failure?
If any answer is vague, the system may still be useful, but its durability claim needs a narrower scope.
What we are learning building Virillio Code
Virillio Code’s session architecture remains in development. The design direction separates durable prompt admission from model execution: the first is a promise that the system has accepted an instruction, while the second is a best-effort attempt by a local runtime with the required placement, permissions, context, and provider access. This is an architectural lesson, not a claim of crash-transparent provider execution in the current product.
That separation is not glamorous, but it pays off. It makes failures easier to explain, avoids pretending that nondeterministic work is automatically replay-safe, and gives future execution systems a stable durable substrate rather than a collection of special cases around a live loop.
Long-running agents will keep getting better at planning and acting. Their runtimes should get better at one quieter discipline too: never confuse a user’s durable intent with the transient process currently trying to fulfill it.
Sources and further reading
- Harness design for long-running application development — Long-running coding harnesses benefit from task decomposition and structured handoffs between sessions.
- LangGraph persistence — Persistence supports resumption, fault tolerance, memory, and human-in-the-loop workflows.
- Effective context engineering for AI agents — Long-horizon agents need compaction, structured note-taking, and careful context curation.
Editorial disclosure
This article was substantially researched, drafted, and revised with AI through the Virillio Code editorial workflow. Virillio Code publishes the final text under its editorial byline, and the supporting primary sources are linked above.