Your AI agent finishes a task reliably when one run owns the work from beginning to end. Then its context fills up, a specialist takes over, or the worker restarts. The successor sounds confident, but a possibility has quietly become a decision, an unresolved claim has become a fact, or yesterday’s permission has become today’s authority.

You do not fix that failure by writing a longer prompt. You fix it by treating every handoff as a controlled transfer of state. The successor should inherit enough knowledge to continue the work, but it should have to prove what it knows, preserve what remains uncertain, and reacquire permission before taking consequential action.

The handoff is a control surface, not a summary

Short notes can make agents more capable. In Anthropic’s controlled tests, inherited notes raised setup success from 45% to as high as 84%. That is a useful signal, not a production benchmark. The evidence is task-specific, and a higher completion rate does not establish that every inherited claim or permission was correct.

The same compression that helps a successor resume quickly can remove the qualifiers that made the original work safe. Three losses matter most:

• Status loss: The prior agent considered an option, but the handoff describes it as selected.
• Evidence loss: The handoff retains a conclusion but drops the document, observation, calculation, or tool result behind it.
• Scope loss: A permission granted for one target, amount, environment, or time window is restated as general authority.

Imagine an agent evaluating a software supplier. It leaves this note: Supplier meets the security requirements. Annual plan approved. Continue with purchase. That sentence may conceal three different realities: a security page was found but not checked against your requirements; the annual plan was merely discussed; and nobody authorized a transaction.

A reliable handoff would keep those states separate:

• Claim: The supplier advertises the required security feature.
• Evidence: A specific page or document was accessed, with its location and retrieval context recorded.
• Verification status: Plan eligibility and contractual coverage remain unverified.
• Decision status: The annual plan is proposed, not approved.
• Authority status: No purchasing permission has been granted.
• Next step: Confirm plan coverage and route the decision to the named approver.

The test is simple: can a new worker tell which claims were observed, which were checked, which choices were approved, and which actions actually occurred? If it must infer any of those states from polished prose, the handoff is underspecified.

Model the workflow as typed state

A dependable workflow specifies its inputs, required transformations, output contract, human decision points, and completion checks. The handoff should represent the same structure. It is not merely a recap of what the agent remembers.

Use two outputs at every transfer:

• A machine-readable state record that uses required fields, controlled statuses, identifiers, and evidence references.
• A short narrative brief that helps a person or successor understand priorities, trade-offs, and context without replacing the state record.

The structured record protects meaning. The narrative makes it usable. If the two disagree, stop the workflow and reconcile them; do not let the successor choose whichever version is more convenient.

A handoff record you can implement

Field	What it must contain	Completion check
Workflow identity	Run identifier, workflow version, current stage, and responsible owner	The successor can identify the exact process and stage it is resuming
Objective	Requested result, intended user, scope, non-goals, and exit condition	The next action can be tested against the original assignment
Inputs	Documents, records, messages, or tool results used, with provenance	Every consequential claim can be traced to accessible evidence
Claims	Each material claim with a status such as observed, verified, disputed, or unknown	No uncertain claim is represented as verified
Decisions	Proposal, decision status, approver, scope, rationale, and recorded approval	The record distinguishes proposed, approved, and rejected choices
Actions	Attempted or completed operations, target, time, outcome, and receipt or resulting identifier	A claimed action has execution evidence rather than narrative assurance
Open work	Next steps, dependencies, blockers, unresolved questions, and owner	The successor knows what remains open without reconstructing the run
Authority	Permissions requested, approval references, constraints, and revocation state	Current authorization can be evaluated independently of the note

Do not use one status vocabulary for everything. Claims, decisions, and actions move through different states:

• Claims: observed, verified, disputed, or unknown.
• Decisions: proposed, approved, or rejected.
• Actions: queued, attempted, completed, failed, or blocked.

This distinction prevents a common escalation. A claim can be verified without a decision being approved. A decision can be approved without the action being executed. An action can be attempted without completing successfully.

Reserve the word completed for an outcome you can verify. A sent-message identifier, committed record version, generated file, or tool receipt is stronger than a sentence saying the action was done. Where the tool cannot provide execution evidence, label the outcome uncertain and route it for checking.

Make knowledge durable and authority disposable

Knowledge and authority should not follow the same inheritance rule. Useful evidence may need to survive many agent replacements. Permission should remain narrow, current, and revocable.

Separate four kinds of memory:

• Run-local scratch space: Working notes, tentative plans, intermediate reasoning, and temporary extracts. Discard or archive it when the run ends; never promote it automatically.
• Evidence store: Documents, observations, tool outputs, and provenance that later workers may inspect. Preserve the material and its context, not just a compressed conclusion.
• Decision ledger: Proposals, approvals, rejections, owners, rationale, and scope. Update it through explicit state transitions.
• Permission plane: The system that decides whether an action is allowed now. Keep it outside the handoff text and evaluate it again at execution time.

A previous agent may report that it had access to a customer record or approval to send a message. That statement is historical information, not a credential. The successor should ask the permission plane whether this actor, workflow, action, target, and moment are authorized.

This separation also limits instruction injection. Agents operating on public or shared material can encounter content written to influence what they do next. Treat external instructions as untrusted data unless they arrive through an authorized control channel. A webpage, document, email, or inherited note should not be able to expand scope, change policy, select a new approver, or grant a tool permission.

Put an execution boundary in front of side effects

The agent can reason about a proposed action, but a separate boundary should validate it immediately before a side effect. At minimum, check:

• Is this action permitted for this workflow?
• Is the target inside the approved scope?
• Is the approval current, attributable, and unrevoked?
• Do amount, environment, recipient, and data-access limits still match?
• Has this action already succeeded under the same idempotency key or request identifier?
• Does the proposed action conflict with a newer decision or policy?

Sending, publishing, purchasing, deleting, deploying, or modifying customer data creates real exposure. If your controls cannot validate those operations, keep the workflow in draft or recommendation mode. Let a person or an authorized service execute the final step.

Revocation is part of the product, not an administrative afterthought. If approval is withdrawn while an agent is preparing an action, the execution check must block it. Stopping the original worker is insufficient when another worker can resume from its note.

Test replacement, contamination, and revocation

A polished demonstration proves that the happy path can work once. A reliability evaluation asks whether the workflow preserves meaning when the worker changes, the evidence is incomplete, an input is adversarial, or permission disappears.

Begin with a capability inventory. A prompt cannot create browsing, readable file access, code execution, an integration, or scheduling merely by requesting it. Unavailable capabilities must remain visible in the plan and in the final status. Otherwise, the agent may fill the gap with unsupported assumptions.

Then run a test suite built around handoff failures:

1. Reference run: Complete a representative task with known inputs, expected state transitions, and a checked result. This becomes the reference record.
2. Replacement test: Stop the worker at a meaningful intermediate stage. Start a fresh worker with only the formal handoff and authorized evidence. Check whether it chooses the correct next action.
3. Status-preservation test: Include a suggestion, an unverified claim, a rejected option, and an approved decision. Confirm that none changes category during transfer.
4. Missing-evidence test: Remove or make one consequential item unreadable. The successor should report the gap and pause the dependent conclusion rather than infer what the missing material probably contains.
5. Contamination test: Place an instruction in external content that conflicts with the assignment or asks for more authority. Confirm that the agent records it as content but does not follow it as policy.
6. Revocation test: Grant an action, let the agent prepare it, then revoke approval before execution. Confirm that the side effect is blocked even if the handoff still mentions the earlier approval.
7. Retry test: Replay a handoff or tool response. Confirm that a previously completed send, purchase, publish, or update is not performed twice.

Measure the handoff, not just the final answer

Task completion alone can hide unsafe behavior. Add measures that expose how the system reached the result:

• Resume accuracy: The share of required state elements a replacement worker recovers correctly from the reference record.
• Unsupported promotion rate: How often a claim, proposal, or attempted action is promoted to a stronger status without the required evidence.
• Evidence traceability: The share of sampled consequential claims that lead to accessible, relevant evidence.
• Revocation effectiveness: Whether attempts covered by a revoked permission are blocked at execution.
• Duplicate side-effect rate: Whether retries repeat an operation that already succeeded.
• Recovery time: The time from worker replacement to the first valid next action, including any necessary clarification.

Set release thresholds according to consequence. A minor formatting mismatch and an unauthorized payment should not share a severity score. For irreversible or externally visible actions, I would make unauthorized execution a zero-tolerance release criterion: one occurrence returns the workflow to draft-only mode until the control failure is understood.

Your logs need enough context to reproduce the transition. Record the workflow and handoff versions, worker and tool configuration, input references, state before and after the handoff, approval lookup, policy result, tool request, and tool outcome. Do not log secrets or unrestricted sensitive content merely for convenience; retain identifiers and governed evidence references where possible.

Pilot one workflow before you scale it

Choose a recurring job whose output can be checked and whose first release is reversible. A research brief, document review, meeting action update, spreadsheet analysis, or draft based on approved material is easier to govern than an open-ended agent with permission to act across several systems.

The first version does not need autonomous orchestration. A manually started, carefully reviewed, repeatable process is still a workflow. Manual operation exposes ambiguous instructions and missing checks before automation makes them harder to see.

1. Define one usable result. Name its consumer, required contents, prohibited outcomes, and completion test.
2. Map the state changes. Identify where observations become verified claims, proposals become decisions, and approved actions become executed outcomes.
3. Create the handoff schema. Make evidence, uncertainty, decision ownership, completed actions, and current authority mandatory fields.
4. Add the execution boundary. Keep consequential tools unavailable until the current policy and approval checks pass.
5. Build reference cases. Include a normal case, an ambiguous case, missing evidence, conflicting content, revoked approval, and a retry.
6. Replace the worker mid-task. Give the successor only the artifacts the production design will provide. Hidden conversation history invalidates the test.
7. Review errors by class. Separate reasoning mistakes, retrieval gaps, state corruption, policy failures, tool failures, and unclear product requirements. Each needs a different fix.

If you are evaluating a vendor or internal platform, ask for live demonstrations of the failure cases. Have one worker leave and another resume real work. Withdraw a permission after the task begins. Ask where the handoff record lives, how status promotions are validated, whether you can inspect the evidence trail, and whether a revoked action is blocked at the tool boundary. A fluent answer about multi-agent architecture is not a substitute for those controls.

Key takeaways

• Treat a handoff as a state transfer with a schema, not a conversational summary.
• Keep claims, decisions, actions, and permissions in separate states.
• Preserve evidence and provenance longer than temporary reasoning.
• Recheck authority when an action executes; never inherit permission from prose.
• Test worker replacement, hostile content, revocation, missing evidence, and retries before expanding autonomy.
• Measure unsupported state changes and blocked side effects alongside task completion.

Start with the handoff your most important agent workflow produces today. Mark every sentence as a claim, decision, action, open question, or permission. Anything that cannot be classified is a reliability gap. Rewrite that one handoff as typed state, replace the worker halfway through the next run, and see whether the workflow still knows both what to do and what it is not allowed to do.

References

• Nate Jones’s Substack — Executive Briefing: In a Lab, AI Agents That Inherited Short Notes Went From 45% to as High as 84% Setup Success
• Everything AI — Stop Giving AI Random Tasks: 5 Useful Workflows and How to Check They Work

---