Your forked subagent already knows too much

When you split a task off to a subagent, you choose how much of yourself to send with it. You can fork the parent's context into the child, handing over the transcript of what the parent has seen and concluded, or you can start the child fresh, with nothing but a task you write for it. The team-of-agents pattern makes forking feel like the default: if the child is one of us, it should know what we know, and holding anything back looks like starting it at a disadvantage. More context cannot hurt, the thinking goes, and it might save the child from redoing work. That thinking is wrong, and the reason has nothing to do with the cost of the tokens.

Two easy answers get in the way of the real one. The first is that a big context is expensive, which is true and beside the point: even a context small enough to fork without a second thought carries the problem I am about to describe, so price is not what decides this. The second is that a fresh agent brings independent eyes and catches what the parent missed. That effect is real, but it belongs to a different setup, the one where you run several agents and aggregate their answers, where the value comes from errors that fail independently across a panel you vote over. A single handoff has no panel and no vote. Set both aside. What decides fork or fresh is neither the size of the inherited context nor the independence of a crowd. It is that an inherited transcript arrives with no way to tell its live conclusions from its dead ones.

A transcript is a record of what the agent tried, and on a hard problem much of what it tries does not survive. It chases a hypothesis for ten steps, hits a wall, and backs out. Sometimes it backs out loudly, and the transcript says so: the test failed, the grep came back empty, the parent wrote that this did not work and turned to something else. A child reading that can see the wall. But the loud retraction is the easy case, and it is not where the damage lives. The parent changes its mind in quieter ways too. It draws a conclusion from a tool result, builds on the conclusion, and when the ground shifts it simply stops leaning on the old belief without ever announcing that it did. It holds a finding as a hunch, hedged and provisional, and the transcript records the finding flat, with the hedge gone. By the time the parent hands off, what it actually believes is everything it tried minus a running set of private corrections it never wrote down. Fork the transcript and the child inherits the sum without the subtractions. It reads a provisional guess and a settled fact in the same even tone, because on the page they are the same, and it has no way back to the moment the parent quietly let one of them go.

Framing is the largest thing that travels this way unmarked. The parent did not only reach conclusions, it decided how to carve the problem up before it reached any of them, and that decomposition is nowhere stated as a choice, only the shape the transcript already has. A child born into it inherits the carving as the shape of the problem and works inside it, including when the carving was the parent's first mistake. A fresh agent, handed the task and not the history, is free to cut it a different way, and now and then the different cut is the whole answer. The panel's independence is a separate thing; this is a single worker escaping a single predecessor's framing rather than a crowd averaging out its errors.

So a fresh agent's ignorance is not a hole to be filled in. The child that never saw the parent's false start cannot be misled by it, and every claim standing in front of it has a source you chose. You are not withholding information, you are withholding residue the child would otherwise have to spend effort disproving, or worse, would quietly trust. A blank context is not an empty one. It is a curated one.

None of which makes fork always wrong. It earns its place for one clear shape of work: continuation, where the parent's half-built state is not residue but the substance of the task, and that state is a live structure rather than a set of facts you could write down. If the child's job is to carry on a line of reasoning the parent was in the middle of, the thing being continued is the half-finished structure itself, and there is no page you can flatten it onto without losing what makes it the work. Resuming an agent you paused is the same move: you keep its context because that accumulated structure is the point, not because you failed to summarize it. The question is not whether inherited context ever helps, but whether this handoff continues one piece of work or begins a separable one. Fork when the state will not survive being written down, not when writing it down is merely a chore.

That gives a sharper test than the intuition it replaces. Try to write the subagent a complete brief: everything it needs, including what you have already ruled out, but not the path you walked to get there. The ruled-out list is the part worth insisting on, because it is the parent's residue with the labels finally attached. Not "I spent an hour in the caching layer," but "the caching layer is not it, skip it." That is a finding, and a finding is exactly what a fresh child should start with. Write that brief and it beats the fork you were about to hand over, not because it holds more but because you chose every line of it and the fork chose none. This is why the summary a careful parent could write, settled here, ruled out there, still open on that, is not a compromise between fork and fresh. It is the fresh brief, done well.

The trade shows most clearly in the subagent whose whole job is to read a lot and come back with a little. Send one to sweep a large codebase for where some behavior lives, and what you want back is the answer, the two files that matter, not the forty it opened to find them. Start it fresh and it reads the code and tells you what the code says. Fork your context into it and you have also handed it your running theory of where the bug probably is, and a subagent holding your theory is very good at finding evidence for it. It comes back having confirmed what you already suspected, from the files you would have guessed, and the file that actually held the answer stayed closed because nothing in the inherited context pointed at it. The fresh searcher reads the codebase. The forked one reads your expectations and calls them the codebase. I reach for the clean-context searcher constantly, and the reason is exactly that: I want it to find what is there, not what I walked in believing.

There is an asymmetry in the two ways this goes wrong, and it is the real argument for making fresh the default. The brief is a written artifact. Under-brief a fresh agent and whatever you left out is missing from a document you can read back, so when the result comes out wrong you can hold the two side by side, find the gap, and close it with a line. The failure has a location. Over-forking has none. The contaminating belief sits somewhere in a transcript you did not write and would not reread at that depth, the child has folded it into work that looks whole, and there is nothing to diff the result against, because the fork's whole promise was that you would not have to assemble one. A mistake you can point to and a mistake smeared across forty turns do not deserve the same default. When you cannot tell which way to lean, lean toward the failure that leaves a mark.

So the choice underneath fork or fresh is less about how much the child should know than about what you want its context to be. A fresh subagent carries only what you put there on purpose, each line with a source and a reason. A forked one carries that plus everything the parent stopped believing along the way, written in the same flat hand as everything it still believes, and you cannot see the seam. Most of the time the context you want is the one you built, not the one you inherited, and building it is the same work as writing down what the task needs. Choosing what an agent does not get to know is not the absence of engineering. It is most of it.