Skip to content

AI Systems

Multi-agent systems: one agent until it can't

Splitting work across several AI agents adds handoffs, traces and things to test. It's worth it when the parts need different records, tools or permissions, or can run at the same time. Then each agent gets a small context and a clear brief, every handoff has a defined shape, and one trace shows the whole run. For most businesses that means one well-built agent; we split the work only when the case for it is clear.
Discuss your systemSee the reasons that hold ↓
Objective · from the account managerPrepare Acme's SA-88 renewal pack: 14 units' history, open warranty claims, next year's visits.One agenttoolscontextjob records · 14 unitswarranty filessupplier portalcalendaragreementlimitover the limit · 11 toolsbefore: one agent, 11 tools, over the limitCoordinatorplans, delegates, assemblesHistoryjob records2 toolsWarrantywarranty, supplier2 toolsPlannercalendar, agreement2 toolsRun log · r-2140→ History, Warranty · briefs sent at the same time← History · 31 visits since 2023 · 3 repeat calls← Warranty · Unit 4B claim open with the supplier · needs a person→ Planner · brief with History's finding← Planner · 4 visits proposed for 2027Draft pack → account manager to review

Most agent teams should be one agent

Every extra agent is another context to manage, another handoff that can lose information, and another thing to test and pay for. These are the reasons we hear most, and why they don't justify a split on their own.
“It mirrors how our team is organised”Agents aren't staff. Splitting by job title adds handoffs without adding ability.
“More agents will give better answers”Each handoff passes on a summary, not everything. More agents usually means less context per decision.
“One agent kept getting confused”Usually a context or tool problem. Fix what it sees and what it can call before adding another agent.
“The framework makes it easy”Easy to build isn't the same as needed. The cost shows up later, in traces nobody reads.

Four reasons that hold

We split only when one of these is true, and we can say which.

  1. 01

    Records that don't fit together

    The context is the limit

    The job needs more material than one context can hold well. A specialist reading only job records, and another reading only warranty files, each sees what it needs and nothing else.

    a coordinator that ends up reading everything anyway.

  2. 02

    Permissions that should stay apart

    Least privilege, per role

    One part reads customer records; another may book visits. Separate agents with separate tools keep a mistake in one from reaching the other's systems.

    a shared tool that quietly gives every agent the same access.

  3. 03

    Work that can run at the same time

    The wait matters

    Independent parts, like history and warranty checks, run side by side instead of one after the other.

    “parallel” parts that each need the other's answer.

  4. 04

    Parts you can test on their own

    One brief, one set of cases

    A specialist with a narrow brief can have its own test cases, so a change to one doesn't need a rerun of everything.

    specialists whose output only makes sense after the coordinator rewrites it.

A handoff is a contract

brief · Coordinator → Warranty

task
Find open warranty claims for Acme's 14 units
inputs
unit list and serial numbers, from agreement SA-88
may use
check_warranty, supplier_status (both read only)
returns
per unit: claim id, status, source document
budget
30 tool calls, 2 minutes
stop and report if
a claim needs a decision, or a serial doesn't match
never sees
prices, customer messages, the calendar

Agents don't chat their way to an answer. The coordinator sends a brief with a defined shape, and the specialist returns findings with a defined shape, each pointing at the records it came from.

What a specialist never sees matters as much as what it does. The Warranty specialist can't see prices or the calendar, so it can't act on them, and its findings can be checked against the warranty records alone.

One run, one trace

Several agents still make one run. The trace shows who was asked what, what each one called, and what came back, so a wrong answer can be followed to the agent that produced it.

Run r-2140 · Acme SA-88 renewal pack

  1. Coordinatorplan

    3 specialists; History and Warranty at the same time

  2. Historybrief received

    units 1–14, jobs since January 2023

  3. Historyfind_jobs × 14

    31 visits

  4. Historyfinding returned

    31 visits, 3 repeat calls (4B, 7A, 11C)

  5. Warrantybrief received

    open claims, units 1–14

  6. Warrantycheck_warranty × 14

    2 claims open

  7. Warrantysupplier_status

    4B: waiting on the supplier since Oct 3

  8. Warrantyfinding returned

    4B open with the supplier; needs a person

  9. Plannerbrief received

    with History's finding

  10. Plannerread_agreement

    SA-88: two visits a year per system

  11. Plannerfinding returned

    4 visits proposed for 2027

  12. Coordinatorcheck

    every finding points at its records

  13. Coordinatordraft pack v1

    waiting for the account manager

Thirteen steps across four agents. Two things wait for a person: the 4B claim and the pack itself.

What a multi-agent system hands off

In

Objective
from a person
Roles
each with its own tools and context
Shared run state
briefs, findings, the log
Coordinator
plan → delegate → check → assemble

Out

Assembled result
each finding with its records
A trace per agent
every brief, call and finding
Escalations
what needs a person, and why

Worth splitting when you can name the reason

Good fit

  • The parts need different records or permissions that shouldn't mix.
  • Independent parts can run at the same time, and the wait matters.
  • Each part can be tested on its own, and someone will read the traces.

Not the right fit

  • One agent with better context and tools would do the job. Try that first.
  • The steps are known in advance. That's a workflow, with no agent at all.
  • Nobody will watch the runs or own the test cases.

Where a split can earn its place

Next to multi-agent systems

Questions about multi-agent systems

When do you recommend more than one agent?

Rarely, and only after a single agent has been tried with better context and tools. The usual reasons are records that shouldn't mix, permissions that should stay separate, or independent work that can run at the same time.

Don't several agents check each other's work?

A second model reviewing the first can catch some mistakes, but it doesn't replace checks in code and tests on fixed cases. We add a reviewing agent only where your test cases show it helps.

What does a split cost?

More model calls, more traces and more to test. That's why it has to pay for itself in something you can name: work that wouldn't fit one context, access that needs separating, or time saved by running in parallel.

Which framework do you use?

Whatever fits the system, often plain code around the model provider's tool calling. The roles and the shape of each handoff matter more than the framework that carries them.