A handoff for context compaction must preserve the active objective, current constraints, decisions and their reasons, exact working state, evidence already gathered, unresolved questions, and the next safe action. It should let the next context continue the same task without guessing what “done” means or repeating an action whose outcome is unknown.
A short chronological summary can lose the one fact that matters most: the patch exists, but its acceptance test still fails. Prefer a compact account of the task’s present state, supported by recoverable evidence.
Compaction is a reduction of the live working context. Durable memory serves later tasks; a handoff serves this task’s continuation. A temporary failing test belongs in the handoff even when it has no value as a permanent memory.
Preserve the distinctions that control the next action
Anthropic describes compaction as summarizing a conversation so work can continue in a new context window, and notes the risk of losing critical details through aggressive compression. That explains the mechanism, but each workflow still has to decide what its continuation requires.
For a coding task, the important distinctions are often these:
- The requested outcome versus the current implementation.
- A decision the user accepted versus an agent’s proposal.
- A command that ran versus a check someone intended to run.
- A local result versus a remote or production result.
- A confirmed failed operation versus an operation with an unknown outcome.
- An owned edit versus an unrelated change already present in the workspace.
If those distinctions disappear, a fluent handoff can send the next session in the wrong direction. “Validation complete” is especially dangerous when it compresses a mix of passing unit tests, an unavailable integration environment, and an unrun migration check.
A handoff that sounds useful but cannot support continuation
Consider a synthetic task to preserve the CSV header for an empty export while keeping the public columns unchanged. The agent has edited the serializer and run one test. A compact note says:
Fixed CSV exports. Tests look good. Continue with cleanup and ship.
The next context cannot tell which files changed, which test ran, whether it passed, or what “ship” authorizes. The word “fixed” has replaced the actual state.
A useful handoff can remain concise while being much more specific:
Goal: Empty order CSV exports must retain order_id,total_cents header.
Constraints: Preserve integer cents and existing field order.
Authority: Local implementation and checks only; no publication/deployment.
Workspace: orders-export fixture, feature/header; inspect current Git state.
Edits: src/export.py now emits the header before iterating rows.
Unrelated state: docs/notes.md was already modified; preserve it.
Evidence: python3 -m unittest test_export -v ran 2 tests.
Result: nonempty case passed; empty case failed because newline is missing.
Evidence file: evidence/test-output.txt; applies to recorded file hashes.
Decision: Keep serializer responsible for the header; CLI passes bytes through.
Next: Inspect the failing assertion, add the missing newline, rerun both cases.
Unknown: Browser download behavior has not been tested.
The handoff does not need the entire tool transcript in the live context. It does need enough information to recover the relevant output and determine whether it still applies.
Bind evidence to the state it describes
A command and result are incomplete without their target. Tests can pass on one revision and fail after a subsequent edit. Record the branch or worktree, commit when relevant, and changed files. For uncommitted work, file hashes or a saved diff can identify the tested state more precisely than a branch name alone.
The receiving session should first inspect the current workspace. Confirm the path, Git status, and whether the evidence’s files still match. If another contributor changed the code after the handoff, preserve the useful history but re-evaluate conclusions that depend on the old contents.
This is not a reason to repeat every completed check automatically. Reuse evidence when its scope and state still match. Rerun checks when relevant inputs changed, when the earlier result is unclear, or when the next action requires fresher evidence.
For a long log, retain the failure summary, exact command, exit status, and a path to the full sanitized output. A handoff that says “see terminal above” is fragile because the new context may not contain that terminal history.
Record unknown effects before retrying
Suppose an API call to create an artifact times out. The handoff should preserve the operation identifier, target, request identity, and the fact that the outcome is unknown. “Creation failed” would invite a second creation and might duplicate the artifact.
The next action should be to inspect status or reconcile using the service’s supported mechanism. A handoff cannot itself make an operation idempotent. It can preserve the information needed to avoid guessing.
The same applies locally. A build process may still be running when context is compacted. Preserve the process or session handle and its last observed state. Starting another build without inspecting the first could produce competing output or unnecessary work.
Keep secrets out of handoffs. Refer to the approved credential mechanism when needed, and sanitize output before saving it. A handoff is often easier to copy or share than the original session, which can widen the audience for anything pasted into it.
Check a handoff with continuation questions
A local fixture compared a vague summary with a structured record for the CSV task. The underlying CSV test transcript was constructed scenario data; the executed check evaluated the handoff, not the serializer. The checker required the goal, constraints, authority, workspace, owned edits, unrelated state, verification, evidence reference, next action, and unknowns. It also checked that the verification was marked failed and that its result did not authorize deployment.
The vague record failed those checks; the structured record passed. After changing its verification state to “passed,” the consistency check rejected it because the recorded output still contained a failure. The exercise ran with Python 3.14.2.
This is a deterministic check of a small, constructed record. It is not an evaluation of an automatic summarizer, nor proof that a model will resume correctly. For that, start a fresh session with only the handoff and its accessible artifacts, ask it to identify the next step, and inspect its work against the task’s acceptance criteria.
Useful questions for that rehearsal include:
- Can the recipient state the remaining failure without reading the entire old chat?
- Can it locate the exact files and evidence?
- Can it distinguish an accepted decision from a proposal?
- Can it name the next authorized action and the unverified result?
- Does it preserve unrelated work and avoid repeating uncertain effects?
Compact repetition before causal information
Repeated progress messages, duplicate search results, and superseded hypotheses are often reducible. Preserve a rejected approach when its reason prevents the next session from trying the same thing again. “Do not use the CLI to prepend a header; other callers need the same behavior” carries more continuation value than a list of every command used to reach that conclusion.
Tool behavior differs. VS Code’s context documentation explains that conversation history is scoped to a chat and that context can be passed explicitly. Do not assume another session, model, or interface automatically receives every artifact mentioned in your note.
Before handing off, read the record as if it were all you knew. The useful result is a task that can continue from evidence, with its authority and uncertainty intact.
Documentation checked October 28, 2026. The before/after handoff and its checks are synthetic; no automatic compaction system was benchmarked.
