MULTI-AGENT ARCHITECTURE

FIELD NOTE 14 / 14

Multi-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.

2 September 20268 min readTeams deciding whether one AI agent is enough
THE CENTRAL THOUGHT

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.

POST OR MESSAGE
STORY OR STATUS
Opens the share sheet on supported phones. Otherwise, the vertical card downloads.

01The useful definition

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.

02The default

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.

03Beyond role play

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.

04The decision test

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?

Add an agent where separation improves the system—not where another label improves the diagram.

RELATED FIELD NOTE

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.
05The control layer

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.

06Where systems break

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.

07A commercial example

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.

08After the demo

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.

THE WEEKLY COMPANION

Fresh AI signal, commercially folded.

AI Laundry watches the week. Field Notes makes the durable ideas useful.

No daily noise. No recycled hype. Unsubscribe any time. See our privacy policy.