subagent

In depth

A fresh context

Delegating to a subagent amounts to opening a fresh context. The main agent formulates an instruction, the subagent handles it in its own loop, then returns only a summary: the thousands of words read along the way stay on its side. The benefit is mechanical rather than intellectual, since the main thread stays readable and does not saturate. The corollary is brutal: whatever the subagent did not write in its response is lost, and the main agent can neither guess it nor go and fetch it.

Parallelism

Delegation also opens up parallelism, several subagents being able to explore avenues at the same time and each report its own summary. It works well when the tasks are independent and the expected answer fits in few words: searching, checking, summarising, comparing. It works badly as soon as the subtasks have to coordinate, because subagents do not talk to one another and share no intermediate state. Writing to the same document several at once, for instance, produces inconsistencies that none of them can see from inside its own loop.

The traps

The first trap is the vague instruction, because a subagent has none of the unspoken assumptions of the original conversation: anything not written in its instruction does not exist for it. The second is the cost, since each subagent reads its own instructions and the description of its own tools again, so that easy delegation multiplies the spend without always multiplying the value. The third is the loss of visibility: an incident that occurred deep inside a subagent appears in the main thread only as a reassuring summary. The trace of each subagent must therefore be kept separately, on pain of no longer being able to explain a result.