Skip to content
All research

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.

Proposed kinds of record · what gives each one weight · not a storage requirement
RecordWhat it is forWhat gives it weight?When to revisit it
Current task and constraintsDefine the decision and permitted workThe authorized owner and current revisionOwner changes the task or scope
Source-backed claimsSupport the comparisonIdentifiable source, date and scopeSource changes or a dependent decision becomes consequential
Accepted decisionsRecord what was actually chosenDecision-maker, scope and conditionsConditions no longer hold
Working hypothesesGuide explorationExplicit reasoning, still provisionalNew evidence contradicts them
Completed-work evidenceEstablish what was doneArtifact or observation tied to a revisionArtifact changes or evidence becomes stale
Open actions and uncertain statePrevent omissions and unsafe repetitionLast known action, missing confirmationState 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.

A handoff record holds four parts: the current task and constraints, source-backed evidence, authority (what was decided and by whom, with a recommendation kept separate from approval) and open actions with uncertain state. Two continuation events feed into it. A changed requirement reopens the conclusion and its dependent claims rather than silently relaxing a constraint. An interrupted action is recorded as attempted with confirmation missing, so the target is inspected before any retry. A bar beneath states that a recommendation never becomes permission by being remembered.
Four things a handoff must preserve, and how two continuation events are reconciled against them. This is a proposed design for a fictional case; no persistence or recovery trial was executed. Open the full-size diagram.

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.

Reconciling H01 · fictional continuation event · nothing executed
Record affected by H01Required update
F01 shared-access requirementMark superseded for this continuation; retain it as history
Recommendation to prototype AReopen because the access design assumed shared permissions
B's plan comparisonF04 puts per-team filtering on its $90 plan, above the unchanged cash ceiling
C's feasibilityAccess behavior remains unimplemented; its three-day estimate already exceeds the effort limit
Next actionIdentify 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.