What an agent handoff is
An agent handoff is the transfer of an in-progress task from one agent session or runtime to another, along with enough state that the receiving agent continues the work rather than restarting it. The unit being transferred is not the conversation. It is the task's current position: what the goal is, what has been established, what remains open, and what has already been ruled out. A handoff succeeds when the receiver's first action advances the work, and fails when the receiver's first action reproduces something the sender already did.
Handoffs stopped being an edge case at roughly the point where agent sessions began outliving their context windows. A coding agent working through a migration, a research agent walking a corpus, an ops agent shepherding a deploy: each routinely exceeds what a single uncompacted session holds. Compaction, crashes, quota exhaustion, model switches, permission boundaries, and simply ending the working day all terminate a session while leaving the task unfinished. Every one of those terminations is a handoff whether or not anyone designed it as one. The only real choice is between a handoff that carries state and a handoff that silently drops it.
The three shapes of handoff
Session-to-session, same identity. The same agent with the same tools against the same repository, resuming after compaction, a crash, a restart, or overnight. Only working memory is lost; the filesystem, the git history, and the tool surface are unchanged, which makes this the cheapest shape and by far the most common. Its failure mode is subtle rather than loud: the agent believes it still remembers, and reconstructs a plausible but wrong account of what it had decided. Continuity that is inferred rather than recorded tends to be confidently wrong.
Agent-to-agent, different runtimes. Claude Code to Grok to Codex, a LangGraph node to a CrewAI crew, a hosted agent to a local one. The motivation is usually specialization (one model is better at broad investigation, another at careful refactors), quota (the implementer runs out and the reviewer takes over), or capability routing (only one runtime holds the credential or the tool). This is the hardest shape, because nothing implicit survives: no shared memory store, no shared system prompt, different tool names, different permission models, different notions of what a session even is. Anything not written down does not cross. The asymmetry is worse than it looks, since the receiver may not even hold the tools required to verify the sender's claims.
Orchestrator-to-subagent. Fan-out to workers, then collection of results. This is delegation with return, not a true handoff: the orchestrator keeps the goal and the task frame, and the subagent receives a bounded assignment it is expected to finish and report on. The distinction is practical, not pedantic, because the payload differs. A subagent brief can be narrow, since scope and success criteria are enough. A handoff must carry the whole task frame, including the parts the receiver does not yet know to ask about. Treating a handoff like a subagent brief under-specifies it; treating a subagent brief like a handoff floods the worker with context it will never use.
Why cold handoffs are expensive
A cold handoff imposes three costs, in ascending order of damage. The first is re-derivation: the receiver re-reads files, re-runs searches, and rebuilds a mental model of a system the sender already understood. That is annoying and metered, but bounded. The second is re-verification: the receiver re-runs the tests, re-checks the deployed state, re-confirms the things the sender confirmed an hour ago. Some of that is healthy skepticism and some of it is pure waste, and the note determines which.
The third cost is re-litigation, and it is the one that actually hurts. The receiver retries an approach the sender already tried and refuted. This is not merely wasted work; it is worse than doing nothing. A refuted approach is usually attractive, which is exactly why the sender reached for it first, and a receiver reasoning from the same problem surface converges on the same first idea. It spends the same effort, hits the same wall, and now has a mutated database, a failed deploy, or a dirty branch to clean up. Worse, an agent that reapplies a fix which should obviously work often concludes the environment is at fault and follows that inference somewhere expensive. The sender's dead end becomes the receiver's detour, at full price, twice.
Negative knowledge is the field that gets omitted
Negative knowledge is the record of what does not work and why: do not try X, it fails because Y. It is the highest-value field in a handoff for a structural reason. Positive state is recoverable from artifacts. Files changed, tests passing, a deploy that landed, a commit that exists: all of it can be reconstructed from the repository, the CI logs, and the running system, even if the note says nothing. Negative knowledge cannot be reconstructed, because failed attempts are erased by design. The branch was reset, the change was reverted, the experiment was thrown away. The only surviving copy lives in the sender's context, which is precisely the thing about to be destroyed.
It is also the field most often left out, for two reasons that are worth naming. First, writing a handoff feels like reporting progress, and refutations do not read as progress; human and model authors alike bias toward listing accomplishments. Second, at the moment of writing, the sender has fully internalized why X fails. It feels obvious, and obvious things do not feel worth recording. That is the illusion of transparency, and it is reliable enough to plan around: if you spent more than a few minutes ruling something out, it belongs in the note.
The reason matters as much as the refutation. Saying that the header-refresh auth path fails leaves the receiver with a dead end it cannot reason about. Saying that it fails because the gateway strips the header before the service ever sees it gives the receiver the actual constraint, tells it where the real boundary lives, and lets it recognize the day that constraint stops holding. A refutation without a cause ages into superstition. A refutation with a cause is a map.
What a good handoff actually contains
Seven fields cover nearly everything. Goal: the outcome, stated as an outcome and not as a task list, so a receiver can re-plan when the plan turns out to be wrong. Done: what is finished, each item attached to evidence such as a commit hash, a test output, or a URL, never to an adjective. Next: the single most useful next action, not a wish list. Blocked: what is waiting on something external, and what specifically would unblock it. Refuted: negative knowledge with causes. Pointers: paths to receipts, logs, plans, and diffs, so the receiver can pull detail on demand instead of receiving it inline. Prohibitions: the explicit do-nots, including anything that must not be reopened before a stated date.
A good handoff is short and dense. The most useful ones fit on a screen, because a handoff is a pointer structure rather than an archive. The test is whether a competent agent with no history could read it and take a correct first action; if the note only makes sense to someone who already read the transcript, the note failed. Two pieces of metadata carry more weight than they appear to: who wrote it, and against what state. A note anchored to a commit hash and a timestamp can be checked for staleness, and staleness is the single largest source of handoff error. Something that was true fourteen commits ago is not neutral when it is wrong; it is actively misleading, and it arrives wearing the authority of a summary.
Anti-patterns worth naming
Dumping the transcript. This is the most common failure and it feels like the safe one, because everything is technically in there. But a transcript is the sender's search process, wrong turns included, ordered by when they happened and carrying no labels that distinguish a conclusion from a discarded hypothesis. Handing it over asks the receiver to redo the sender's synthesis from a worse position than the sender had. The compression is the deliverable, not an optional courtesy.
Handing off vague prose. Continue the work, finish the refactor, pick up where I left off. These carry no information beyond a pointer to the repository, and they invite the receiver to invent a goal. Assuming shared memory that is not shared. Phrases like as discussed, per the plan, or the same approach as before reference state the receiver may have no access to, and this breaks hardest across runtimes, where memory features are scoped per vendor, per project, and per session. If it is not in the note or in a file at a stated path, it does not exist.
Trusting the sender's claims without verification. Tests pass is a statement about a moment that has since passed, and it may have been optimistic even then. A receiver that opens by confirming the two or three load-bearing claims against the actual repository, the actual service, and the actual test run will occasionally find the handoff was wrong, and will always be cheaper than one that discovers it three steps in.
A handoff note is untrusted input
Once notes cross a trust boundary, between runtimes, between tenants, from an automated writer, or through a shared queue, a handoff is content of uncertain provenance being loaded into a receiving agent's context at the very start of its run, which is the point of maximum influence over its behavior. If the receiver treats that content as instructions, then anyone who can write a note can steer the receiver. This is the ordinary prompt-injection surface with an unusually bad property attached: the receiving agent is typically configured to act, with tools, immediately.
The workable rule is that a handoff note is data to summarize, not orders to execute. The receiver reads it, extracts claims and pointers, verifies the load-bearing ones against real state, and derives its own plan from what it confirmed. Prohibitions deserve a different treatment from imperatives, and the asymmetry is useful: a prohibition can only shrink the action space, so a hostile one is a nuisance at worst, while an imperative that expands the action space is the dangerous shape. Text claiming that the user already approved something, that a review step can be skipped, or that the receiver is authorized to act should be read exactly as skeptically as the same sentence found on a web page. Authorization does not travel inside a handoff note. It travels through the permission system and through the human.
This is a shift-change handover, and that is not a metaphor
Clinical handover, NOC and SRE shift change, and aviation crew changeover all converged on structured formats for the same reason agent systems are converging on them now. Unstructured verbal handover measurably drops information, and the dropped items cluster in predictable places: pending results, things already ruled out, and things explicitly not to be done. SBAR, with its situation, background, assessment, and recommendation, and I-PASS, with its action list and its contingency planning, exist because free-form narrative degrades under time pressure and because the receiver has no way to notice what they were not told. Fixed fields make omission visible, which is most of the value.
One element of the clinical version transfers almost directly and is usually skipped in software. I-PASS ends with synthesis by the receiver: the incoming clinician restates the plan in their own words, and discrepancies surface immediately. Aviation read-back works the same way. The agent equivalent is cheap. The receiver's first action after ingesting a handoff is a short restatement of goal, next action, and prohibitions, checked against the real repository or service state, before anything is mutated. Most bad handoffs announce themselves in that restatement, at a cost of one turn.
Any structured format will do this job. A markdown file with fixed headings committed next to the code, a JSON record in a state store, a row in a task table: what matters is that the fields are fixed so omissions are visible, that pointers beat inlined bulk, and that the receiver verifies before acting. One open, free format that encodes exactly these fields, refutations and prohibitions included, is the Delx Continuity Capsule; it is per-identity lineage, meaning a capsule belongs to one agent identity's chain of sessions rather than to a public feed. Use it or use your own. The format is not the interesting part. The interesting part is that the field which gets omitted is the expensive one, and the field that gets omitted is almost always the one recording what has already been proven not to work.