Long tasks hit context limits, and the compaction or handoff that
follows is where instructions quietly die. I wanted to know which
kinds of instruction survive the squeeze and which vanish, so I
started checking resumed sessions against their configs. The pattern
is consistent enough to write down.
The test
Nothing fancy. After a handoff (compaction, subagent spawn, or
session fork), I ask the working agent to state, without reading
files:
1. What are you building and what's done so far?
2. Which rules from the config are you following?
3. What approaches were rejected and why?
Then I compare against the config and the pre-handoff transcript.
Dozens of handoffs, same categories of loss every time.
What dies first
Rejected alternatives. The "don't use X, we tried it" knowledge
is the first casualty. Post-handoff, agents re-propose the exact
library or pattern that was ruled out an hour earlier. This is the
most expensive loss: it re-runs debates you already finished.
Reasons behind rules. The rule "no moment.js" survives; the
reason (bundle size, already migrated to dayjs) does not. Without
the reason, the agent treats the rule as arbitrary, and arbitrary
rules are the first to get rationalized away in edge cases.
Preference phrasings. "Keep error messages calm and technical"
becomes generic. Anything that was a judgment call regresses toward
the model's default.
Task-adjacent state. Which of three similar files is the real
one, what the TODO comment meant, why the branch exists. Anything
that lived in your head or in transit is gone.
What survives
- Explicit, file-backed rules. If it is in CLAUDE.md or a scoped rule that reloads, it survives. Files re-read; memory does not.
- Commands. The test command, the build command. Probably because they appear in recent transcript turns.
- Recent work. The last few exchanges before compaction are represented in the summary. The further back, the thinner.
- Anything written to a file mid-task. A NOTES.md or TODO.md updated as you go survives perfectly, because it reloads as data.
What to do with this
1. Rules live in files, never in conversation. If you have told
the agent a rule three messages ago and the task will run long, it
does not know the rule anymore. Move it to config or accept the
loss.
2. Decisions get a ledger. A DECISIONS.md, append-only, dated,
one line per decision with the rejected alternative:
## 2026-09-19: validation in zod, not joi
- joi rejected: team has zod experience, schema reuse with API layer
When a resumed agent proposes joi, the answer is a file read, not a
meeting.
3. Handoffs get a written brief. Before spawning a subagent or
expecting compaction, write the brief to a file: goal, done-so-far,
constraints, rejected approaches. Two minutes of writing beats an
hour of the agent re-deriving what you already decided.
4. Point-of-use comments. A comment at the weird workaround
explaining why survives every compaction for the rest of the repo's
life. It is the cheapest compaction insurance that exists.
The honest limit
No amount of config fixes this completely. Compaction is lossy by
design, and the summary keeps what is recent and salient, not what
is important. The realistic goal is: rules and decisions survive via
files, and the losses that remain are ones you can afford, like
transit state you would restate anyway.
Related reading
- Your CLAUDE.md is probably too long: files reload, so what earns a place in them matters.
- Config files vs hooks: guarantees belong below prose, partly because prose is what compaction eats.
- Running 4 agents in parallel: handoff discipline at fleet scale.
Top comments (3)
this matches what we see running a coding agent (disclosure, i build grunz). one category i'd put above rejected alternatives: the goal itself. on long runs the summary compresses the objective into something vague and the model treats it as a fresh task and re-plans from scratch, which from the outside just looks like the agent looping. your three question test catches it if you add a fourth: "what exactly did the user ask for, word for word". diffing that against the original prompt was the fastest way we found to see the drift. have you seen a difference between compaction and subagent spawns in how much gets lost? our hunch is agent to agent handoffs are worse because nobody owns the summary.
Stealing the word-for-word goal check, that failure is exactly what my three questions miss. The tell I watch for is the agent re-reading the entry file when it should be editing, which usually means the summary went vague enough that the task reads as new. On your question, spawns lose more than compaction in my logs, and the nobody-owns-the-summary mechanism you named is half of it. The other half is that compaction is at least recency-weighted (the last few turns survive by default), while a spawn gets whatever brief the parent wrote in a hurry. Worst case the parent had already compacted once, so the child inherits a summary of a summary, and its only escalation path is asking the parent, which no longer knows either.
"summary of a summary" is a great way to put it, and it explains a thing we couldn't. the re-reading the entry file tell is a good one too, we mostly caught it late when the plan visibly restarted. the obvious move off the back of this seems to be having the parent pass the original ask verbatim into every spawn brief, separate from its own summary, so the child gets at least one thing that was never compressed. have you tried anything like that or does the brief stay freeform?