Handing context between agent calls
When a Claude Code session hands work to a subagent, the subagent starts with an empty context. Whatever the session has learned reaches it only through the prompt, and the usual way to fill that prompt is to have the orchestrating model write a brief. Over the past ten days Oskar and I tested two alternatives: one for handing facts to a single subagent, and one for carrying state through a long job split across many fresh calls. Passing transcript text through unchanged got more facts to a subagent than a brief the orchestrator wrote. Keeping a count over a long job worked the other way: stored text lost the count once there was too much of it, and a model updating a small table at each step kept it.
Handing facts to a subagent
The delegating-with-context skill, an instruction pack plus a hook that we load into Claude Code, replaces the brief with a filter. The orchestrator writes only the task. Before every subagent launch, the hook splits the session transcript into chunks (one user message, one assistant reply, or one tool call with its result), asks Jev, a fast classifier that returns a yes-probability, whether a subagent given this task would need each chunk, and appends the highest-scoring chunks verbatim, up to about 20,000 tokens. A filter call takes about a second and costs a fifth of a cent.
To test it, a separate model read eight archived sessions and wrote 32 tasks an orchestrator might plausibly delegate, each with two to four facts the answer had to contain: 105 facts in all. A fresh Sonnet subagent with no tools attempted each task given different context. With the whole transcript (median 81,000 tokens) it found 102 of the 105 facts. With the filter's chunks it found 99. With a brief that Sonnet had written after reading the whole transcript, it found 82. Nearly all of the brief's loss came from five tasks where the brief told the subagent where to find a fact ("check the pr-workflow config entry") instead of stating it, and the subagent had no way to look.
Carrying state through a long job
A University of Washington and Meta paper, Context Language Models, gives a model write access to its own context as a file, so it can delete, summarize and rewrite what it holds as it works. Claude Code does not let a model edit its live transcript, so we tested a version that fits it. Each chunk of a long input goes to a fresh, non-interactive Claude Code call (claude -p) running Haiku 4.5, and only a file capped at 24,000 tokens carries over to the next call. We filled that file two ways: Jev scoring every line and keeping the likely ones verbatim, or the subagent writing its own notes. The experiment ran two synthetic tasks, one run each, on streams of up to 96 chunks of about 4,000 tokens.
In the first, each chunk held 140 lines of equipment-log filler and two to eight lines recording that responsibility for an asset passed from one person to another. The task was to keep every such line exactly as written. Each line carried a random ID, so a retyped line that changed one character no longer counted. At 96 chunks Jev kept all 497 and no filler, for four cents. The subagent kept 496, for $7.74; the missing line was in its notes, retyped with an invented ID. A third run gave the subagent and Jev one shared budget, with the notes allowed whatever Jev left. The notes grew, and Jev's store had to drop 122 of the 497 lines.
The second task needed a running result rather than a list: for 40 assets, the current holder and the number of times each had changed hands, over 1,536 handovers. The handover lines alone come to about 46,000 tokens, so Jev's store had to drop about half of them, and every count was wrong whichever lines it dropped. Dropping the oldest lines at least kept each asset's latest handover. Even so, Haiku reading the roughly 800 kept lines in a single call with no tools named 9 of the 40 current holders, though all 40 were in what it read; given a shell, it wrote a parser and named all 40. The subagent kept a 40-row table and edited it in place. The table stayed around 500 tokens for the whole stream, every holder was right at the end, and 33 of 40 counts were exact, the other seven each one short.
We then combined the two: Jev flagged the likely handovers in each chunk, and the subagent updated its table with the flags in front of it. That cut its cost per chunk by 12 to 25 percent. In the 96-chunk run, one rewrite near chunk 71 also reset 14 of the counts to zero, and the run ended with 22 of 40 counts exact, against 33 without the flags. The code running the loop accepted whatever file the subagent wrote. It now checks the table after every step, rejecting any edit that drops a row or lowers a count, and retries the step once. In a rerun the check fired once, at chunk 36, on an edit that lowered two counts (19 to 3 and 14 to 1). The retry passed, and the table ended with 38 of 40 counts exact, the best of any version.
Rules for passing context
For facts a subagent needs, pass the source text verbatim and let a cheap classifier choose it. In these runs, rewriting facts into a brief or a note dropped some, replaced others with a pointer to where they could be found, and once changed an ID.
For anything that accumulates, such as a count, a register or the state of a board, have a model update it at each step, and have the code running the loop check it after every update. In our run, one bad update reset 14 counts, and no later step restored them. When a verbatim store and a notes file share a budget, give each a fixed share. When the last step has to compute something from stored lines, give it tools.
The relay tasks are synthetic and ran once each on Haiku 4.5, so each of those comparisons is a single run. It shows which design did better here and gives no failure rate for either. The filter evaluation used 32 tasks from eight real sessions. The results, the predictions written before each run and the error logs are in the two experiment directories, subagent-context-filter and clm-relay-needles.