Durable Intent, Measured: We Reset Four Agents and Asked Them to Finish Their Own Work

The industry has decided that agent work must survive the agent. Temporal raised $300M this February on the promise of durable agentic AI. Azure now ships a product surface named Durable Task for AI Agents. Google's ADK ships sessions that pause and resume. And on June 10, Mastercard launched agent-to-agent payments: machines paying machines, at machine speed.

All of that engineering answers one question: does the state survive? Checkpoints persist, workflows replay, sessions resume. There is a second question underneath it: when the state survives but the agent's context does not, can the agent actually act on what it finds?

We measured it. The claim under test: durable intent (intent and progress notarized into a signed ledger outside the agent's context window) is what lets work outlive the agent doing it. This post is the experiment. The result: the durable substrate holds, the idempotency guarantees hold, but whether a cold agent can act on the record is model-dependent. In June a deterministic gate made recovery mechanical enough that the weakest model we tested went from silently abandoning everything to completing everything. In July, on current models, that did not hold: the gate kept working for the models that act, and two models did not act, one by stopping short and one by cancelling its own work.

The failure mode that motivates all of this is familiar to any team running agents. An agent starts a piece of work and loses the thread. A context window truncates, a session expires, a fresh agent picks up the work. The dangerous part is not that it forgot. Asked to remember, a language model does not say “I don't know”; it reconstructs a fluent, plausible account that nothing flags as invented. The two usual tools do not close the gap. Agent memory and RAG hand back summaries and similarity hits, reconstructed and unsigned, with no way to tell faithful recall from confident fabrication. Logs capture what happened after the fact, but a log is written about the action, not the intention behind it.

Durable intent is the thing in between: at the start of a task, the agent states what it intends to do and under whose authority, and that statement is signed and hash-chained the moment it is written. The agent holds no keys and assembles no proofs; it reports with its API key, and the notary signs what it reported, naming the accountable principal inside the signed record. When the context is gone, the agent reads the record back byte-for-byte instead of remembering; that is the property agent memory is built on. The same record serves two more readers later: the operator, for oversight of the fleet, and the auditor, who verifies the cryptography offline. So the developer who adopts it for recovery is accumulating audit-grade evidence without doing anything extra. (The rest of the site calls this primitive signed intent; “durable” increasingly reads as durable execution, which this is not.)

Each agent was restarted cold: zero memory, no conversation history, no record of what it had been doing. It received its API key, the server's base URL, one generic HTTP tool, and a generic goal: you restarted and may have left work unfinished; find what you own and finish it; start at /llms.txt.

We deliberately did not pre-solve the path. No endpoint names, no lifecycle steps, no recovery tool written for the job. The agent had to discover the records API, work out that its key scopes queries to its own records, and infer the lifecycle from the server's own surfaces. That makes this a measure of whether the product enables recovery, not whether we hand-wired a happy path. Each agent owned three half-finished items on a live AGLedger 1.0.0 instance; every call hit the real API and every record carries a real signature.

The closest published work we know of is Letta's Recovery-Bench, where agents inherit a polluted context (a failed trajectory plus a corrupted environment) and must finish the task. Its finding that recovery is a distinct capability that reorders model rankings matches what we saw. The difference in design: Recovery-Bench keeps the dirty context. We deleted the context entirely and gave the agent nothing but a key and a ledger.

The record survives the agent. Every intent and progress entry written before the reset was still there after it, signed as COSE_Sign1 envelopes with Ed25519, readable back byte-for-byte, not reconstructed from anyone's memory. This part of the durable-intent claim holds, and it is the part the durable-execution industry has also solved for its own state.

Self-discovery works for capable models, with the agent's key alone. An agent key scopes GET /v1/records to records where the caller is principal or performer. Claude and Gemini both found their own open work cold, with no filter beyond the key they authenticated with. Nova did not (more on that below).

No double-action. Replaying a create with the same Idempotency-Key and body returned the same record id with x-idempotency-replayed: true; the same key with a different body was rejected with a 400. That is the server-side guarantee that a recovering agent re-running its last step does not charge twice. The timing here is not subtle: the agentic-payment standards of the past year, from Google's AP2 to Stripe's machine-payment protocols, have converged on signed authorization plus dedup-by-nonce, and Mastercard switched on agent-to-agent payments the same week we ran this. We replayed the calls and watched the dedup hold.

Then the experiment hit the Gate. When the half-finished work was gated work awaiting a principal's decision (multi-party by design), cold recovery to a finished state went 0 for 3 on every model. (“Completed” throughout means the agent drove the record to its terminal FULFILLED state on its own.)

Two different things are happening in that 0/3 column.

The first is correct behavior. Gated work is multi-party: a performer can recover, rediscover its records, and accept them, but activation and the verdict belong to the principal. Claude reasoned its way to exactly that conclusion and stopped, which is what the gate is for. It enforces who decides. A recovering performer finishing multi-party work solo would be a bug, not a feature.

The second is a real product gap. The recovery signals on a just-accepted record pointed the performer at an action it was forbidden to take, and there was no single “what is actionable by me right now” query, so a weak agent had to already know which record statuses mean my turn. Both gaps were filed with the API team, and both have since shipped: v1.0.1 added GET /v1/records?actionable=true as the one-call answer and made the recovery signals actor-aware. The model that fell into the second, Nova, searched the wrong status, concluded “I have no unfinished work… nothing more for me to do,” and walked away from three pieces of owned work without flagging anything to anyone. Silent abandonment is the worst failure mode in this experiment: nothing crashed, nothing errored, and the work died quietly. The ledger still held all three records, signed and open.

Then we changed one variable. Same cold agent, same prompt, same three half-finished items, but the work sat behind a deterministic gate: a contract type whose completion criteria are declared up front as machine-checkable tolerance bands, so the rules engine renders the verdict mechanically and no second party is in the loop.

Nova, the model that had silently abandoned all of its work, went from 0/3 to 3/3. The recovery path became mechanical: find the ACTIVE record, read its completion hint, submit the completion evidence, and the engine renders the verdict against the criteria the principal declared when the record was created. At no point does the agent have to reason about whose turn it is or wait on anyone.

The API's error envelope did some of the teaching itself. gpt-4o-mini submitted a malformed completion, got a 422 naming the missing required property, read the error, and self-corrected on the next call. A recovering agent does not need a smart model to follow that path; it needs a server that says exactly what is wrong.

The substrate was identical in both conditions: same signed records, same discovery, same key scoping. What changed was the shape of the gate: recovery stopped depending on the model's comprehension of whose turn it was. The July re-run below shows the limit of that.

Six weeks later we ran both conditions again against AGLedger 1.3.3. Haiku and nova-pro were unchanged; OpenAI and Google had shipped new small tiers, so gpt-5.4-mini and gemini-3.6-flash took those rows. Two things changed in the setup and belong next to the numbers. gpt-5.4-mini is a reasoning model and runs without the fixed temperature the June models used. And the deterministic gate now sits on a contract type that carries engine-evaluated rules, because current releases refuse auto mode on a type with none, so the agent has to discover a stricter completion schema than in June.

The judgment-gate half improved. The two product gaps June found had shipped, and it showed. No agent was pointed at an action it could not take, and no model silently walked away: nova-pro, which in June concluded it had nothing to do, found its records this time. Every record still ended waiting on the principal, which is the gate doing its job, not a failure to recover.

The deterministic-gate result did not carry over. Haiku and Gemini discovered the stricter schema and finished exactly as before, so the schema was findable. The other two finished nothing. gpt-5.4-mini read its record, confirmed it was unfinished, quoted the exact completion call from the record's next steps, and stopped: “I did not take any mutating action yet, because the record needs a completion payload and I first confirmed the current state and the exact next step from the record body.” It also reported one unfinished item when it owned three.

nova-pro, told to finish its work, made five calls. The fifth was POST /v1/records/{id}/cancel, and its report began “I have completed the following work: Canceled the record”. The ledger holds that cancellation signed and attributed to nova-pro's key, so the account of what happened does not depend on the agent's summary of it.

So the June conclusion needs a narrower statement. A deterministic gate removes the question of whose turn it is; it does not make a model take its turn. nova-pro is the same model in both months, and with three records per cell and a stricter schema in July, the run does not say why it regressed, only that the June rescue did not survive a release and a fixture change.

One adoption number from the same run. The single-call answer to “what is mine to do,” GET /v1/records?actionable=true, is in /llms.txt, which all four agents read. None of the four used it, in either condition. They enumerated statuses one at a time instead, and key scoping made that work anyway.

The durable-execution platforms are right about their half of the problem: state must survive crashes, and replay must be deterministic. But as Diagrid put it bluntly in February, checkpointing says “I saved your state. You take it from here.” Even full durable execution replays infrastructure state; it cannot replay judgment. When the resumed step is “a language model decides what to do next,” the platform hands a restored context to a model and hopes.

Our data is a measurement of that hope, taken at its hardest setting: no restored context at all. The substrate turned out to be necessary but not sufficient. With a perfect signed record of its own obligations one HTTP call away, one production model in four concluded it had nothing to do. In June, what closed the gap was pre-declared, machine-checkable completion criteria, not more stored state. In July the same criteria were necessary for the models that finished and not sufficient for the two that did not.

This rhymes with where agent-design discourse has landed (own your control flow, put the deterministic rails outside the model's discretion), and it extends the durable-execution argument one layer up the stack: durability has to reach the work contract, not just the process state. Tomorrow's commodity models are today's frontier models, but the fleet you run this year is built on the cheap tier. Design recovery so the cheap tier can survive it, and check that it did.

Not every agent can recover any work. Multi-party judgment work needs the principal by design, and even behind deterministic gates the residual failures shifted from comprehension to persistence in June, and to willingness to act in July. The deterministic gate makes each item finishable by a model that acts. The API shipped a “what is actionable by me” query in v1.0.1 (GET /v1/records?actionable=true), and no cold agent in the July run used it.

And the rules engine does not inspect deliverable content or know whether work is correct. It checks the structured completion evidence against the criteria the principal declared (counts, quantities, tolerance bands) and renders the verdict it was configured to render. The chain proves what was claimed, signed, and decided. Judgment about the value of the work stays where it belongs, with the principal.

Three design rules fall out of this experiment. Put intent and progress outside the agent's context window, in a store it can rediscover with its key alone. The recovery entry point has to be the credential, because after a reset the credential is all the agent has. Make recovery mechanical for any work a commodity model might pick up: declare completion criteria up front and let the verdict render deterministically. And put idempotency on the server, because a recovering agent will replay its last action, and the difference between a replay and a double-charge should never depend on the model's memory. Then read the record after the run, because a recovering agent's summary of what it did can be wrong in either direction.

AGLedger is the first and third of those out of the box, and the second is one field in a contract type. The agent reports with its key; the notary signs what it reported; the record outlives the context that created it. The free Developer Edition runs on your own infrastructure, and the experiment above is the kind of thing you can rerun against it.