- In short
- A scoped cross-role tool is a single constrained tool handed directly to an agent so it can perform a high-frequency, simple operation itself instead of routing through the coordinator. It trades a tiny amount of role purity for a large latency win on the common case, while complex variants still escalate to the coordinator.
What scoped cross role tools are
Scoped cross-role tools are a deliberate, narrow exception to the rule that every agent owns only the tools of its own role. The previous principle, keep each agent to a few role-true tools, is correct, but applied too rigidly it forces a costly pattern: a worker agent that needs a quick fact has to stop, hand the request to the coordinator, wait for the coordinator to run a tool, and wait for the answer to come back. When that quick fact is needed constantly, those round trips dominate the system's latency. A scoped cross-role tool fixes that by giving the worker its own small, constrained tool for exactly that operation.
The emphasis is on both words. It is scoped: not a general capability, but one tightly constrained tool that does one simple thing. And it is cross-role: a capability that, under pure role scoping, would have belonged to a different agent or to the coordinator. You grant it anyway, because the cost of routing exceeds the cost of the small role impurity.
- Scoped cross-role tool
- A single, narrowly constrained tool granted directly to an agent so it can handle a frequent, simple operation itself rather than escalating to the coordinator. It optimises latency on the common case while complex variants of the operation still route through the coordinator.
Why the coordinator round trip is the problem
In a coordinator-subagent system, the coordinator is the hub: it dispatches work, holds shared context, and runs the heavier tools. That centralisation is valuable for hard decisions, but it becomes a tax when applied to trivial ones. Every operation routed through the coordinator costs at least one extra model turn each way, the worker asks, the coordinator interprets, the coordinator calls a tool, the coordinator replies. For a one-off complex verification that is fine. For a lookup the worker performs dozens of times in a single task, it is pure overhead.
The exam's framing is concrete: roughly 85 percent of an operation's invocations are simple, and only the remaining fraction are genuinely hard. If all of them go through the coordinator, you pay round-trip latency on the easy majority to handle the hard minority correctly. Scoping a constrained tool to the worker flips that ratio: the worker handles the easy 85 percent itself in one turn, and only escalates the hard cases.
The canonical example: a synthesis agent that can verify simple facts
The textbook case is a synthesis agent in a research system. Its role is to compose an answer from gathered material, and under strict scoping it owns no verification tools, every fact-check would route to the coordinator. But simple verifications ("does this number match the source paragraph?") happen on nearly every sentence. So you give the synthesis agent a single scoped verify_fact tool: constrained to checking a claim against already-gathered documents, nothing more. It cannot search the web, open arbitrary URLs, or run heavy analysis. For the common simple check, the synthesis agent calls verify_fact directly and keeps writing. When a claim needs deeper investigation, cross-referencing multiple new sources, the agent escalates to the coordinator as before.
Critically, this does not re-create tool overload. You are adding one tightly scoped tool to handle one frequent operation, not handing the synthesis agent the search agent's whole toolbox. The constraint is what keeps the grant safe: a narrow verify_fact is nothing like a general search_web.
Quantifying the latency win
It is worth making the latency arithmetic explicit, because the exam frames this pattern as a measured trade-off rather than a slogan. Routing a single operation through the coordinator is not one extra step but a short chain of model turns: the worker asks, the coordinator interprets the request, the coordinator calls the tool, and the coordinator relays the answer back. Each of those is a round trip with its own model latency and token cost. Collapse the chain to a direct call and the worker pays one turn instead of roughly four. Now weight it by frequency. If about 85 percent of the operation's invocations are the simple case, you remove that four-turn chain on the large majority of calls and keep it only for the 15 percent that genuinely need the coordinator's broader context. The aggregate saving is large precisely because the simple case is the common case, and the correctness of the hard case is untouched because its path never changed. That asymmetry, a big latency win on the majority and zero correctness cost on the minority, is the whole reason the pattern is worth a small break from role purity.
How to apply the pattern correctly
Treating this as a judgement call rather than a default is the apply-level skill. Use the pattern when an operation is both high-frequency and simple enough to bound with a tight constraint. Avoid it when an operation is rare (the round trip costs little), or when it is complex enough that a "constrained" version would have to be broad, at which point you are back to handing out general tools and inviting overload.
A useful test: can you describe the scoped tool's job in one narrow sentence and enforce its limits in the tool itself? verify_fact checks one claim against gathered documents, yes. A general research tool, no. If you cannot constrain it tightly, it does not belong as a cross-role grant; keep it with its proper role and route to it.
Worked example
A multi-agent research assistant is slow. Profiling shows the synthesis agent spends most of its wall-clock time waiting on the coordinator for fact-checks, and the vast majority of those checks are trivial confirmations against documents already in hand.
Begin by separating the simple case from the hard one. You measure that about 85 percent of the synthesis agent's verification requests are simple, confirm a figure or a date against a paragraph the team already retrieved. The remaining 15 percent need fresh sources and real cross-referencing, work that genuinely belongs to the coordinator and the search agent.
Now apply a scoped cross-role tool. Give the synthesis agent a single verify_fact tool constrained to checking a claim against the documents in the current context. For the simple 85 percent, the agent calls it directly and continues without a round trip. For the complex 15 percent, you leave the escalation path intact: the agent hands those to the coordinator exactly as before.
The result is a large latency reduction on the common path and no change to correctness on the hard path, because you did not weaken the coordinator's role, you offloaded only the easy cases. And because verify_fact is narrowly constrained, the synthesis agent's toolset grew by one disciplined entry rather than absorbing the search agent's powers. That balance, direct handling of the frequent simple case, escalation of the rare complex case, is the entire pattern. The exam tests exactly this trade-off.
When the pattern is the wrong call
The same judgement that justifies a scoped grant also tells you when to withhold one, and the apply-level skill is knowing both directions. Two conditions disqualify an operation. The first is rarity: if the worker performs an operation only occasionally, the coordinator round trip costs almost nothing in aggregate, so adding a tool buys little latency while still spending a slot in the agent's small toolset. The second is irreducible complexity: if you cannot bound the operation with a tight constraint, a so-called scoped version would have to be broad, and a broad tool on a worker is simply tool overload wearing a different label.
Worked example
On the same research team, someone proposes also giving the synthesis agent a research_topic tool so it can chase brand-new sources itself instead of escalating, reasoning that this cuts even more round trips.
Apply the two tests and the proposal fails both in the way that matters. The operation is not high-frequency in the simple sense, since the genuinely hard verifications are the minority, so the round trips it would remove are few. More decisively, it cannot be tightly constrained: chasing new sources means open-ended retrieval, multi-step cross-referencing, and judgement about which sources to trust. A research_topic tool narrow enough to be safe would not actually do the job, and one broad enough to do the job hands the synthesis agent the search agent's powers, re-creating the overload and the attack surface you scoped the system to avoid.
So you decline the grant and keep the escalation path. The complex 15 percent continues to route to the coordinator, which already holds the broad context and the heavier tools for exactly this work. The takeaway is that a scoped cross-role tool is earned by an operation that is both frequent and boundable; an operation that is neither belongs with its proper role. Recognising the non-example is as much a part of the skill as recognising the example, and the exam will offer you the tempting over-grant as a distractor.
How a scoped grant differs from a bloated toolset
It is worth stating plainly why this pattern does not contradict the lean-agent rule it sits beside. Adding one tightly constrained tool for one frequent operation is a precise, reversible decision: the agent's toolset grows by a single distinct, sharply described entry, so the descriptions it chooses among stay legible. Handing the agent another role's toolbox is the opposite move, several broad and overlapping tools whose descriptions compete for the model's attention. The constraint is the hinge between the two. A narrow verify_fact reads nothing like a general search_web, so the synthesis agent never confuses them, and selection reliability across its small set holds. Keep that distinction sharp and you can apply this pattern repeatedly across a system without ever sliding back into overload.
Misreadings to avoid
Misconception
Routing every operation through the coordinator is always the cleanest design because it keeps roles pure.
What's actually true
Misconception
If you give a worker agent any cross-role tool, you have re-created the tool overload problem.
What's actually true
Where it fits in tool distribution
Scoped cross-role tools are one of two levers you balance when designing a whole system. This one buys latency by placing a narrow tool close to where it is used; its companion, replacing generic tools with constrained ones, buys safety by shrinking each tool's reach. Holding both in tension across an entire multi-agent system is the tool distribution strategy this page unlocks. The judgement you practise here, deciding when a frequent simple operation earns its own scoped tool, is the same judgement that scales up to designing the toolset of every agent at once.
In a research system, the synthesis agent must constantly confirm figures against documents already gathered. Most confirmations are trivial, but a minority require pulling new sources. Latency is dominated by waiting on the coordinator. What is the best design change?
People also ask
When should a subagent get its own tool?
How do you reduce coordinator round trips in a multi-agent system?
What is a scoped tool?
Should every operation route through the coordinator?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Building Multi-Agent AI Research Systems at Anthropic
Why watch: Breaks down Anthropic's multi-agent research system where subagents are given scoped tools to act independently, illustrating why high-frequency simple operations stay local instead of routing through the coordinator.
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.