subagent

Two neighbouring terms get used as if they meant the same thing. An orchestrator agent is the one doing the spawning: it triages, routes, tracks run state, and does no specialist work itself. A critic agent is one job a subagent can be handed, not the general word for the unit. Subagent is the unit itself, whatever job it gets: spawned, scoped to one task, isolated, gone when it finishes.

The vocabulary is not settled here, including on this site. Agent run cost attribution uses subagent and specialist in the same essay for the same thing, and several other pieces use specialist throughout. Read the two words as synonyms.

Fresh context is the point

Who checks the checker names four in one run: Analizer 2000 for requirements, the Architect for system design, the Challenger as a cold critic, the Spellwright for build prompts. Under the names the machinery is plain. Each specialist runs in a fresh context, and parallel build agents work in separate git worktrees so they do not collide.

The structure is built around that isolation on purpose. A subagent that never watched an artifact get argued into shape can only respond to the artifact, which is the entire value of handing a review to one. The cost is that the parent has to give the subagent less than it knows, and write down what it wants back.

What isolation costs

An isolated context is also an isolated record. A clean audit run proves nothing shows the shape of the fix that follows: the run's nonce goes into the specialist agent's spawn prompt, so it turns up in that agent's own transcript and never in any shared log, and the session-stop hook checks the nonce before attributing tokens to the run.

Most subagent problems have that shape. Anything you want to know about what a subagent did has to be captured at the boundary, either in the handoff it writes or by harness code reading its transcript once it has exited. Asking the subagent to report on itself is not a third option, because the parent has no way to check the answer.