A pattern that measurably cut our multi-agent failure rate: scope each agent’s tool list to only the tools its role needs, instead of handing every agent the full toolset.
The intuition is that more tools = more capable, so give everyone everything. In practice the opposite happened. When a “researcher” agent could also see the file-write and shell tools, it would occasionally decide to do the work itself instead of returning findings for the next agent — collapsing the crew into one confused generalist and skipping the handoff entirely. The more overlapping tools two agents share, the blurrier the boundary between their roles gets.
What worked:
- Researcher → search / fetch only. It cannot write, so it has no choice but to return structured findings.
- Planner → no execution tools at all; it emits a plan as text. Forcing the plan through a text boundary makes it inspectable and lets you gate before anything runs.
- Executor → the write/shell tools, but not search. If it needs a fact, it has to ask for it via the plan, which keeps the researcher’s step meaningful.
The effect is that the role isn’t just a system-prompt label anymore — it’s enforced by capability. An agent can’t drift out of its lane because the tools for the other lane aren’t in its hands. It also makes traces far easier to debug: when only one agent can write files, you always know who did what.
Two caveats. (1) You’ll occasionally need a tool in two roles (e.g. both read a shared store) — that’s fine, just don’t share the mutating ones. (2) Narrow tool lists also shrink the token cost of each agent’s tool schema, which is a nice secondary win on longer runs.
Anyone else enforcing role boundaries through tool scoping rather than prompt wording? Curious where the line breaks down for larger crews.