What makes a good handoff from an AI agent?
By Soumen Sarkar · October 2026
Short answer: A good handoff lets the next person or agent start within a minute without asking anything: it is specific about what's done and what isn't, names one concrete next step, and records the assumptions and traps that aren't visible in the code.
What is the test of a good handoff?
The test is simple: could someone who has never seen this work continue it without asking the person who started it? If they'd have to send a message, the handoff isn't finished. The work speaks for itself only when everything the next person needs is written down, and nothing they don't need gets in the way.
What separates a strong handoff from a weak one?
Five qualities, in rough order of how often they're missing.
- Specific, not general. "Mostly done" tells the next person nothing. "Parser handles dates and amounts; currency codes not yet" tells them exactly where to start.
- One next step. Name the single thing to do first, concrete enough to act on. A list of five options hands the decision back to someone who has less context than you.
- What the code can't show. The next agent can read the code. It can't read why you chose this approach, what you assumed or what you tried and dropped. That's what the handoff is for.
- Traps named outright. If something looks right but isn't, say so. A trap you found and didn't write down is a trap the next session falls into.
- Short. It should fit on one screen. A handoff that takes ten minutes to read has moved the work from the code into the note.
What does that look like side by side?
Say an agent is moving file uploads to direct-to-storage in Uploads · lib/uploads and its session ends partway through.
A weak handoff:
Worked on uploads. Made good progress, a few things left.
Some tests failing. Check the storage stuff.
A strong one:
Done: signed upload URLs are generated and tested (lib/uploads/sign.ts).
Unfinished: the browser still posts to the old endpoint.
Next step: switch the upload form to request a signed URL first.
Assumed: URLs expire after 15 minutes. Not confirmed.
Trap: the two failing tests use the old endpoint on purpose;
delete them once the form is switched, don't fix them.
The second one can be continued in a minute. The first one starts with an hour of reading and probably a message to someone who's now asleep. Notice the trap: without it, the next agent would "fix" the failing tests and undo the move.
When should the handoff be written?
Every time a session stops, not just when it finishes. The unplanned stops matter most: the context filling up, a laptop closing, a developer switching to something urgent. Put the instruction in the agent's standing instructions: "Before you stop for any reason, write a handoff with done, unfinished, next step, assumed and traps." The handoff template gives the shape, and how an agent hands off unfinished work covers where it should go.
How do you know your handoffs are good enough?
Watch pick-up time, how long unfinished work sits before someone continues it, and listen for the follow-up question. If people keep asking "what did you mean by this?" after reading handoffs, the handoffs are too vague. In Claude Code, Campfyrr writes the handoff from the session itself in this shape when it stops, so the habit doesn't depend on anyone remembering.
Words used here
- Handoff: A handoff is what unfinished work carries for whoever continues it: what's done, what's left, the next step, and what to watch out for.
- Pick-up time: Pick-up time is how long a handoff waits between being left and someone picking it up to continue the work.
- Assumption: An assumption is the best available answer to an unknown, stated and acted on, kept visible so anyone can correct it.
The principle behind this: Let the work speak: Our work explains itself, so nobody ever has to come and ask us.
Move as one at agent speed. Nobody waits. Add Campfyrr to Claude: it briefs every agent before it touches the code, keeps assumptions and handoffs where the team can see them, and never takes your code (what it keeps).