TL;DR
When one coding agent stops mid-change and another takes over, the note it leaves mixes what it checked, what it guessed and what someone agreed, all in the same confident tone. Freeze the unfinished diff in a commit, list which checks passed, failed or never ran, and label every other claim as observed, inferred or decided. The receiving agent re-derives observations, tests inferences before building on them and treats only recorded decisions as settled, so a later error can be traced to the line that caused it.
Three sentences that look equally true
Here is the kind of note a coding agent leaves when it runs out of time or usage halfway through a change. It is illustrative, not taken from a real session.
The first line came from a test run. The second is the agent's best guess after reading one stack trace. The third was agreed with a product owner last week. On the page they have the same weight, and a second agent reading them has no way to tell which one it may build on.
On 30 September 2026 someone asked on Hacker News how others switch to another agent when they hit a usage limit, Codex to Claude Code and back, without losing the task in progress. In June, a developer who moves between Claude Code, Codex and Cursor asked on the Cursor forum how to stop an agent's unchecked guess from being treated as fact by the next tool. They had found invented details stored next to things they had confirmed, in the same shape and with the same weight. Both authors also mention or promote a tool of their own; the questions stand without it.
Why confidence travels and evidence does not
A summary keeps conclusions and drops how they were reached: the receiving agent sees "is a timing problem" and not "I read one stack trace and did not reproduce it".
Research on multi-agent systems describes the same failure inside automated pipelines. A taxonomy built from more than 1,600 annotated traces across seven frameworks (Cemri et al., MAST) groups its fourteen failure modes into system design, inter-agent misalignment and task verification. Misalignment includes withholding information another agent needed and failing to ask for clarification when data is incomplete; verification includes checking incompletely or not at all. Those are research frameworks such as ChatDev, not one person moving a branch between tools; treat the parallel as a warning, not a measurement.
The Cursor thread produced a useful distinction. A test result can be re-run cheaply, so it stays valid while the test stays green. A person's yes cannot be re-run without asking them again. An agent's own reasoning is a guess until something outside the agent confirms it. One reply summed up the role of version history as "Git as a staleness trigger, not a truth oracle": it tells you something changed since a claim was made, not that the claim was ever true.
Freeze the unfinished work before you describe it
"My changes" is not something the next agent can inspect. A commit is. Before switching tools:
- Commit the work in progress on the feature branch, or on a handoff branch if your team keeps the feature branch clean, with a message that says it is incomplete. Include untracked files you mean to keep. The note then refers to one hash, and the receiver can diff it against the base.
- List incomplete edits by file. For each, say what exists and what is missing: "handler written, error mapping not started", not "mostly done".
- Say what was deliberately left alone, and why. A migration skipped pending a decision looks like an oversight unless the note says otherwise, and the next agent may helpfully write it.
- Give every check one of three states. Passed, with the command and the commit it ran on. Failed, with the command and the test names. Not run, with the reason: no database in that sandbox, ran out of time, not yet relevant.
"Not run" is the line most handoffs leave out, and its absence reads as "passed". The article on verifying that an AI agent actually ran the checks it says passed covers what a credible record of a run contains. The article on what to save for a new AI coding session covers what Git shows and misses.
Label every claim the next agent might rely on
Everything that is not the diff or a check result is a claim. Give each one a label in the line itself, so a line copied into a prompt carries its label with it.
Comparison
| Label | What it means | What the line must carry | What the receiving agent does |
|---|---|---|---|
| Observed | Seen in output, a file or a run | The command or file, the commit and the time | Re-runs it or spot-checks it before relying on it |
| Inferred | The writer's reasoning, not yet confirmed | The reasoning, and what would prove it wrong | Tests it before building on it |
| Decided | Agreed by someone entitled to decide | Who decided, when, and where it is recorded | Treats it as settled, after confirming the record exists |
| Open | Not known | The question and who can answer it | Asks, rather than guessing |
One rule keeps the labels honest: no agent promotes a claim by restating it. An inference becomes observed when a check confirms it and the command and output are recorded, whoever ran the check, and decided when a person agrees and the agreement is written where the team keeps decisions. A second agent repeating the claim is not confirmation; a second agent running the check itself and recording the result is.
What the receiving agent checks before its first edit
Ask the receiving agent for a report before any code: which claims it confirmed, could not check or contradicted. Then let it edit. It should:
- Confirm the starting point. The branch and commit match the note, and the diff against the base contains what the note says, no more.
- Load the project instructions in this tool. Tools read different files. Claude Code, for example, reads
AGENTS.mdonly when there is noCLAUDE.mdin the working directory or above it (Claude Code memory), so a rule the first agent followed may not reach the second. - Re-run what was failing or not run, in its own environment. A check that passed in another tool's sandbox describes that sandbox.
- Re-read every file it will change instead of working from the summary.
- Test each inference it depends on, using the disproof the note gave. If the note gave none, treat the claim as open.
- Find the record behind each decision. A decision with no record is an inference with a confident tone.
To find out whether your own process works, plant one claim you know is stale in a practice handoff and see whether the receiving agent catches it before editing. That is a suggested drill, not a reported result.
Trace a mistake back to the line that caused it
When resumed work fails, you want to know whether the handoff misled the agent or the agent ignored the handoff. That needs both kept.
- Commit the note next to the code, with numbered lines, and keep the receiving agent's reinspection report with it.
- Find the line the failed work relied on, then its label. An inference nobody tested points at the receiver's checks. An observation that was wrong points at its command or its timing. A conflict with a recorded decision has two readings: the code failed to implement the decision, which is a defect to fix in the code, or the decision itself has changed, which a person records as a new decision that supersedes the old one.
- Correct the record instead of rewriting it. Mark the line as superseded, add what replaced it with the commit hash and date, and leave the original visible.
git log -pon the note then shows what each agent believed at each point. - Downgrade similar claims. If one timing guess was wrong, other unreproduced timing guesses in the same note go back to open.
Paqad applies the same discipline between the stages of one change rather than between vendors. On the graduated and full lanes in Claude Code and Codex CLI, each stage runs in a fresh subagent that receives the change reference, the lane and the previous stage's output file instead of the conversation, and returns any decision that belongs to you as a pending request. Each ledger row records whether it was witnessed live or inferred from an artifact or Git, and whether a script proved it, a model judged it or the measure was blocked. Decisions you resolve are committed with the code. Its limits: the evidence bundle is machine-local and git-ignored by default, so it does not follow the work to another machine or tool, and reconnecting a new session to unfinished work on a branch is best-effort. Paqad's stage agent documentation explains how one stage hands its work to the next.
Frequently Asked Questions
How do I hand unfinished work to another coding agent without passing along wrong assumptions?
Hand over evidence rather than conclusions: a commit, a table of check states and labelled claims, with a reinspection report as the receiver's first output. If you can, stop the first agent at a clean seam, a finished or reverted function, because a half-written edit is the claim hardest to describe accurately.
What must the handoff say about the current diff, incomplete work and unrun checks?
Beyond the hash, file list and check states, name generated or bulky changes, such as lockfiles and snapshots, so the receiver does not mistake them for the work. Name any partial edit that leaves the build broken, so the next failure is not blamed on the receiver.
How do I label observations, hypotheses and approved decisions so the next agent does not confuse them?
Put the label at the start of each line and keep a fixed vocabulary across the team, so prompts and reviews can search for it. Ask the writing agent to list its inferences separately before it writes the note; guesses are easier to spot when it has to name them.
What must the receiving agent inspect afresh before it edits or relies on the previous result?
Anything that depends on the environment as well as the code: tool and model versions, sandbox network access, environment variables and services. An observation is true for the place it was made; the receiver confirms it holds in its own.
How can we trace an eventual error back through the handoff and correct the shared record?
Compare three things side by side: the handoff note, the receiving agent's reinspection report and the commits that followed. If the same label failure appears twice, fix the handoff template or the receiver's instructions, not just the line.