Handoffs that write themselves
By Soumen Sarkar · October 2026
Playbook. Make stopping the trigger and the agent the writer: a handoff of what's done, what's left and what to watch for, every time work stops.
How do you get handoffs that write themselves?
Make stopping the trigger, and make the agent the writer. Whenever a session stops before the work is finished, the agent writes what's done, what's left, the next step, the open questions and the traps, and leaves it where the next person or agent will start. Nobody has to remember to write it, and nobody has to come and ask.
That's the sixth VibeFlock principle: our work explains itself, so nobody ever has to come and ask us. The agent that did the work already knows all five things at the moment it stops. A few minutes later, nobody does. A handoff written at that moment costs almost nothing, and saves the next session from starting cold.
Who is this for, and what do you get?
It's for teams where work regularly passes between sessions and people: a session that runs out of context, a teammate who finishes for the day, work that continues across time zones, a weekend of agents running unattended. It works with any agent that can follow instructions and write to a shared place.
What you get:
- Unfinished work that anyone can pick up, at any hour, without a message to its author.
- A next session that starts on the next step, not on rediscovering the last one.
- Traps written down once, by the agent that fell into them.
- A clear moment when work changes hands, so nothing sits ownerless.
What does a good handoff say?
Five things, in plain words, short enough to read in a minute. The handoff template has the shape; here's one filled in for a hypothetical change in Notifications · lib/notifications:
Handoff: send daily digests from a queue instead of one nightly job
Done: digests are queued per user and sent by the new worker;
tested with 500 fake users.
Left: retry on a bounced email; remove the old nightly job.
Next step: add the bounce check in sendDigest(), then delete the job.
Open questions: assumed users who unsubscribed in the last hour
are skipped. Not confirmed.
Watch out for: the worker reads the user's timezone from settings,
not the profile. The profile field is out of date for older accounts.
Where: branch digest-queue · lib/notifications/worker.ts
The most useful line is often "watch out for". It's the thing the next session would otherwise spend an hour discovering.
The steps
- Agree the five parts. Done, left, next step, open questions, watch out for, plus where the work lives. Same order every time, so anyone can skim them.
- Make stopping the trigger. The instruction is "whenever you stop before the work is finished", not "at the end of the day". That covers a session ending, a session about to compact its context, and a person saying "let's pause here".
- Let the agent write it. The agent has the whole session in front of it. A person writing from memory leaves out the traps. Ask the person only to read it and fix anything wrong.
- Put it where the next session starts. One place the whole team uses: the pull request description under "Handoff", a note in the area, or a shared record agents read at the start. A handoff in a private terminal helps nobody.
- Make picking it up explicit. When someone continues the work, they say so, and it's theirs from then on. Two people quietly continuing the same handoff is how work gets done twice.
- Start the next session with it. The first instruction to the agent continuing the work is to read the handoff and begin at the next step.
- Finish with an outcome. When the work lands, the last note says what it turned out to be compared with the plan. That's what the next person reads in the area's history.
Which moments count as stopping?
More than most teams think. Each of these is a moment when what the session knows is about to be lost, so each is a moment for a handoff:
- The session ends. The person closes the terminal, or the agent finishes its turn and nobody comes back.
- The context is about to be compacted. A long session summarises itself to keep going, and detail is lost in the summary. A handoff written just before keeps the traps and open questions that a summary drops.
- A person steps away. Lunch, a meeting, the end of the day. If the session might sit for hours, it should leave a handoff before it sits.
- The work changes owner. Someone else is better placed to finish it, or it moves to another time zone.
- The plan changes. The agent discovers the approach won't work and stops to rethink. What it learned is worth more than what it built.
A session that only read code, or answered a question, has nothing to hand off. Don't ask for one; a handoff with nothing in it trains people to skip them.
What does picking up look like from the other side?
The handoff is only half of it. The other half is the person or agent who continues, and what they do in their first minute.
Say Lena picks up the digest work above the next morning, from another time zone. She doesn't message the author. She reads the handoff, says the work is hers now, and starts a session with one instruction: read the handoff and begin at the next step. The agent adds the bounce check in sendDigest(). Because "watch out for" mentioned the timezone field, it reads the timezone from settings, not the profile, and doesn't spend the morning chasing digests that go out at the wrong hour.
The open question is still open. Lena's agent keeps building on the assumption that recent unsubscribes are skipped, and the line stays visible until someone who knows confirms it. When the work lands, the last note says what it became: digests sent from a queue, with bounce retries, and the nightly job gone.
What should you tell your agents?
## When you stop
Whenever you stop before the work is finished, including when
your context is about to be compacted, write a handoff in
<where handoffs go>:
Done: what is finished and working.
Left: what remains, in order.
Next step: the single thing to do first.
Open questions: assumptions nobody has confirmed.
Watch out for: traps, slow paths, things that look right but aren't.
Where: branch, area, key files.
Write it for someone who has never seen this session.
Leave out secrets and credentials.
When you continue someone else's work, read their handoff first
and start at its next step.
When the work is finished, say what it turned out to be.
What should you watch for?
- Transcripts posing as handoffs. A pasted log is long, and the next step is buried in it. A handoff is a summary, written for a reader.
- Vague "left" lines. "Finish the feature" tells nobody anything. "Add the bounce check in sendDigest()" is a next step.
- Missing traps. If the agent spent twenty minutes on something surprising, that belongs in "watch out for". Ask for it in the instruction.
- Handoffs nobody picks up. A handoff that sits for a day is work going cold. Someone should look at unpicked handoffs daily, even if only to say "this waits until Thursday".
- Two people picking up the same work. Make "this is mine now" a visible step, not an assumption.
- Secrets. Handoffs travel. Tokens, passwords and customer data stay out of them.
How do you know it's working?
- Pick-ups without messages. Work changes hands and nobody asks its author "where were you on this?"
- Next sessions start on the next step. The continuing agent's first action is the one the handoff named, not a tour of the code.
- Traps get avoided. The problem written under "watch out for" doesn't get hit twice.
- Handoffs are picked up quickly. Unfinished work doesn't sit for days. How long it waits is the pick-up time, and it's worth watching.
- Mornings are quiet. People start the day by continuing work, not by catching up on it.
What does Campfyrr automate?
In Claude Code, Campfyrr writes the handoff from the session, so neither the person nor the agent has to remember.
- Written when work stops. When a session stops, compacts or ends, the hook writes a handoff from the session: done, unfinished, next step, open questions and traps. The transcript itself isn't kept. A session that only read code and changed nothing leaves no handoff.
- Waiting at the top of the next session. Each person's next session brief opens with "Pick up where it was left": their own unfinished work and handoffs to them.
- Shown to the team. In the project's Activity feed, a handoff shows as work paused partway, with its next step. To take over a teammate's, paste it into your first prompt, and your agent starts from it.
- Nothing goes cold unnoticed. Paused work stays in the feed until someone continues it, and the "What Campfyrr caught for your team this week" card on Activity shows how many handoffs were picked up, and how fast.
- Finished work says what it became. An agent calls
finish_work with the outcome, and the work shows as landed, with what it turned out to be.
Codex, Cursor and other clients call hand_off themselves, following the instructions the server gives them. For the questions people ask most, see how an agent hands off unfinished work and how to continue another developer's agent session.
A handoff is the last thing a session does and the first thing the next one reads. When it's written at the moment of stopping, by the agent that knows, the work never has to wait for anyone to explain 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).