- In short
- A tool distribution strategy is the set of decisions about which tools live on which agent across a multi-agent system, made to balance three competing pressures: selection reliability (favoured by fewer tools per agent), latency (favoured by fewer coordinator round trips), and security (favoured by constrained tools). Good design optimises all three together rather than maximising one.
What a tool distribution strategy is
A tool distribution strategy is the deliberate plan for which tools live on which agent across an entire multi-agent system. It is an evaluate-level skill because no single rule produces the answer, you are weighing competing pressures and justifying a design, not applying one principle. The earlier knowledge points each give you one lever; distribution is where you pull all of them together and defend the result.
The reason this is hard is that the levers fight each other. Make every agent leaner and selection gets more reliable, but agents now lean on the coordinator more, adding latency. Push capabilities down to agents to cut round trips, and you risk re-creating overload or widening the attack surface. A good tool distribution strategy holds three forces in balance at once rather than maximising any one of them.
- Tool distribution strategy
- The system-wide design of which tools each agent holds, chosen to balance selection reliability (fewer tools per agent), latency (fewer coordinator round trips), and security (constrained tools). The mark of a good strategy is that it improves all three together instead of trading one away for another.
The three axes you are balancing
Every distribution decision moves you along three axes. Naming them is what lets you reason about a design instead of guessing.
- Selection reliability. Driven by the tool overload problem: the fewer, more distinct tools an agent holds, the more reliably it selects the right one. This axis pulls toward small, role-scoped toolsets.
- Latency. Driven by coordinator round trips: every operation an agent must escalate costs extra turns. This axis pulls toward placing capabilities close to where they are used, the scoped cross-role tool lever.
- Security. Driven by each tool's breadth: generic tools are large attack surfaces. This axis pulls toward constrained tools that validate inputs and bound scope.
The three do not align automatically. The art is finding a layout where a gain on one axis does not quietly cost you on another, and the scoped, constrained tool is the device that often lets you win on two at once.
How the levers reconcile
The reason the earlier patterns matter here is that they resolve the apparent conflict between axes. Naively, reliability and latency are opposed: lean agents are reliable but escalate often. The scoped cross-role tool breaks that opposition. Because it is a single, tightly constrained capability rather than a whole toolbox, it cuts round trips (latency win) without meaningfully growing the toolset (reliability preserved), and because it is constrained, it does not widen the attack surface (security preserved). One well-chosen tool can therefore advance all three axes.
Constraining does similar double duty. A constrained tool is safer and has a sharper description, which improves selection, so security and reliability move together. Recognising these interactions, rather than treating each axis in isolation, is exactly what the evaluate-level questions are testing.
When the catalogue is genuinely large
A subtle evaluate-level move is recognising when the three-axis trade-off has an escape hatch rather than a compromise. The reliability axis assumes the tools an agent holds are loaded into its context up front, which is exactly why fewer is better. But if a role honestly needs a large catalogue, Anthropic's tool search tool changes the shape of the problem. With defer_loading: true, an agent's many tools sit outside the context prefix and are discovered on demand, three to five at a time, so the agent still reasons over a small working set even though its catalogue is large. Anthropic notes that selection accuracy degrades once a model sees more than roughly 30 to 50 tools at once, and that a deferred catalogue can hold up to ten thousand tools, which together mean the right design for a tool-rich role is neither dumping everything onto one agent nor shattering the role across a dozen thin agents, but giving one agent a searchable catalogue. The strategic point is that capability and reliability stop being strictly opposed: you no longer have to trade one away when the platform can keep the working set small while the catalogue stays large. A strong distribution strategy reaches for this when the alternative is either overload or an awkward proliferation of agents.
How to evaluate a proposed distribution
When you assess a design, score it on all three axes and look for an axis that has been sacrificed. The classic failures are single-axis optimisations:
- Latency-only. "Give every agent every tool so nothing waits on the coordinator." This collapses reliability into overload and ignores security entirely. It is the exam's favourite wrong answer.
- Reliability-only. "Route every operation through the coordinator so each agent holds the bare minimum." Selection is pristine but latency is terrible, because even trivial frequent operations pay a round trip.
- Security-only. "Lock every tool behind the coordinator." Safe, but slow, and it concentrates risk and load on one agent.
The balanced design takes a middle path: scope each agent to a small role-true set (reliability), promote the frequent simple operations to constrained cross-role tools (latency), and replace any remaining generic tools with constrained ones (security). When you can articulate why a layout serves all three axes, you are reasoning the way the exam wants.
Worked example
You are designing the tool layout for a multi-agent research assistant from scratch: a coordinator, a web-search agent, and a synthesis agent. Requirements: high answer quality, low end-to-end latency, and no exposure of internal systems to untrusted document content.
Work axis by axis, then reconcile. For reliability, refuse the temptation to build one generalist agent with every tool. Scope the search agent to web tools and the synthesis agent to reading and composing tools, four to five each, so neither has to disambiguate a crowded menu.
For latency, profile the common path. The synthesis agent verifies simple facts constantly, and routing each through the coordinator would dominate wall-clock time. So you promote that one frequent simple operation to a scoped cross-role tool, a narrow verify_fact on the synthesis agent, while complex verifications still escalate. That buys most of the latency back without bloating the toolset.
For security, audit every tool that touches the outside world. The search agent's fetch capability is generic, so you constrain it to fetch_allowed_source, validating inputs against approved domains, neutralising the risk that untrusted document text redirects it inward. Heavy, broad capabilities that are rarely needed stay on the coordinator rather than being pushed down.
Now check the whole: each agent is lean (reliability), the dominant simple operation is local (latency), and outward-facing tools validate their inputs (security). No axis was traded away. A weaker design would have maximised one, all tools everywhere for latency, or all tools centralised for reliability, and the exam would mark that down precisely because it ignores the other two pressures. The deliverable is not a single tool placement but a justified balance across the three.
A scoring rubric for any proposed layout
When you are handed a distribution to evaluate, resist judging it by its headline virtue and instead score it on all three axes in turn. Three questions do most of the work. First, for reliability: does any single agent hold so many overlapping tools that its selection would blur, and could naming or consolidation shrink the set before you resort to adding agents? Second, for latency: does a frequent, simple operation pay a coordinator round trip it does not need, and if so, can a single tightly constrained cross-role tool absorb it? Third, for security: does any outward-facing tool accept more than its purpose requires, and could a constrained, validating replacement remove the unsafe reach? A layout that answers all three well is balanced. A layout that aces one question while ignoring the others is the single-axis optimisation the exam is built to catch. The discipline is to notice the unasked question, the axis a confident-sounding proposal quietly sacrificed.
Worked example
A team presents the opposite of the over-grant. To keep every agent maximally reliable, they route every tool call, including trivial frequent lookups, through the coordinator, leaving each worker with almost no tools of its own. They report excellent selection accuracy, but users complain the system is slow.
Score it on the three axes. Reliability is genuinely strong, because each agent holds a tiny, unambiguous set, so selection rarely misfires. Security is fine too, since broad tools live behind the coordinator. But latency has been sacrificed wholesale: every trivial, high-frequency operation pays a full coordinator round trip, and the aggregate of those round trips is exactly the slowness users feel. This is the reliability-only failure, the mirror image of the more famous latency-only trap of giving every agent every tool.
The fix is not to abandon centralisation but to make a surgical exception. Identify the frequent, boundable operations a worker performs, promote each to a single constrained cross-role tool on that worker, and leave the rare or unboundable operations routing through the coordinator as before. Reliability barely moves, because each worker gains only one or two narrow, sharply described tools; security is untouched, because the grants are constrained; and latency improves sharply on the common path. The balanced design recovers the axis the proposal gave away without surrendering the two it got right, which is precisely the reconciliation an evaluate-level answer must articulate.
How this is tested
This is the evaluate-level capstone of task statement 2.3, and it sits at the difficulty ceiling for the task because no single rule yields the answer. Questions present a proposed tool layout, often with a plausible-sounding justification, and ask you to assess it as the reviewing architect. The reliable failure mode in the wrong answers is single-axis reasoning: a design that minimises round trips by handing everyone every tool, or maximises reliability by centralising everything, or locks down security at the cost of speed. The correct answer names the neglected axis explicitly and proposes the lever that restores balance, role scoping for reliability, a constrained cross-role tool for latency, a validating replacement for security. If you can articulate why a layout serves all three pressures at once, and spot the one it abandoned when it does not, you are reasoning the way the capstone demands.
Misreadings to avoid
Misconception
The best tool distribution minimises coordinator round trips, so push as many tools to the agents as possible.
What's actually true
Misconception
Tool distribution is just applying the 4-to-5-tools rule to every agent.
What's actually true
How this caps off Domain 2 tool design
This knowledge point is where the task statement's threads converge. The overload problem gave you the reliability axis, scoped cross-role tools gave you the latency lever, and constrained tools gave you the security lever. Distribution strategy is the evaluation skill that holds them in tension over a whole system, which is why it sits at the top of the prerequisite chain and at the difficulty ceiling for the task. Master it and you can defend a tool layout, not just recite a rule, exactly what the scenario questions in Domain 2 demand.
A team proposes giving all six agents in their research system identical access to every tool, arguing this minimises coordinator round trips and therefore latency. As the reviewing architect, what is the strongest objection?
People also ask
How do you distribute tools across a multi-agent system?
How do you balance tool selection reliability and latency?
How many tools should each agent in a system get?
What trade-offs matter when distributing tools?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Using multiple tools
Why watch: Distributing a handful of tools to one agent is a concrete case of tool-distribution strategy across a system.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.