Agent work context: checkpoint and resume

One root record represents the work. Every checkpoint is a child of that root via parentRecordId: siblings, never chained checkpoint-to-checkpoint. The head is the one checkpoint nothing supersedes, one call:

The contract type gives the state a shape a resuming agent can rely on: objective and summary for the zero-context reader, completedWork and pendingWork (ordered, first entry is what to do next), decisions with rationale and who rendered them, assumptions, constraints, openQuestions, and resumeInstructions. What a prose handoff keeps is up to whoever wrote it; what a typed checkpoint keeps is declared.

The head id rides in two places. The top-level supersedesRecordId is the field the engine acts on: resolved at create (a dangling target is refused with a 404), immutable, inside the signature, and what retires the old head from the superseded=false view. The copy inside criteria carries the same claim in the signed record content, where offline verification can see it. One guard lives in the schema itself: a final checkpoint must have empty pendingWork, so the work cannot be declared done while items remain.

Checkpoints are snapshots, not appended logs. Superseded checkpoints stay on the ledger forever, so the head keeps only the recent working set and the supersedes chain is the archive of how the work actually progressed. A useful working checkpoint is 2 to 4KB; an instructed model compacts an oversized head into a small successor naturally.

A registered agent is a durable identity. The sessions that do its work, across models, harnesses, and runs, are ephemeral. Resume means a new session of the same agent, presenting that agent's existing key. For a handoff you want on the record, mint an additional key bound to the same agent for the successor session: attribution in each record carries both the agent and the specific key, so the succession is visible in the chain and each successor's key is independently revocable. Under live probes, a key bound to a different agent could neither read nor continue the work.

The recipe was exercised with fresh model contexts across four model families (Gemini, GPT, Claude, and their small variants), each given nothing but a base URL, an agent key, a root id, and a type name, against a live server. The run counts are small, so read this as trace evidence rather than rates: the strongest performer completed the full resume protocol in every run, including reading an oversized head and writing a compacted successor around a tenth its size.

The finding that holds across every failed run: the lineage stayed clean. No model ever forked the chain or landed a successor on a stale head.

One failure mode survives the guard, and it shaped a convention. A small model wrote a checkpoint that correctly superseded the head while claiming work that never happened; its own request trace shows no such call. A signed checkpoint is attributed, not fact-checked. The convention: when a pending item creates a record, the successor checkpoint carries the created record id, which turns “I did it” into a claim checkable against the chain.

Scale, as far as it was exercised: at 150 checkpoints under one root, the head is still one call and the full lineage check walks every page in tens of milliseconds against a local server. Months-long work items with thousands of checkpoints remain unexercised.

Two sessions resuming the same agent's work concurrently can both read the same head and both write successors that supersede it. Both land, both are genuinely signed, and the head query silently returns whichever got the later timestamp: a fork, not tamper. The server notarizes what it is told; lineage coherence is the client's job by design.

The recipe ships the tool for that job: a lineage checker that, given a root, proves exactly one initial checkpoint, every supersedes reference resolving under the root, no checkpoint superseded twice, a single chain covering everything, and a terminus that matches the head query. Run it at every resume if concurrent sessions are possible in your deployment. Recover from a fork by writing a checkpoint that supersedes the branch you keep and records the merge; never try to un-write the other branch.

As of v1.5.0 the whole loop runs over A2A. An A2A-native session holding the agent's key writes checkpoints with create_record, which carries both parentRecordId and supersedesRecordId, and reads the head with a ListTasks filter on superseded = false; the returned Task's metadata reports the lineage, so a writer can tell a live head from a replaced one without a REST read. What stays REST: fleet triage (the ListTasksgrammar has no criteria term, so “which work is awaiting approval” is one criteria search over REST but one call per work item over A2A), and checkpoints that need references or metadata, such as carrying A2A task ids so the A2A side of a handoff is checkable from the chain.

Every checkpoint is an ordinary AGLedger record, so it is signed, attributed, hash-chained, and verifiable offline like everything else on the ledger. You adopt the recipe for resume and handoff; what accumulates is a tamper-evident archive of how the work progressed, with a succession between two processes provable from the exported bytes alone. Nothing to migrate when an operator wants oversight or an auditor wants proof: it is the same record.

The recipe is plain files: the contract type, a registration script, an importable manifest, and the lineage checker. The spine behind it is proven end to end by a twelve-step walkthrough against a fresh install of the published release, offline verification of every record included. It ships with the v1.5.0 release at examples/recipes/work-context alongside the industry recipes; the Agent Work Context guide is the checkpoint-and-resume working loop, and the install guide covers registering any recipe against your Server in one command.

For the measured background, the blog post Durable Intent, Measured wiped four agents mid-task and asked them to finish their own work.