VI · Multi-AgentEmerging★

One Tool, One Agent

also known as Specialist-Per-Tool Design, Microservices-Style Agent Decomposition

Design agent systems as a team of narrow single-purpose agents, each owning one tool or one capability, rather than a single super-agent that handles every tool — the agent analogue of microservices over monolith.

Context

A team designs a workflow agent. The temptation: one big agent with the full tool catalog, doing 'everything'. Reality: this monolith is hard to debug, hard to evaluate, hard to evolve, and often performs worse than specialized agents because the LLM has to context-switch across too many tool semantics.

Problem

Monolithic agents accumulate complexity in one prompt and one tool catalog. They debug poorly (where did this fail?), evaluate poorly (which capability regressed?), evolve poorly (every change risks every workflow). They often degrade because the LLM's attention is split across too many tool semantics.

Forces

  • Multi-agent decomposition adds orchestration overhead.
  • Specialist agents have to communicate, with handoff cost.
  • More agents = more cost = more model calls.

Example

A newsletter automation system. Naive: one super-agent that does search, summarization, formatting, delivery. Result: hard to debug, summarization regression when search prompt changed. With One Tool One Agent: Search Agent (finds articles), Summarization Agent (3-bullet summaries), Email Agent (sends daily), Compiler Agent (organizes selected articles), Newsletter Formatting Agent (Mon publication), Manager Agent (coordinates). Each has narrow scope and its own eval. Result: 300k subscribers in one month, debuggable.

Diagram

Solution

Therefore:

For each major capability the system needs (search, summarization, formatting, delivery), instantiate a dedicated specialist agent. Add a manager / orchestrator agent that decomposes user requests and routes to specialists. Each specialist owns its narrow tool catalog and has its own eval suite. Pair with orchestrator-workers, supervisor, hierarchical-agents, multi-agent-sequential-degradation awareness (don't decompose what's intrinsically sequential).

What this pattern forbids. No specialist owns more than one tool / capability; the orchestrator owns coordination only, not domain logic.

And the patterns that stand alongside it, or against it —

  • complementsOrchestrator-Workers★★— An orchestrator dynamically breaks a task into subtasks at runtime and delegates each to a worker LLM, then synthesises results.
  • complementsSupervisor★★— Place a coordinating agent above a set of specialised agents and route work to them.
  • complementsHierarchical Agents★★— Organise agents in a tree where higher-level agents decompose tasks for lower-level agents, recursively.
  • complementsMulti-Agent on Sequential Workloads✕— Anti-pattern: split a fundamentally sequential workload across multiple agents, degrading accuracy by 39–70% with no parallelization benefit.
  • complementsTwo Human Touchpoints★— Place exactly two human-in-the-loop checkpoints in agentic pipelines: one at content selection and one at final review before publication.
  • complementsMagentic-One Generalist Multi-Agent★— Use Microsoft's generalist multi-agent architecture: a single Orchestrator agent dispatches to four specialist sub-agents (WebSurfer, FileSurfer, Coder, ComputerTerminal) for solving open-ended complex tasks that span web browsing, file manipulation, code execution and shell operations.
  • alternative-toHierarchical Tool Selection★— Organise tools into a tree of categories so the agent first picks a branch and then a specific tool within it.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

References

Provenance