One AI Agent or Several?

"Turn this meeting transcript into an action-item table." How many agents does that take?

Usually one. It reads the text, pulls out the action items and outputs a table, and a clear task instruction and output format already keep the whole process in check. Split it up, and you might end up with this:

Agent A reads the meeting transcript
Agent B extracts the action items
Agent C checks the format
Agent D summarizes the risks

That looks thorough, but for a simple task it's too much: every extra agent adds a handoff, and when a handoff is unclear, information gets lost along the way.

Multi-agent setups are genuinely useful. Splitting adds communication, handoff and state-syncing costs, and you have to verify the benefit in practice. A simple task usually needs one agent. Consider splitting when responsibilities, tools or risk boundaries differ so much that one agent can't cover them. First check whether one agent can finish the task reliably, and when problems appear, ask whether splitting would fix that particular problem.

01 Start with a single agent

The first principle:

If one agent can do it reliably, use one agent.

Anthropic gives the same advice in Building effective agents: look for the simplest solution and add complexity only when needed, which may mean not building an agentic system at all.

When a single agent makes a mistake, read the process record first to see where it went wrong:

Outdated material    -> update the material (a split agent would still read the old file)
Unclear rules        -> fix the rules
Duties interfering   -> only now does splitting come into play

If a refund judgment is wrong because the policy file is outdated, an extra after-sales agent will probably read the same old file.

02 Five situations where splitting makes sense

Consider splitting when one of these shows up.

First, responsibilities differ too much. In a customer-service system, one task is helping people pick products and another is handling refunds. Their goals, tone, tools and risks are completely different. Put them into one agent, and it may reach for the refund tool while recommending products, or slip into sales talk during a refund.

Second, there are too many tools. An agent with product search, order lookup, refund requests, inventory updates, coupon issuing and support escalation all at once finds it harder to choose. The more tools it has, the less reliably it picks the right tool and permission.

Third, the instructions get too long. When one agent carries sales, after-sales, technical support, compliance and finance rules, its instructions grow long and the key boundaries get harder to uphold.

Fourth, the risk levels differ. Ordinary questions can be answered quickly, but refunds, payments and contract promises need strict confirmation. Handling them separately lets permissions and the strength of checks match the real consequences.

Fifth, model capability and cost differ. Tasks vary in weight:

Running every task on one heavy agent is poor value in speed and cost, while giving a complex task to an agent that's too light hurts quality. Splitting is sometimes just a way to hand each task to the right handler. After a split, each role's permissions and risk of overstepping need redesigning, which is what agent guardrails are for.

03 How multiple agents work together

The most common entry point for a multi-agent system is a router agent. It works out the user's intent and passes the task, with the context it needs, to the right specialist. A customer-service setup might look like this:

User input
  |
  v
Router agent: shopping, order status, refund, or tech support?
  |
  +-> Shopping agent: recommend products, compare options
  |
  +-> After-sales agent: look up orders, judge refund eligibility
  |
  +-> Tech-support agent: troubleshoot usage problems

The router works like a receptionist: it sends each request to the right handler, and the specialists handle the actual business.

Once the work is split among roles, can they start at the same time? That depends on whether they wait on each other. If two pieces of material are independent, they can be checked in parallel and handed to a named owner to combine. A refund judgment that needs the order lookup has to wait for the lookup to finish before the handoff. Parallel checks must also cover the same subject and use the same standard. If one side checks against the old policy and the other against the new one, the two reports can't simply be merged, and the final owner has to list the conflict first and ask for verification.

There's one more reason to stop: not enough permission, risk beyond what was authorized, or a question no one can judge. Then hand it to a person, who has the authority to supply what's missing.

04 Spell out five things for each role

A role's name is just a label. What makes roles cooperate smoothly is their responsibilities, inputs and outputs. For every agent, make five things clear:

What is it responsible for?
What is it not responsible for?
Which tools can it use?
When does it take over?
When does it hand back or hand off?

For example, an after-sales agent:

With clear boundaries, routing and handoffs stay steadier, and tasks conflict or fall through the cracks less often.

05 Handoffs lose information easily

The first common mistake is treating "more splits" as "more advanced." A simple writing task split across topic, research, drafting, review and polishing agents just adds waiting and compute cost. I care more about whether each role solves a real problem. The second mistake is "every agent can do everything": if every agent has all the tools, all the permissions and similar instructions, they fight over tasks and the point of splitting disappears.

The third mistake is losing information in the handoff. The receiving agent sees "hand to after-sales" but doesn't know what the user asked, which order it is or what has already been checked, so it has to ask again or judge on incomplete information. Then what about passing the full history? A shopping budget usually has nothing to do with this refund and matters only if the task also includes an exchange. Pick the information a handoff carries based on the work the receiver will do next. It should hold at least:

The user's original question
Facts already confirmed and the current status
Questions still unresolved
What the next agent needs to do
Boundaries it must not cross

For example: "The user is requesting a refund for order A; the order has been received; the applicable policy hasn't been verified; please have after-sales look up the policy and produce a recommendation; no refund may be submitted without human approval." Every statement in a handoff should also keep its source. If the original record says "the user says it was received," write exactly that, and change it to "the order system confirms receipt" only once the system has confirmed:

User says it was received   -> weak basis; may need a follow-up check
System confirms receipt     -> keep the source and the time of the lookup; use it while it's still valid

The fourth mistake is having no final owner. Several agents took part in the task, and someone still has to check that the final result is consistent, stays within the limits and can be delivered, so handoff errors don't carry through into what you deliver.