Beyond One Agent, One Tool

Vol 1 engineered the two layers around the model — the environment an agent acts in and the context it reasons over. This volume takes the harness’s remaining moves: the tools an agent reaches for, and the orchestration of more than one agent. Both look like ways to add power. The thesis of this chapter is that both are better understood as ways to spend context — and that seeing them in that single currency gives both the same governing default.

From one agent to a system of capability and coordination

Vol 1 left two of the harness’s components deliberately unbuilt: the tool interface, and sub-agent orchestration. They are this volume’s subject. An agent, in the working definition the series uses, is a system where models “dynamically direct their own processes and tool usage” [Official] Building effective agents · Erik Schluntz and Barry Zhang (2024)T1-official original — so the moment you move past a single bare model, you are making two kinds of decision: what capability to expose (which tools, which protocol, which prompts), and how to coordinate when one agent is not enough.

It is tempting to treat both as additive — more tools, more agents, more power. The rest of this chapter argues the opposite framing, because the additive view is exactly what produces bloated, slow, hard-to-debug systems. Both decisions spend the same scarce resource.

The first axis: capability is a context cost

The first axis is what capability to expose. The naive view treats a capability as free until used. It is not. Context is “a critical but finite resource for AI agents” [Official] Effective context engineering for AI agents · Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield (2025)T1-official original — a budget — and every tool you expose draws on it whether or not it fires, because its definition sits in the window and its presence enlarges the model’s selection problem.

This is why the governing default on the capability axis is subtraction: “More tools don’t always lead to better outcomes.” [Official] Writing effective tools for agents — with agents · Aizawa (Anthropic) (2025)T1-official original The same instinct governs the build-vs-buy decision (start direct on the API; add abstraction only when it earns its keep, since “many patterns can be implemented in a few lines of code” [Official] Building effective agents · Erik Schluntz and Barry Zhang (2024)T1-official original ), the protocol you wire external capability through, and the way you shape the agent’s text input and output.

The second axis: coordination is a context-isolation move

The second axis is how to coordinate once one agent is not enough. Here the key reframing is sharper still: a sub-agent does not give the model a new skill — it gives the work a fresh, separate window. Sub-agents “use their own isolated context windows.” [Official] Building agents with the Claude Agent SDK · Thariq Shihipar et al. (2025)T1-official original The value is the isolation, not an added capability: a unit of work runs out of band, untouched by the main conversation’s history, and returns only its relevant result.

So coordination, too, is a context decision — not “add an agent to gain an ability” but “add a window to quarantine context or parallelize work.” That reframing carries the whole orchestration half: you reach for another agent when there is context to isolate or independent work to fan out, and you do not when the coordination cost outweighs the gain.

Primitive versus topology

One distinction prevents most orchestration confusion: the primitive is not the topology.

• A sub-agent is the primitive — a single isolated unit: fresh context in, relevant result out.
• A multi-agent system is a topology — how you coordinate many such units (an orchestrator delegating to workers, say).

Conflating them produces both over- and under-engineering: building a multi-agent topology when one isolated sub-agent would do, or expecting a lone sub-agent to deliver what only a coordinated topology can. The orchestration half of this volume treats them as different objects — the isolation primitive first, the coordination of many second — and gates the topology on cost, because coordinating agents is not free.

The map of this volume

The chapters move along the two axes — first what capability to expose, then how to coordinate.

Capability — what to expose, and how.

• Build vs. buy — whether to write thin on the API, configure a harness, or build one; the start-direct default.
• Tool minimization — the governing subtract-first discipline for the tool set itself.
• MCP — wiring external capability against a least-privilege, capability-negotiated protocol.
• Shaping input — the prompting craft — the five moves that shape what goes into the agent.
• Shaping output — structured & reliable — the levers that force machine-readable output you can trust coming back.

Coordination — how many windows, and how they cooperate.

• Sub-agents — the context-isolation primitive: a fresh window that inherits nothing and returns only the result.
• Multi-agent — the coordination topology, and the cost gate that decides whether it is worth it.

Quick reference

• Two axes, one currency: capability (what’s in a window) and coordination (how many windows) both spend context. Effective context engineering for AI agents · Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield (2025)T1-official original
• Capability default — subtract: expose what the workflow needs, not what the platform offers. Writing effective tools for agents — with agents · Aizawa (Anthropic) (2025)T1-official original
• Coordination default — isolate, don’t add skill: a sub-agent is a fresh window, valuable for isolation, not capability. Building agents with the Claude Agent SDK · Thariq Shihipar et al. (2025)T1-official original
• Primitive ≠ topology: the sub-agent is the unit; the multi-agent system is how units coordinate.
• The map: capability chapters (build-vs-buy, tool minimization, MCP, prompting, structured output) → coordination chapters (sub-agents, multi-agent).
• The reflex to unlearn: “can I add this?” → “what does it cost in the window, and is the work worth it?”

Practice