Defending a Sub-Agent Design

Designs with more than one agent draw some of the sharpest pushback in Anthropic’s technical rounds. An interviewer looks at the diagram and asks a short question: “Why not one agent?” A candidate who added agents because the design looked more advanced has no good answer. A candidate who added one for a specific reason can name the reason, show the boundary it creates, and state what it costs.

That answer rests on three ideas: isolated context, scoped tools, and contained failure. Each one is easier to defend when we have built it. The examples extend the expense-audit scenario, where a coordinator decides what happens to each report and a sub-agent checks each report against its scanned receipt.

When a sub-agent earns its place

A sub-agent is a specialized agent that a main agent, the coordinator, hands part of a task to. The sub-agent works in its own context window with its own instructions and tools, then reports a result back. The coordinator sees that result and nothing else from the sub-agent’s work.

A sub-agent earns its place in a Claude design for four reasons.

• Isolated context: A noisy subtask, such as reading long receipts or search results, stays in the sub-agent’s context, and the coordinator receives only the finding.

• A narrower tool set: A role that only needs to read data gets read tools only, so it cannot take actions even when it makes a mistake.

• Parallel work: Independent checks, such as one receipt check per report, can run at the same time.

• A cheaper model: A focused task often runs well on a smaller, faster model than the coordinator needs.

Every sub-agent also adds cost. Each one starts its own conversation, rereads its instructions, and spends tokens the coordinator would not have spent. Strong candidates state that cost before the ...