MULTI-AGENT ARCHITECTURE
FIELD NOTE 14 / 14Multi-agent AI is not a team of bots. It is a system of responsibilities.
Multi-agent AI can separate complex work across specialised agents. It can also multiply cost, delay and failure. The architecture earns its place only when every agent owns a necessary boundary.
Add another agent only when the work needs a new boundary—not when the prompt needs another personality.
SHARE THIS FIELD NOTE
Pass the useful signal on.
Multi-agent AI divides one outcome across several reasoning roles.
A multi-agent AI system uses more than one goal-directed AI component to complete a larger piece of work. One agent may decide what needs to happen, others may investigate or act within a specialist domain, and an orchestration layer coordinates the sequence, state and final result.
The agents do not need to sit in a group chat. A manager can call specialist agents as tools. Agents can hand work to one another. Independent agents can run in parallel and return evidence to a coordinator. Some steps may not be agents at all: a rule, database query or conventional workflow is often the better component.
That is less cinematic than the popular image of a digital team debating around a table. It is also more useful. A production system is defined by how responsibility, context and permission move—not by how many named personalities appear in a diagram.
The number of agents is an implementation detail. The division of responsibility is the architecture.
One capable agent should remain the starting point.
A single agent with clear instructions and distinct tools can already complete surprisingly varied work. It is easier to understand, faster to run and cheaper to evaluate than a network of agents. When it fails, there are fewer prompts, handoffs and state changes to investigate.
Adding an agent adds another probabilistic decision-maker. It also adds a communication boundary, another context window, more model calls and another place where the system can stop, repeat itself or confidently pass weak work downstream. Two agents can agree and still be wrong. A reviewer agent can reproduce the same blind spot as the agent it reviews.
Start with multiple agents because the work requires separation, not because the architecture looks advanced. If clearer tools, better context and a tighter operating specification make one agent dependable, a second agent is overhead rather than intelligence.
A new job title is not yet a new agent boundary.
Researcher, strategist, writer and critic are easy roles to place in four prompt boxes. But naming four personas does not prove that four independent agents are needed. The same model may receive overlapping context, use the same tools and judge every stage against the same vague instruction. The system has multiplied conversations without separating responsibility.
A meaningful agent boundary changes something operational. The agent may need access to data another agent must not see. It may use a different set of tools, work against a specialised knowledge base, run in parallel, follow a different evaluation standard or be owned by another part of the business.
The boundary should make the system easier to control or improve. If nobody can explain what becomes safer, clearer, faster or more accurate by separating the role, keep it inside the existing agent or implement it as a deterministic step.
Give every proposed agent a reason to exist on its own.
Multi-agent AI is justified when the work contains boundaries that should remain visible. These questions test whether a proposed agent owns one. A single strong yes may be enough when the consequence is material. A collection of weak maybes usually means the architecture is being designed around the trend rather than the task.
- Does this part of the work require context that would distract, overload or conflict with the context used elsewhere?
- Does it need tools or permissions that should be isolated from the rest of the system?
- Can it run independently or in parallel without depending on unfinished work from another agent?
- Does it require a distinct model, instruction set or definition of acceptable quality?
- Will a separate owner need to inspect, approve or improve this capability over time?
- Can its input, output and stopping condition be stated clearly enough to test the handoff?
RELATED FIELD NOTEAdd an agent where separation improves the system—not where another label improves the diagram.
A useful agent boundary defines scope, permission, thresholds, escalation and recovery—not merely a specialist label.
Your AI agent does not need more autonomy. It needs better boundaries.The orchestrator carries the responsibility the agents cannot.
Specialist agents do not become a system merely because they can exchange messages. Something must interpret the original goal, decide which work is required, allocate it, preserve the relevant state, handle dependencies and determine when the combined result is ready.
That coordinator may be an AI manager, deterministic workflow logic or a hybrid of both. The choice should follow consequence. Flexible reasoning is useful when the path depends on what the system discovers. Fixed routing is safer when policy already determines the next step.
The orchestration layer also needs limits: the maximum number of agents and turns, time and cost budgets, retry rules, approval points, escalation paths and a definition of done. Without those controls, collaboration becomes an open-ended loop funded by tokens and optimism.
A handoff needs a contract, not a conversation.
Many multi-agent failures happen between capable agents. The first agent returns a persuasive summary but omits the evidence the next agent needs. Two agents use different meanings for the same customer stage. An action agent receives a recommendation without knowing whether it was approved. Context becomes shorter at every handoff until the final agent acts on a confident abstraction of the original problem.
Define what every handoff must contain: the task, relevant evidence, source references, assumptions, confidence, decisions already made, allowed next actions and the condition for returning the case. Structured outputs help, but the schema matters only when it represents the business meaning the next agent needs.
Shared memory should not mean giving every agent the entire transcript. It should mean maintaining governed state: current facts, decisions, ownership and history that agents can read according to their role. More context is not the same as common understanding.
Do not turn the organisation chart into an agent architecture.
Imagine a system responding to a meaningful account signal. One component gathers the event and validates the account. A research agent investigates the company and buying context. A decision agent compares that evidence with qualification rules. A channel specialist prepares the appropriate response. A human approves a high-consequence action before the CRM and outreach tools are updated.
That can justify multiple agents because research, commercial judgment and external action need different context, tools, permissions and evaluation. It does not require separate marketing, sales and customer-service agents simply because those departments exist. Recreating departmental boundaries may reproduce the very fragmentation the system should remove.
The agents should work from shared customer and business context while remaining narrow in authority. Marketing evidence can improve a sales decision. Service history can stop an inappropriate acquisition message. The orchestration should connect the customer journey, not automate each silo more efficiently.
Evaluate the specialists and the system they become together.
A good result does not reveal which part of a multi-agent system deserves credit. A bad result does not reveal where the failure began. Operating the system requires traces that show delegation, evidence, tool calls, state changes, handoffs, retries and the final action.
Evaluate each agent against its own responsibility, then evaluate complete runs across realistic cases. Measure whether agents duplicate work, contradict one another, lose evidence, exceed budgets or create delays that erase the benefit of parallel execution. Test partial failure: one agent times out, a source is unavailable, permission is revoked or two results disagree.
Name an owner for the whole outcome. Specialist ownership is useful, but customers and revenue teams experience the combined result. Someone must be accountable for deciding whether the architecture still needs every agent—and for removing one when a simpler system can now do the work better.
Multi-agent AI earns trust when responsibility becomes more visible, not more distributed.
Evidence and further reading.
Practical guidance on starting with a single agent, introducing multiple agents when logic or tool selection becomes difficult, and choosing manager or handoff patterns.
02Anthropic: How we built our multi-agent research systemA production account of orchestrator-worker architecture, parallel research, delegation failures, token cost, observability and evaluation.
03Microsoft: Choosing between a single-agent and multi-agent systemDecision guidance covering separation of concerns, security and compliance boundaries, multiple teams, scalability and the additional coordination burden.
04AWS: Multi-agent orchestrationWell-Architected guidance on agent coordination, orchestration patterns, shared context, failure handling, observability and governance.
