TL;DR
Structured handoff state is a short block with four sections: decisions made, current facts, actions already completed, and remaining work. You write it before handing unfinished work to another model or a fresh session. The researchers compared three ways of passing context at the same text length: the last messages of the conversation, a prose summary, and a structured block. The structured block beat both.
The core pain is that the new model doesn’t know what’s already been decided and done. A chat tail cuts off the beginning, so a user’s choice or an already executed operation falls out of frame. The model asks again, repeats the action, or circles back to a rejected option. The bigger surprise: a prose summary did worse than the raw chat tail. In a polished, coherent narrative, the concrete “what we chose” and “what’s already done” get lost.
The method is simple: before the handoff, explicitly break the state down into fields. Crucially, stale values must be replaced by new ones, not left lying side by side. That’s one extra request or one rule in the agent’s instructions. But the gains are uneven: on one of the six models, some tasks actually got worse.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1 (at the end of the first model's or session's work):
Build a state block from the history → 4 sections:
DECISIONS / CURRENT FACTS / DONE / REMAINING
STEP 2 (new model or session):
Receives the block + its task → continues with the block in mind:
doesn't reverse decisions, doesn't repeat what's done, doesn't use stale data
Step 1 is a separate request (it can be the same model that did the work). Step 2 is a new chat or session. In the study, the block was built by a separate model, GPT-4.1, from the visible history.
Example in Practice
Task: You’ve spent three hours in Claude Code wiring up Stripe payments for a barbershop’s WhatsApp booking bot. The context has ballooned, and it’s time to open a fresh session. If you just copy over the last few messages, the new session won’t know that you dropped polling in favor of webhooks or that the database migration has already been applied.
Prompt (in the old session, before closing it):
I'm handing this work off to a new session that won't see our conversation.
Put together a state handoff block strictly by section:
<Decisions>
Everything we've locked in that can't be revisited without my say-so
(for example: webhooks instead of polling, amounts stored in cents).
</Decisions>
<Current_facts>
Current values. If something changed along the way, give only the
new value; don't mention the old one.
</Current_facts>
<Done>
What's already completed and doesn't need repeating: modified files, applied
migrations, passing and failing tests, failed attempts and why
they didn't work.
</Done>
<Remaining>
What's not done yet, open questions, working hypotheses
(mark them: "hypothesis, unverified").
</Remaining>
Only facts from our work. Don't make anything up.
If a section is empty, write "none".
Result: The model produces a compact four-section block with specifics: file names, migration status, which test is failing. You paste the block as the first message in the new session and write “continue from the Remaining section.” The new session doesn’t re-ask about webhooks and doesn’t try to apply the migration a second time.
Why It Works
Weakness: a model handed a truncated history sees only what’s in the window. Decisions and completed actions from the start of the conversation simply don’t exist for it. A prose summary makes things worse: there’s no boundary between “decided,” “tried,” “done,” and “thinking about.” The model reads it all as general background and may mistake a rejected option for the current one.
Strength: models are good at reading explicitly labeled information and following it. If it says “this is locked in” and “this is already done,” the model takes that into account in its next steps. Structure turns implicit state into a set of checkable statements.
How the method exploits this: the four sections separate, by role, what the conversation jumbles together. “Decisions” are constraints, “Done” guards against repeats, “Current facts” guards against stale values, and “Remaining” is the entry point.
Control levers:
- Sections: add a section tailored to your work, e.g. <Output_format> for report fields. In the study, for tasks with a file report, the state was built with the required output fields in mind.
- The “hypothesis, unverified” tag: removes the risk that the recipient treats a guess as fact.
- “Only the new value”: the main lever against stale data.
- Length: in the study, the block was no longer than the other variants. Bloat it, and the token-for-token advantage disappears.
Prompt Template
The authors’ exact prompt isn’t given in the available part of the paper. The template below is built from their description: “facts, commitments, prior actions, and remaining work.”
We're handing unfinished work to another executor ({model_or_session})
who won't see our conversation. Put together a state block for the task: {task}.
<Decisions>
What's locked in and can't be revisited without explicit consent.
Format: "decision — who made it and when".
</Decisions>
<Current_facts>
Current values of key parameters: {which_parameters}.
If a value changed, give only the latest one. Don't carry over old ones.
</Current_facts>
<Done>
Completed actions that shouldn't be repeated: {what_counts_as_an_action}.
Include failed attempts with the reason.
</Done>
<Remaining>
Unfinished steps and open questions. Mark unconfirmed assumptions
"hypothesis, unverified".
</Remaining>
Rules: use only what's in the history. Don't make things up.
Empty section → "none". Length: no more than {word_count} words.
What to plug in: {task} — the name of the job; {which_parameters} — things that can change (amounts, deadlines, addresses, versions); {what_counts_as_an_action} — operations with consequences (an applied migration, a sent email, an updated shipping address on an order).
🚀 Quick start — paste into the chat:
Here's a template for a state handoff block. Adapt it to my task: {your task}.
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask which parameters change as you work and which actions are irreversible. That shapes the “Current facts” and “Done” sections, which is exactly where the method protects you from stale data and repeated operations.
Limitations
⚠️ Full history is still better: if the whole conversation fits in the window, pass it along. The structured block beats the tail and the summary at equal length, but not the full text.
⚠️ Uneven effect: the gain depends on the model. One of the six actually dipped on average and lost about nine points on tool operations. Test the block on your own recipient model instead of trusting the average.
⚠️ Not a silver bullet: even with a structured block, the recipient fully meets all criteria in only about half of the tasks. When the model was given a reference state, the result rose to 85%. So the main headroom lies in the quality of the block, not just in having one.
⚠️ It won’t recover what was never there: when locating the right files in a codebase, absolute scores stay low. The block helps recall what was seen but doesn’t replace a fresh search.
⚠️ Tested on limited material: the block was built automatically by a single model, and continuation was tested on synthetic scenarios. The comparison with prose was done on one model. The exact block format isn’t shown in the available part of the text.
How They Studied It
The idea was to test the handoff itself, not just the final outcome. The authors assembled 1039 tasks of two kinds. The first 300 are real traces of a coding agent working across 38 repositories, cut off after ten steps, where the new model has to find the right files and lines of code. The remaining 739 are synthetic: a conversation where some decisions stay in force and some facts get updated; an order service with operations already executed; a progress report on work with files. Scoring used binary criteria: did the recipient preserve the decision, account for the new fact, avoid repeating what was already done.
Six recipient models (GPT-5.4, Claude Sonnet 5, DeepSeek V3.2, Qwen 3.5 Plus, Gemini 3.5 Flash Lite, Kimi K2) received the same history. The context was passed in three forms at the same token count: the chat tail, a prose summary, and a structured block. This setup rules out “they just got more text.”
Results. Code search: for GPT-5.4, the structured block raised line-F1 from 0.075 to 0.229, and all six models improved. The gain peaks (0.132–0.189) when the needed files have already dropped out of the chat tail. Continuing the work with GPT-5.4: mean score 89.73 (tail), 87.34 (prose), 92.76 (block), 94.51 (full history); full completion of all criteria 44.7 → 42.8 → 52.1 → 57.9%.
What was surprising. First, prose is worse than the raw tail. Second, the leaders differ: Claude and Gemini are best at finding code, while GPT-5.4 is better at continuing the work. Third, the gains didn’t line up across models: of the 300 search tasks, the block helped at least one model in 231, but all six in only 91. In practice, this means you should test your choice of recipient and the block format together.
Adaptations and Extrapolations
🔧 Technique: automatic handoff → a HANDOFF.md file via a rule in CLAUDE.md
Instead of remembering to write the block by hand, bake the rule into the agent’s instructions:
When the context is more than 70% full or I write "handoff":
write a block with the sections Decisions / Current_facts /
Done / Remaining to HANDOFF.md. In "Current_facts" keep only the latest
values. At the start of a new session, read HANDOFF.md first.
This is my adaptation: the study tested passing the block, not a rule for writing it to a file.
Extrapolation: checking the recipient’s understanding. In the study, continuation was checked via a state report (what’s decided, what’s done). You can use the same trick in practice: after pasting the block, ask the new session to restate its understanding before it starts working.
Read the state block. Before acting, list in your own words:
1) which decisions can't be changed, 2) what's already done and won't be repeated,
3) what the next step is. Wait for my "yes".
Any mismatch in the restatement immediately shows that the block was put together inaccurately.
Resources
- Benchmarking Task Takeover Across Agent Handoffs (HSC-Bench, Handoff State Continuity Benchmark)
- Authors: Wenyuan Li, Guang Li, Dongyuan Li, Keisuke Maeda, Takahiro Ogawa, Miki Haseyama — Hokkaido University, The University of Tokyo
- Related work cited in the paper: ContextBench, CodeTraceBench, LongMemEval, τ-bench, SWE-bench