The State-Handoff Playbook: What Actually Has to Survive When You Switch AIs Mid-Task

You are forty messages deep into a debugging session. Your AI has read the logs, tried three fixes, and is finally circling the real cause. Then it hits its context limit, or you switch to a stronger model for the finish, or you simply want a second brain on the problem. You copy the conversation, paste it into the new AI, and type: "continue from where we left off."

And the new AI confidently continues from where you were never.

It re-tries the fix you already ruled out. It "remembers" a test result that never happened. It presents conclusions with the same swagger as the first AI, except now nothing behind those conclusions is checkable. You have not handed off work. You have handed off a story about work, and the new AI is now improvising the ending.

This is the AI agent continuity problem, and it is not solved by longer context windows. It is solved by knowing exactly what state has to survive a handoff, and by making that state checkable by whoever receives it.

A transcript is not state

Here is the core confusion. A chat transcript records what was said. State is what was established. These are different things, and the difference is where handoffs die.

Consider a handoff between two humans. When an engineer goes on vacation mid-incident, they do not hand their replacement a dump of every Slack message. They write a handoff note: what we know, what we tried, what is still broken, what to do next. The note is short because most of the transcript was noise, and it is useful because the surviving parts are the parts somebody verified.

An AI-to-AI handoff needs the same discipline, except with one extra requirement: the receiving AI cannot ask clarifying questions the way a human colleague can. It will treat whatever you paste as ground truth. So the handoff bundle has to be built so that fiction cannot smuggle itself in.

The four things that must survive

Every successful cross-AI state handoff I have run or studied comes down to four components. Miss any one of them and the new AI is guessing.

1. The goal, with constraints attached. Not "fix the bug." The goal as it currently stands, including every constraint discovered along the way: which files are off-limits, which behavior must not regress, what "done" means now versus what it meant at the start. Goals drift during a session. The handoff must carry the current goal, not the original one.

2. Ruled-out paths, with reasons. This is the most commonly dropped component and the most expensive to lose. The first AI tried the obvious fix and it failed. If the handoff does not say so, with the evidence, the second AI will try the obvious fix again. You will pay for the same dead end twice. A ruled-out path is only useful if the reason travels with it: what was attempted, what was observed, why it was abandoned.

3. Verified intermediate results, with provenance. The tests that passed. The query that returned the damning row. The config value that turned out to be wrong. Each result needs its provenance: how it was obtained, when, and what would let someone re-obtain it. An intermediate result without provenance is a rumor. This is where most people paste a summary like "we confirmed the database was the bottleneck" and the new AI builds an entire plan on a claim nobody can re-check.

4. The next action, stated concretely. Not "continue debugging." The single next step, with the command or query to run and what a pass or fail would mean. A handoff that ends in vagueness hands the new AI a blank check to wander.

Why the copy-paste transcript fails

Pasting the whole conversation feels thorough. It is the opposite. Four failure modes show up every time:

Hallucinated continuity. The new AI smooths over gaps. Where the transcript is ambiguous, it invents the most plausible bridge and presents it as memory. You cannot tell which parts it "remembers" and which parts it authored, because it does not know either.

Lost provenance. The transcript shows a test passing, but not which environment ran it, with what inputs, at what time. The result is visible; its checkability is gone.

Context rot. Long transcripts contain early hypotheses the first AI later abandoned. The second AI has no reliable way to weight the retraction at message 38 against the confident claim at message 6. Stale claims resurrect.

No verification surface. Even if everything in the transcript were true, the new AI has no independent way to confirm any of it. It must either trust the paste or redo everything. Most of the time it picks a third option: it trusts the paste while sounding like it verified it.

The fix is not a better paste. It is a different artifact entirely.

The protocol: export, bundle, verify, continue

Here is the playbook. It works whether you are switching models, switching tools, or handing work from one agent to another.

Export. Before the handoff, ask the current AI to produce the four components above as a structured summary. Be explicit: "List the current goal and constraints. List every approach tried, what was observed, and why each was abandoned. List every verified intermediate result with how it was verified. State the single next step." Review this output yourself. You are the last human checkpoint before fiction crosses the boundary, so read it like an auditor, not a fan.

Bundle. Assemble the export into one document with a fixed structure. Here is an illustrative example for a debugging handoff (values are placeholders, the structure is the point):

handoff:
  task: "One-sentence current goal"
  constraints:
    - "Do not modify the payment path"
    - "Fix must work on the current production data shape"
  ruled_out:
    - attempt: "Raised the connection pool limit"
      observed: "Latency unchanged; p99 moved 2ms, within noise"
      abandoned_because: "Pool was never saturated; metrics showed idle connections"
  verified_results:
    - claim: "The slow query is the order-history join"
      how_verified: "EXPLAIN ANALYZE on production replica, 2026-09-23, 800ms of 950ms total"
      receipt: "<verifiable receipt id or link>"
  next_step:
    action: "Add the composite index on (user_id, created_at) and re-run EXPLAIN ANALYZE"
    pass_means: "Join time drops below 50ms"
    fail_means: "The join is not the bottleneck; re-examine the sort stage"

The exact format matters less than the discipline: every claim carries its verification, every dead end carries its reason, and the next step is a decision procedure, not a vibe.

Verify. This is the step everyone skips, and it is the whole game. Before the new AI acts on the bundle, it should re-verify the cheapest decisive claim in it. In the example above, that means re-running the EXPLAIN ANALYZE, not trusting the pasted number. A handoff bundle is a set of leads, not a set of facts, until the receiving side confirms them. One confirmed anchor is worth ten pasted claims, because it tells you the bundle is grounded in the same reality you are looking at.

Continue. Only now does the new AI start working, and it works from the verified anchor outward. As it completes steps, each one should produce its own checkable record, so the next handoff, if one comes, inherits a chain of verified results instead of a longer story.

The receiving side has a job too

Continuity is a two-sided protocol. The AI that receives a handoff should be prompted to act like a skeptical colleague, not an eager intern. Three instructions make an enormous difference:

1. "Before proposing anything, re-run the verification for the cheapest decisive claim in this bundle and report what you found."
2. "Treat every claim without provenance as unconfirmed. Mark them as such instead of building on them."
3. "If a claim fails re-verification, stop and tell me before continuing."

The first AI's job is to export honestly. The second AI's job is to verify before it trusts. When both sides do their job, a cross-AI state handoff stops being a leap of faith and becomes a relay with a baton you can inspect.

Receipts, logs, traces: pick the right evidence

One subtle point worth getting right. When people talk about "keeping records" of agent work, they usually mean one of three different things, and handoffs need the strongest one.

A trace shows how a request flowed through a system. Useful for debugging, useless as handoff evidence, because it describes the machinery, not the conclusion. An audit log is a chronological record of events inside one system's boundary. Useful for governance, weak for handoffs, because the receiving AI sits outside that boundary and cannot interrogate the log. A verifiable receipt is a stable, self-contained record of one completed execution: the request, the tool activity, the observed result, the timestamp, and the integrity material that lets anyone check it without replaying the original session. That last property is exactly what a handoff needs, because the receiving AI was not there.

If you want the full factual breakdown of when to use which, this comparison of execution receipts versus audit logs versus traces lays it out cleanly: https://zambo.dev/compare/

The practical rule: put a verifiable receipt behind every "verified result" in your handoff bundle. Then the receiving AI is not trusting your summary. It is checking a record.

What cross-AI continuity actually is

Strip away the marketing language and the definition is simple: cross-AI continuity is the ability to move a task's checkable state from one AI to another without losing what was proven. Not the conversation. Not the vibe. The checkable state.

That is why longer context windows will never solve it. A bigger window lets you paste a longer story. It does nothing to separate what was verified from what was merely said. Continuity is not a memory problem. It is an evidence problem.

And it compounds. Every handoff that preserves verified state makes the next handoff cheaper, because the bundle accumulates confirmed anchors instead of accumulating narrative. Teams that hand work between AIs regularly should treat their handoff bundles as assets: versioned, receipt-backed, and re-verifiable. The organizations that figure this out first will be the ones that can actually run long tasks across many models instead of restarting every time the context fills up.

Checking the work, on either side

None of this requires exotic tooling. The verification step in the protocol can be as simple as re-running a command and comparing output. But if you want to go further, if you want to check what an AI agent actually did rather than what it said it did, there is a real category of tools for that now: receipt verifiers, transcript scorers, execution auditors. I keep a current list of what exists here: https://zambo.dev/answers/what-tools-verify-ai-agent-work/

Use them on both sides of the handoff. Verify the first AI's results before you bundle them. Verify the second AI's continuation after it lands. The handoff is only as strong as the weakest unverified claim in it, and the tools to find that claim exist.

The one-paragraph version

Switching AIs mid-task without losing context is not about pasting more conversation. Export the four things that matter: the current goal with constraints, the ruled-out paths with reasons, the verified results with provenance, the concrete next step. Bundle them in a fixed structure. Make the receiving AI re-verify the cheapest decisive claim before it acts. Back every verified result with a verifiable receipt. That is the whole playbook, and it works today, with the models you already have.

I build tools for checkable AI work at zambo.dev. Every API call returns a verifiable receipt, so the next AI in the chain can prove what it inherited instead of trusting a paste. Free to try, no account needed.