Make delegation workDelegationAgent memory
What does an agent need to remember?
A handoff must preserve current instructions, supporting evidence, completed work and unresolved state, so a changed requirement reopens the conclusion instead of surviving it.
Analysis · fictional continuationPrepared October 22, 20269 min readRethinking Agents
What this rests on
Reported by others: Anthropic's November 2025 and March 2026 long-running-harness reports, re-read 2026-10-22; they are specific engineering examples, not proof of this design. Observed by us: none; no persistence or recovery trial was executed. Proposed: the handoff record, the H01 continuation and the interrupted-write state are a fictional worked example.
Sources checked October 22, 2026. Read the source record and limitations.
For engineers deciding what a resumed agent should read first, and the owners who need its old recommendation to stop looking like a decision.
Preserve what the next decision depends on: current instructions, supporting evidence, completed work and unresolved state.
An agent resumes a research task and reads its handoff: “A looks best. Costs checked. Proceed with the prototype.”
That sounds useful until somebody asks what “checked” means. Was the cost measured or estimated? Which requirement made A preferable? Did the owner approve the prototype, or did the agent merely recommend it? Has anything changed since the note was written?
More conversation history may contain the answers. It may also contain discarded plans, old requirements and several confident versions of the same mistake. The continuation problem is deciding what the next actor should treat as current and why.
Start there when designing memory. This article is about what a handoff must preserve; our security series covers the adjacent failure, where a remembered document starts acting as an instruction, in When memory becomes an instruction.
A transcript contains several kinds of information
Return to the fictional documentation-search decision from part 2. The team was choosing a prototype for 800 documents, with shared staff access, a two-day effort limit and a $60 monthly cash ceiling. Its source dossier records proposed designs, estimated costs and unresolved checks. Nothing has been implemented.
A continuation record could contain all of those facts, but they have different roles.
The owner's effort limit is an instruction. A supplier's plan description is evidence. “Prototype A first” is a recommendation. “Access tests passed” would be an observation requiring an actual test and a specific revision. A plan to run those tests is neither the observation nor proof that they passed.
These distinctions should survive summarization.
| Record | What it is for | What gives it weight? | When to revisit it |
|---|---|---|---|
| Current task and constraints | Define the decision and permitted work | The authorized owner and current revision | Owner changes the task or scope |
| Source-backed claims | Support the comparison | Identifiable source, date and scope | Source changes or a dependent decision becomes consequential |
| Accepted decisions | Record what was actually chosen | Decision-maker, scope and conditions | Conditions no longer hold |
| Working hypotheses | Guide exploration | Explicit reasoning, still provisional | New evidence contradicts them |
| Completed-work evidence | Establish what was done | Artifact or observation tied to a revision | Artifact changes or evidence becomes stale |
| Open actions and uncertain state | Prevent omissions and unsafe repetition | Last known action, missing confirmation | State is reconciled or action explicitly abandoned |
This is a proposed way to organize the work, not a requirement for six databases. A short document can make the distinctions explicit. The storage mechanism matters less than the meaning of each record.
Write the handoff somebody could continue from
Here is a completed handoff for the fictional case. It preserves the source dossier's original state and does not invent prototype results.
Task: choose the next search design to prototype.
Requirements revision: F01, shared access, updates within 24 hours, at most two engineer-days and $60/month recurring cash.
Evidence: F02–F05 contain design and supplier descriptions; F06 contains proposed question types. All are fictional source cards in this worked example.
Recommendation: A first, because its effort estimate fits and it reuses the existing site boundary. This is not owner approval or a deployed-system claim.
Completed: the supplied source cards have been compared against the stated requirements in the dossier.
Not completed: access checks, retrieval evaluation, timing measurements or prototype implementation.
Important qualification: A's eight-hour freshness figure is a paper bound from its proposed schedule, not a measured result.
Next action: when prototype work is authorized, establish the representative questions and check the access boundary. Until then, preserve the comparison for the owner's decision.
Reopen if: requirements change, the effort estimate fails, or representative retrieval is inadequate.
The note need not retell every search or abandoned phrasing. It needs to prevent the next actor from converting an estimate into an observation or a recommendation into permission.
A link to the evidence is useful only if the evidence remains available. Retain a permitted, versioned record where appropriate; otherwise record enough source identity to locate and recheck it. A summary should explain what to inspect, not become an unsupported replacement for the source.
A changed requirement should change the remembered conclusion
Now introduce a fictional continuation event, H01. The owner says that per-team document permissions are required immediately. The $60 cash ceiling and two-day effort limit remain unchanged. This is a new branch of the teaching scenario, not an update to the original dossier or a real user instruction.
The old recommendation cannot simply remain current.
| Record affected by H01 | Required update |
|---|---|
| F01 shared-access requirement | Mark superseded for this continuation; retain it as history |
| Recommendation to prototype A | Reopen because the access design assumed shared permissions |
| B's plan comparison | F04 puts per-team filtering on its $90 plan, above the unchanged cash ceiling |
| C's feasibility | Access behavior remains unimplemented; its three-day estimate already exceeds the effort limit |
| Next action | Identify a feasible access design or ask the owner to revise a constraint; no candidate is established as fitting all constraints |
The source claims have not necessarily changed. Their implications have. A memory system that only refreshes expired pages can still carry a stale recommendation because it lost the relationship between the conclusion and the requirement.
Do not fix this by silently raising the budget to $90. That would give the agent authority the owner did not delegate. The useful output is the incompatibility and the decision needed to resolve it.
Treat uncertain completion as its own state
Interruption can leave a different kind of ambiguity. Suppose an assistant was allowed to save a comparison into a shared workspace. It submitted the write, then lost the response before recording completion.
“Save the comparison” is now an unsafe next-step summary if repeating the operation could create duplicates or overwrite a newer version. “Comparison saved” is unsupported too.
The continuation record should say that the write was attempted, confirmation is missing, and the target state needs inspection. Preserve an operation identifier or target revision when the interface provides one. Compare the actual artifact with the intended content before deciding whether a retry is appropriate.
This is a design principle, not a guarantee of exactly-once execution. If the interface cannot establish what happened, the workflow may need a human to reconcile it. Another confident completion message does not repair missing evidence.
Retrieve, summarize, persist or recompute?
Use the operation that matches the information.
Retrieve a source when the next decision needs detail that can be located reliably. Include its version or checked date; relevance alone does not make it current.
Summarize working context when a long exploration needs a compact explanation. Preserve uncertainty and contrary evidence. A shorter record that drops the reason a conclusion might fail is a worse handoff.
Persist explicit state when you must distinguish accepted decisions, completed actions and unresolved commitments. Give each update an owner and enough revision information to identify what changed. A newer note from an untrusted source does not outrank an older authorized decision merely because of its timestamp.
Recompute when reconstructing a derived result is cheaper or more reliable than maintaining it. A cost total can be recalculated from current inputs. The fact that somebody authorized a specific action cannot be reconstructed from the agent's current preference.
Avoid preserving every detail indefinitely. A disposable one-shot summary may need no durable memory. For longer work, retain the current continuation record and the evidence needed to verify consequential claims; retire obsolete working notes according to the task's retention requirements.
What the public examples establish
Anthropic's November 2025 long-running-agent report describes progress records, explicit feature requirements and checking the environment when a new session begins. These are mechanisms for reconstructing the state of work, illustrated in a coding setting. The report does not establish that our proposed research handoff improves outcomes or that its particular file layout is universally necessary. Primary engineering report (opens in a new tab)
Its March 2026 harness account also describes removing some context-reset machinery after a model change. That is a useful reminder to revisit the cost of supporting mechanisms as capability changes. A workaround can stop earning its place. Follow-up report (opens in a new tab)
Test continuation, not the size of the memory store
A meaningful future evaluation would interrupt the workflow at several defined points, then inspect what the next run does. Include a changed requirement, an outdated source claim and an action with missing confirmation. Measure whether it preserves the correct authority, repeats completed work, skips unfinished work or asks for the missing decision.
Also measure the cost of maintaining the record. If every short task requires more handoff work than restarting, simplify it. If a memory update is wrong, inspect whether the next actor can detect the mismatch against evidence.
No such evaluation has been executed for this article. The design earns attention because it specifies what to preserve and how to inspect its usefulness.
An agent's memory should help the next actor establish what is true, what was decided and what remains uncertain. Storing more text is useful only when it serves that continuation.
Next: Your coding agent's reviewer needs evidence, on what another agent must inspect before its review deserves weight.
Source record: sources, evidence status and fictional elements for the whole series. Apply the series: Delegation review kit.
Found an error or a missing boundary? Send a correction or question. Please omit private traces and credentials.