2.3 Tool Distribution & Tool Choice

It's tempting to think more tools make an agent more capable — give it everything and let it figure out what to use. Task Statement 2.3 says the opposite is true past a point: handing an agent too many tools makes it WORSE at choosing among them. This lesson is about how many tools an agent should have, how to distribute tools across a multi-agent team, and how to control which tool gets called.

Here's the intuition. Imagine a kitchen with five well-chosen, clearly-labelled tools versus a drawer crammed with fifty gadgets, half of them similar. In the crammed drawer you waste time deciding, grab the wrong thing, and occasionally use a tool for something it wasn't meant for. The model faces the same problem: every extra tool is another option to weigh on every turn, and similar tools blur together (exactly the misrouting from Lesson 2.1, now multiplied). The guidance from the exam is concrete — aim for roughly 4–5 tools per agent, each scoped to that agent's role. Eighteen tools on one agent is a recipe for unreliable selection.

In a multi-agent system, the natural way to keep each agent's toolset small is to scope tools to the agent's ROLE — give each agent only the tools its job requires. This isn't just about reliability; it's also a safety principle (least privilege) we'll deepen in 2.5. An agent with tools outside its specialization tends to MISUSE them.

A concrete example from the research-system world: a synthesis agent's job is to combine findings, not to gather them. If you give that synthesis agent a web_search tool, it may start doing its own searches — duplicating the search agent's work, blurring responsibilities, and producing inconsistent results. The fix is to scope: the search agent gets search tools, the analysis agent gets document tools, the synthesis agent gets only what synthesis needs. Each agent's 4–5 tools map cleanly to its role.

Strict scoping has a cost, and the exam tests the nuance. Suppose the synthesis agent frequently needs to verify a small fact mid-synthesis — a date, a name, a statistic. With strict scoping, it has to hand control back to the coordinator, which invokes the search agent, which returns, which re-invokes synthesis. That round-trip adds 2–3 hops and can balloon latency (think +40%) for what is usually a trivial lookup.

Here's the insight: if 85% of those verifications are simple fact-checks and only 15% need deep investigation, you shouldn't route ALL of them through the coordinator. Instead, give the synthesis agent a SCOPED cross-role tool — a narrow verify_fact tool that handles the simple 85% directly — while still routing the genuinely complex 15% through the coordinator to the full search agent. You get the speed of local handling for the common case and the power of full delegation for the hard case.

Notice this is a balance, not a contradiction of 2.3.2: you're not handing the synthesis agent the full web_search tool (which it would misuse), you're giving it a CONSTRAINED tool sized exactly to its high-frequency need. Scope tightly by default; add a narrow cross-role tool only where a high-frequency simple case justifies it.

So far the model has freely decided whether and which tool to call. Sometimes you need to take that decision into your own hands — guarantee that it calls SOME tool, or a SPECIFIC tool. That's what the tool_choice setting controls, and it has a small set of modes worth knowing precisely.

Two modes earn their keep in practice. Use "any" when conversational text would be a failure — for example, an extraction pipeline where you MUST get structured data back, not a chatty paragraph; 'any' forces the model to call one of your extraction tools. Use forced selection ({type:"tool",name:"extract_metadata"}) when a particular step must run FIRST regardless of what the model thinks — pin extract_metadata as the opening move, then handle the enrichment steps in follow-up turns. (And recall the Lesson 1.1 warning: forcing a tool every turn with 'any' can prevent the loop from ever ending — use it deliberately, not as a permanent setting.)

The 2.3 traps test whether you'll over-provision tools, route everything through the coordinator, or pick the wrong tool_choice. Keep three ideas straight: scope tightly, handle the high-frequency simple case locally, and match tool_choice to the guarantee you need.

• •Over-provisioning. ✗ Giving the synthesis agent the full web_search tool so it 'can verify anything'. ✓ Give it a scoped verify_fact for the 85% simple case; route the 15% complex through the coordinator.
• •Routing everything centrally. ✗ Sending every simple verification back through the coordinator (2–3 hops, +latency). ✓ Handle the common simple case with a scoped local tool.
• •Wrong tool_choice for structured output. ✗ Leaving tool_choice on 'auto' when you MUST get a tool call (structured data). ✓ Use 'any' to guarantee a tool call.
• •Tool overload. ✗ Putting 18 tools on one agent. ✓ ~4–5 role-scoped tools per agent.

You now know why fewer tools means better selection, how to scope tools to roles, the 85%/15% cross-role pattern, and the tool_choice modes. The exercise makes the trade-offs tangible — you'll feel the latency of over-routing and the reliability cost of tool overload.

You've now designed individual tools (2.1), made them fail well (2.2), and distributed and controlled them (2.3). The next lesson, 2.4, moves to where many of these tools actually come from in practice: external MCP servers, and how to wire them into Claude Code and agents.