---
title: "Single agent vs multi-agent AI: how CTOs should choose"
description: "Single agent or multi-agent? Atallah says ten specialists beat one superagent. Masad runs one agent across Replit. Here's how CTOs should choose."
type: Essay
url: https://sunilkumar.ai/writing/single-agent-vs-multi-agent/
author: Sunil Kumar (https://sunilkumar.ai/about/)
datePublished: 2026-10-05
pillar: Architecture
tags: [agentic-ai, orchestration, multi-agent-systems, governance, approvals]
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
---

# Single agent vs multi-agent AI: how CTOs should choose

Single agent or multi-agent? Atallah says ten specialists beat one superagent. Masad runs one agent across Replit. Here's how CTOs should choose.

## In short

- Single agent vs multi-agent is really a question of accountability. One agent that does everything is easy to talk to and hard to debug. A team of specialists is harder to coordinate, but when something breaks you know whose it is.
- Masad's one-agent setup suits a chief executive, who can see everything. Most employees can't, and access control is what stops a typical team from having a truly general agent.
- Join on read, split on write: let one agent read across everything the user may see, and give every action to a specialist agent with narrow tools, its own evaluation set and a named owner.
- Split work that can run side by side and keep sequential reasoning in one agent. Google measured an 81 percent gain from coordinated agents on parallel financial analysis, and losses of 39 to 70 percent on sequential planning.
- Memory, web search and connectors are table stakes now. Pick an agent design by how it fails, who owns each action and what each agent is allowed to touch.

Two well-known AI founders disagreed on a podcast in October, and I think every enterprise is about to have the same argument with itself: a single agent, or a multi-agent system of specialists? Alex Atallah co-founded OpenRouter, the model router Stripe agreed in August to buy, for $7.5 billion according to The New York Times. He says ten specialist agents beat one superagent. Amjad Masad, who runs Replit, runs one agent across his whole company and loves what it can connect.

They're both right, about different halves of the work. Let one agent read across everything a person is allowed to see, because that's where a general agent really pays for itself. But anything that changes something should belong to a specialist agent with its own tools, its own tests and a named owner, because that's where the risk is. I call it join on read, split on write. It's what I tell CTOs who ask me whether to build a single agent or a multi-agent system, and it comes straight out of what building [Leverge's 306 agents](/writing/what-306-agents-in-production-taught-me-about-enterprise-ai/) taught my team.

> **Superagent**: A single AI agent given broad tools, memory and access across many domains, and expected to handle whatever a person or a company asks of it. The alternative is a multi-agent system: a team of specialist agents, each with one job, its own tools and an owner, usually with a coordinator in front.

## What Atallah and Masad actually disagreed about

Most of the conversation, hosted by a16z's Erik Torenberg, was about models, and on models they mostly agreed. Atallah's bet at OpenRouter is on what he calls neurodiversity: different models, trained in different ways, each routed to the job it does best. He said as much when the Stripe deal was announced: "no single model will be optimal for every task". Masad made a similar case from inside the enterprise, where companies increasingly need to own their AI capability rather than depend entirely on one model provider.

Where they split was personal agents. In a16z's summary of the episode, Masad runs one agent across his whole company and loves the cross-domain joins. Atallah thinks general agents make you "sacrifice understanding", and that ten specialised chiefs of staff beat one superagent. The caption a16z put on the clip gives his reason in a line: "One job each means you can see exactly where it's failing."

The most useful bit for anyone running an enterprise is easy to miss. Masad's setup works for Masad partly because he's the chief executive, with admin access. By one detailed account of the episode, he drew that line himself: the case against general agents applies more in the enterprise, where access control means individual employees and teams can't have a truly general agent. And Atallah admitted that nobody has yet built a team of specialists that's as easy to use as a single chat window.

So here's the trade. A superagent is easy to talk to and hard to debug. A team of specialists is harder to coordinate, but when something breaks you know whose it is. Neither side's argument depends on how clever the model is.

## Masad is right about reading

Most of what makes a general agent useful is the joins, and joins are reads. Think about the questions a chief executive actually asks on a Monday morning. Which of our twenty biggest customers have an open escalation, an overdue invoice and a renewal coming up this quarter? The answer lives in the CRM, the support desk and the finance system at once. Hand that question to three agents that can't see each other's work and you get three half-answers, plus a fourth agent to stitch them together.

Atallah's sharpest line was aimed at exactly these joins. The more work you give a personal agent, he said, "the more understanding of what's going on you're sacrificing". For reads, I think that's a price worth paying. You can check a join against the systems it came from, and if it's wrong you ask again. For writes, the same loss of understanding is how money quietly leaves the building.

Some of the research backs Masad here. Cognition, the company behind the Devin coding agent, argued in 2025 for a single-threaded agent, because agents that can't see each other's work end up making conflicting decisions. Its first principle is to "share context, and share full agent traces, not just individual messages". Anthropic says work where every agent needs the same context isn't a good fit for splitting today. The exception is a read that breaks into independent parts, which is where Anthropic's own research system does well, and even there a single lead agent owns the answer.

I run an agent like this myself. Every evening it reads our CRM, my inbox and the team's channels and sends me a report I can get through in five minutes: what's unresolved, what's slipping, who hasn't had an answer. It sees what I can see in those systems. It doesn't change anything until I say yes, and that's the part I care about most. If it misreads the pipeline one evening, I get a bad summary, and nothing has been paid, sent or deleted.

## Atallah is right about acting

Once an agent starts changing things, the question changes too. Forget how much it can see. What you need to know is who answers for it at two in the morning, and how quickly you can find the step that went wrong.

We learned this the hard way. Our first Leverge agents were single, capable agents that took a request all the way from intake to outcome. One model did the classifying, the retrieving, the deciding and the writing, from one prompt with one set of tools, and that prompt kept growing until nobody on the team could tell you what it did. Breaking each process into steps, each with its own agent, tools and refusal list, fixed more failures than any model upgrade ever did. Leverge's 306 ready-to-deploy agents now cover 93 processes, roughly three agents to a process.

Access is the other problem. An agent that can act everywhere needs permission to act everywhere, and in practice that means a service account with more rights than any employee has. It also means the first prompt injection that gets through can reach all of it. The [reference architecture](/playbooks/agentic-ai-reference-architecture-for-enterprise/) I use goes the other way: every tool checks who the agent is acting for, and read tools are handed out generously while write tools are handed out sparingly.

A US clinical-documents platform we built works this way. Extraction, classification and routing are separate agents, each working under HIPAA role-based access with an audit trail (the first two share one fine-tuned small model). Review time is down 74 percent and throughput is up two and a half times. When an extraction comes out wrong, there's exactly one agent to look at.

## Join on read, split on write

Put those two halves together and you get the multi-agent architecture I recommend to most enterprises. There's one agent at the front door, the one people actually talk to. It reads across every system the user is allowed to see, using that user's own permissions, and it plans and proposes. For a big question it can send read-only helpers off to search in parallel, the way Anthropic's research system does, but one agent owns the join and the answer. Behind it sits one specialist per action, each with narrow write tools, a refusal list, its own evaluation set and a named owner. Anything that can't be undone goes to a named human approver first.

This is my answer to the problem Atallah left open. People still talk to one agent. They don't need to know the specialists exist until something goes wrong, and then the specialists are the first place you look. The [agent harness playbook](/playbooks/agent-harness-decision-layer/) covers the same discipline at the seam: a model proposes from a menu the host prepared, and the host checks the pick, and can refuse it, before anything runs.

We rebuilt recruitment along these lines for an enterprise in the UAE. Recruiters work from one cockpit. Behind it, screening, job descriptions, candidate messages and scheduling are separate agents with separate jobs. Screening time is down 75 percent, a shortlist that used to take about ten days now takes 48 hours, and each recruiter handles three times as many open roles.

## The research tells you where to cut

The research doesn't say more agents are better, and it doesn't say never split. What it does is show you where the cut should go.

Anthropic's multi-agent research system, a lead agent directing sub-agents that search in parallel, beat a single agent by 90 percent on Anthropic's internal research evaluation. It also burned about 15 times the tokens of an ordinary chat, and Anthropic points out that most coding has fewer truly parallel parts than research does.

Google Research tested 180 agent configurations and found the same line from the other side. With a central coordinator, a team of agents did about 81 percent better on financial reasoning, which splits neatly into independent parts. On planning tasks that need strict step-by-step reasoning, the multi-agent versions did 39 to 70 percent worse. And agents working independently amplified errors about 17 times, where a coordinator kept that to about four. Cognition's second principle is a fair explanation of the sequential result: "actions carry implicit decisions, and conflicting decisions carry bad results".

![Where splitting helps and where it hurts, from Google Research's test of 180 agent configurations. Financial reasoning, which breaks into independent parts, improved by 80.9 percent with a coordinated team of agents. Planning that needs strict sequential reasoning got 39 to 70 percent worse with the multi-agent variants. Errors were amplified 17.2 times by agents working independently and 4.4 times under a central coordinator.](../../assets/images/writing/single-agent-vs-multi-agent-research.png)

A Berkeley-led team set out to answer why multi-agent LLM systems fail. They started from the observation that these systems' gains on popular benchmarks are often minimal, then identified 14 distinct ways they fail and published more than 1,600 annotated traces from seven frameworks. OpenAI's guide to building agents gives the plainest advice of the lot. Get as much as you can out of a single agent first, and only split when the prompt fills up with conditions or the tools start to overlap.

Microsoft's guidance for its cloud customers draws the line in much the same place. Start with a single agent, it says, unless something mandates separation: regulations or policies that require strict data isolation, distinct teams that own separate knowledge areas, or a solution that spans more than three to five distinct functions. Its reason for the first is the one I gave above. Least privilege limits the blast radius.

Put together, that's a short list of reasons to split: work that runs in parallel, a permission boundary, or a different team owning the knowledge. Everything else can stay with one agent, and a chain of reasoning should stay in one context. When you do split, put a coordinator over the specialists instead of leaving them to work blind to each other. That's join on read, split on write, seen from the research side.

## Everyone has memory and web search now, so ask how it fails

Atallah made a point on the episode that's worth taking into every vendor meeting. Notifications, connectors, context management, memory, sandboxes, web search, computer use, running always on: everyone building agents is building the same loop. He called these "the new table stakes primitives", like the database, the users table and the sign-in page every web app had in 2005.

So don't pick an agent design, or a vendor, from its feature list. Ask how it fails. Can you tell which step went wrong? Is there an evaluation set for each job? Who owns each action, and what is each agent allowed to touch? Memory and web search are the sign-in page of 2026, and nobody ever chose a system for its sign-in page.

Gartner expects 70 percent of multi-agent systems to use narrowly specialised agents by 2027, which it says will improve accuracy and increase coordination complexity. It also expects more than 40 percent of agentic AI projects to be cancelled by the end of 2027, over escalating costs, unclear business value or inadequate risk controls. In my experience specialists help with the third. They make the first one worse unless somebody owns the coordination, and moving the narrow, high-volume steps onto [small language models](/writing/small-language-models/) is how you win the money back.

For a client in the UK we built appointments and intake as a suite. Round-the-clock scheduling, no-show recovery, intake and the handoff into the client's practice management system are separate agents. No-shows are down 38 percent, and 76 percent of bookings now go through without anyone on staff touching them. Because each agent is measured on its own, a bad week points at one agent instead of at "the AI".

## Single agent or multi-agent: when to pick which

Here's the short version as a table. Read it against the work you're actually doing.

| If the work | Pick | Because |
| --- | --- | --- |
| Reads across systems for one person: briefings, research, analysis | One general agent, using that person's permissions | The value is in the joins, and a wrong answer costs you a second question |
| Changes a system of record: a customer record, a ticket, a booking | One specialist per action, with a named owner | One job, one set of permissions, one evaluation set, one place to look when it breaks |
| Can't be undone, or is regulated: a payment, a message to a customer, a deletion | A specialist plus a named human approver | The approval goes where the damage would be |
| Runs as a strict sequence, each step depending on the last | One agent, or a fixed workflow | Splitting sequential reasoning cost 39 to 70 percent in Google's tests |
| Breaks into independent parts that can run at once | A coordinator with parallel specialists | Big gains on parallel work, at many times the tokens |
| Crosses a permission boundary, say HR and finance | A specialist on each side of the line | No single agent should hold both sets of rights |
| Is new, and you don't know the jobs yet | One agent, with every call logged | The logs will show you where to cut |

![Which design fits, by what the agent does and whom it serves. One person, reading: one general agent, where Masad's case is strongest. One person, acting: one agent, with a human approver on anything irreversible. Many people, reading: one front door that reads with each user's own permissions. Many people, acting: specialist agents with named owners, where Atallah's case is strongest and where most of the work we see sits.](../../assets/images/writing/single-agent-vs-multi-agent-quadrant.png)

If you already have an agent running, these are the signs it's time to split it:

- Its prompt has branches nobody on the team can explain any more.
- Its tools overlap, and clearer names, parameters and descriptions haven't fixed it. OpenAI reports agents that manage more than fifteen well-defined, distinct tools, and others that struggle with fewer than ten overlapping ones.
- Two teams want different refusal lists for it.
- Incident reports say "the agent" instead of naming a step.
- One evaluation set can't cover everything it does any more.
- There's a narrow, high-volume step inside it that a small model could do for a fraction of the cost.

## If you are doing this in your company

Start by listing the actions, not the agents. For everything your AI does, write down whether it reads or writes, and whether it can be undone. That list is most of your architecture.

Give the reading to one agent that acts with each user's own identity. Never give it a service account with rights no employee has.

Give every write to a specialist with its own tools, refusal list, evaluation set and named owner. Anything irreversible gets a named approver, and you should watch the approver as closely as the agent. [The approver who said yes 1,900 times](/notes/the-approver-who-said-yes-1900-times/) is why.

Keep sequential reasoning in one agent. Run independent work in parallel under one coordinator, and budget for the tokens.

Measure each job on its own: success rate, cost and owner. Then, every quarter, merge the specialists that never fail and split any agent whose prompt keeps growing.

If you'd like a second opinion on an agent design before it meets production, that's what the production readiness review on the [work with me](/work-with-me/) page is for. Building the specialists is what Ailoitte's pods do.

## Sources

- a16z, [Why Specialized AI Could Beat The God Model](https://www.youtube.com/watch?v=ekK8urKHPMQ), The a16z Show, with Alex Atallah, Amjad Masad and Erik Torenberg, 3 October 2026.
- a16z, [episode post](https://x.com/a16z/status/2106408584460509308) and [clip of Alex Atallah on personal agents](https://x.com/a16z/status/2106466929859080501), X, 3 October 2026 (the summary of the disagreement, "sacrifice understanding", "one job each", Atallah's line on cross-domain joins).
- BigGo Finance, [Alex Atallah Says Stripe Deal Was About Keeping AI Plural, Not Building a God Model](https://finance.biggo.com/news/d02be89b3d0efcc4), 3 October 2026 (Masad's access-control caveat, Atallah on the elegance problem, "the new table stakes primitives").
- Stripe, [Stripe agrees to acquire OpenRouter to help businesses optimize token routing and usage](https://stripe.com/newsroom/news/stripe-agrees-to-acquire-openrouter), 19 August 2026 (Atallah's "no single model" quote).
- Bort, J., [Stripe didn't really buy OpenRouter because of the 'singularity'](https://techcrunch.com/2026/08/19/stripe-didnt-really-buy-openrouter-because-of-the-singularity/), TechCrunch, 19 August 2026 (the $7.5 billion price, from sources who spoke to The New York Times).
- Anthropic, [How we built our multi-agent research system](https://www.anthropic.com/engineering/multi-agent-research-system), 13 June 2025 (the 90 percent result, 15 times the tokens, poor fits for splitting).
- Kim, Y. and Liu, X., [Towards a science of scaling agent systems: when and why agent systems work](https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/), Google Research, 28 January 2026 (180 configurations, 80.9 percent, 39 to 70 percent, 17.2 and 4.4 times).
- Yan, W., [Don't Build Multi-Agents](https://cognition.com/blog/dont-build-multi-agents), Cognition, 12 June 2025.
- Cemri, M. and colleagues, [Why Do Multi-Agent LLM Systems Fail?](https://arxiv.org/abs/2503.13657), led by UC Berkeley, arXiv 2503.13657, March 2025, revised October 2025.
- OpenAI, [A practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf), April 2025.
- Microsoft, [Choosing between building a single-agent system or multi-agent system](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/single-agent-multiple-agents), Cloud Adoption Framework, Microsoft Learn, updated 10 December 2025.
- Coshow, T. and Zamanian, K., [Multiagent Systems in Enterprise AI: Efficiency, Innovation and Vendor Advantage](https://www.gartner.com/en/articles/multiagent-systems), Gartner.
- Gartner, [Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027](https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027), 25 June 2025.
- Ailoitte client examples are anonymised; the outcomes are from Ailoitte's 2026 case studies. Leverge's numbers are from [What 306 agents in production taught me about enterprise AI](/writing/what-306-agents-in-production-taught-me-about-enterprise-ai/).


## Questions people ask

**When should you use a multi-agent system instead of a single agent?**

When the work crosses a permission boundary, splits into parts that can run at the same time, or belongs to different teams. Microsoft's guidance names the same triggers: strict data isolation, separate teams owning separate knowledge, and solutions that span more than three to five functions. If none of those apply, start with one agent and split only when testing shows you have to.

**Is a single agent better than a multi-agent system?**

For work that runs as a strict sequence, often yes. In Google Research's tests, multi-agent setups did 39 to 70 percent worse on sequential planning, while a coordinated team did about 81 percent better on financial reasoning that splits into independent parts. The shape of the work decides it.

**Why do multi-agent systems fail?**

A Berkeley-led study of seven multi-agent frameworks found 14 distinct failure modes, grouped into system design issues, misalignment between agents and weak task verification. Google's tests add another reason: agents working independently amplified errors about 17 times, against about four under a central coordinator.

**Is multi-agent the same as agentic AI?**

No. Agentic AI is any system where a model plans and takes actions with tools. A multi-agent system is one way to build it, with several agents that each do part of the work, usually under a coordinator.

**What does join on read, split on write mean?**

It's the rule I use for agent design. Let one agent read across everything the user is allowed to see, with that user's own permissions, and give every action that changes something to a specialist agent with narrow tools, its own evaluation set and a named owner. Anything irreversible also goes to a named human approver.


---
Sunil Kumar, Co-founder and CEO, Ailoitte Technologies. https://sunilkumar.ai/about/