A Deliberate Handoff Beats Automatic Compaction
Compaction keeps a general summary that the tool chose. A handoff document keeps what I decided the next session needs. They solve different problems, and the handoff is the one worth writing by hand.
Every long agent session reaches the same point. The context window fills, the answers get vaguer, and something has to give. Claude Code's built-in answer is compaction: /compact, or an automatic version of it when the window is nearly full. The harness summarizes the conversation, drops the original, and carries on from the summary.
That is convenient. It also makes a decision on my behalf. Something has to choose what the next stretch of work needs to know, and with compaction the chooser is a summarizer that has no idea what I plan to do next.
The alternative is a handoff document: a short markdown file, written on purpose, that a fresh session reads first. Matt Pocock added a /handoff skill to his public skills repo this month and then spent a twelve-minute video on why it is built the way it is.
What compaction keeps
Pocock describes the compact summary as a small block injected at the start of the new session: the files that were referenced, the things the user said, the general tone. Compact again later and the new summary is built on top of the old one. He calls the buildup "sediment".
He is not against it. His example is debugging. Summarize the options already tried, keep trying new ones, hit the wall, compact again. There is one problem and one thread, and the summary only has to preserve what has been ruled out.
The limit is structural. Compaction produces exactly one continuing session, and its summary is general purpose. It gets written without knowing whether the next hour is more of the same work or a turn toward something else.
What a handoff keeps
Pocock's motivating case is the mid-session tangent. Partway through planning he spots a refactor or a bug that is out of scope. Continuing in the same session dilutes the context. Compacting clobbers the progress he has. So he takes only the slice that matters to the side task, writes it to a file, and opens a second session on it. The first session stays as it was.
The detail I care about most is a small one. His skill treats any argument passed to it as a description of what the next session will focus on, and tailors the document to that. He says he always states the purpose. A compact summary records what happened. A handoff written this way records what the next session needs, and only the person steering knows that.
He lists four other design decisions:
- Point at existing artifacts (issues, plans, other markdown) instead of copying them in.
- Name the skills the next session should load.
- Save to the OS temp directory. The file is disposable and should not rot in the repo.
- Redact keys, passwords and personal data.
When I wrote up his changelog video earlier this month, my open question was what the skill did about secrets sitting in temp files. The last rule answers it.
Because the result is a plain file and not harness state, it also crosses tools. Pocock points out that the file can go to Codex or any other agent. He also describes a round trip: hand off to a work session, then have it write a handoff back. His example is a prototype session that grew to 169k tokens, far more than the planning session had room for.
The window is smaller than the label
All of this assumes context is scarce, and the news this month says the opposite. Nate Herk's video on Anthropic's new compute capacity reports that Claude Code's five-hour limits doubled, and argues the 1M context window is now practical for production work. The title says session limits are solved.
I think that mixes two budgets. Rate limits govern how many tokens I can spend in five hours. They say nothing about how well the model reasons deep into a single conversation. Pocock's claim is about the second budget. He says he starts to feel responses degrade around 120k tokens, in what he calls the "dumb zone". That number is his impression from daily use, not a measurement, and I would not repeat it as a threshold. I do find the direction easy to believe, and a doubled quota does nothing to change it.
What the extra quota changes is the price of the fix. A fresh session per tangent is easier to afford now.
When each is right
| Situation | Reach for |
|---|---|
| One problem, a long grind, same goal afterward | Compact |
| A tangent shows up in the middle of planning | Handoff the slice, keep the original session |
| Planning needs a prototype bigger than the remaining window | Handoff out, then a handoff back |
| A different agent should take a look | Handoff, because a file crosses tools |
| The work stops for the day | Neither. Write a durable note |
The last row is where I part ways with Pocock a little. His handoff is throwaway by design, and for a mid-session fork that is right. My own habit leans toward durable records: daily notes, compiled articles, memory files. Those are for me next week. A handoff is for the session that starts in ten minutes.
One thing I do not know yet is whether the round trip compounds loss the way repeated compaction does. Each leg is a summary of a summary, and Pocock does not address it.
What I would put in one
Purpose: what the next session is for, in one sentence
State: what is decided, what is still open
Ruled out: what was tried and why it failed
Pointers: paths and links to the plan, the issue, the files
Next step: the first concrete action
Skills: which skills to load
Purpose, pointers and skills are Pocock's rules. Ruled out and next step are my additions, borrowed from what he says compaction does well in a debugging loop.
Key Takeaways
- Compaction extends one session with a general summary. A handoff forks a scoped slice into a new session and leaves the original alone.
- I state a handoff's purpose, so it is written for the next task and not the last one.
- Compact for a long single-purpose grind. Hand off for tangents, oversized side quests and cross-tool review.
- Higher rate limits make fresh sessions cheaper. They do not make a full window reason better.
Sources
- Matt Pocock, "/handoff is my new favourite skill"
- Matt Pocock, "New Skills! /handoff, /prototype, /review and /writing-* | Skills Changelog"
- Nate Herk, "Claude Just Solved Session Limits"
Next for me: port the handoff skill into my own library and try it the first time a planning session runs long.