Your AI agent doesn't need an org chart

The proposal on the table

Picture a proposal that lands on a retailer's desk this month. It's an invented example, but you've probably seen one like it. The company wants one AI assistant that can answer customers about orders, returns, shipping and the loyalty program. The plan has a router at the front that sorts each message, an orders agent, a returns agent, a shipping agent and a loyalty agent behind it, and an orchestrator on top that passes the conversation between them. Each agent belongs to the team that owns that part of the business.

It looks tidy. It also looks a lot like the company's org chart, and on Thursday Anthropic published a guide that says that resemblance is usually the problem.

The guide, Building agents: When to fold subagents into your main agent loop, came out October 22 and has been circulating among people who build agents on X ever since. It's worth reading if anyone is building or quoting an agent for you, because it changes what a sensible first design looks like.

What Anthropic actually said

The short version: for a lot of business agents, one agent that loads what it needs, when it needs it, beats a team of agents passing notes.

Anthropic's Applied AI team says that across several enterprise deployments, "a single agent with skills frequently outperformed both the one-prompt-for-everything design and the subagent design on quality, and often at a lower cost and latency per task." One customer that compared its multi-agent setup with a single agent loop "saw a roughly 2x faster runtime with the latter."

They're blunt about why so many designs end up split: teams give each problem its own subagent, "with the agent architecture becoming a copy of their org chart (Conway's law at work)." And they say plenty of proposals carry structure the model no longer needs. In those cases, "one clear system prompt, 4-5 thin data tools, and firm output guardrails would cover most of the use case."

The cost of splitting is mostly lost context. Every time one agent hands work to another, something gets summarized away. Anthropic's commerce agent guide puts it plainly: "Every handoff to a subagent is a state-lossy operation." The guide calls the back-and-forth a "telephone game." If you've ever had a support call transferred three times, you know the feeling from the customer's side.

Mark up the proposal, line by line

Go back to the retailer's plan and ask what each box is for.

The router. In the single-loop design there isn't one. The model reads the message and decides what to do next. Sorting messages into buckets before the model sees them is work the model can now do itself.

The planner. Same answer. In Anthropic's version, the model writes its own plan on the first turn and revises it as results come back. The thing that makes the plan is the thing that carries it out, so it can change course halfway through.

The four domain agents. These split in two. How the returns team does its work, meaning the steps, the rules and the judgment calls, becomes a skill: written instructions the agent loads only when a returns question comes up. Looking up an order, issuing a label or reading the loyalty balance become tools: actions with a fixed shape that call the systems you already run.

The approvals. These don't disappear. They move into the tools. A refund tool can check whether this customer, this amount and this user are allowed, and return a plain refusal the agent can read and explain. Turn limits and spending limits sit in the code around the loop.

The orchestrator. Gone, because there's nothing left to orchestrate.

Notice what didn't change: the teams. The returns team still owns returns. It just owns a skill and a couple of tools instead of a whole agent, and one small central team owns the main prompt and the overall quality checks.

When a team of agents is still the right call

This isn't a rule against subagents, and Anthropic says so. It still uses them in its own research system. The guide names three situations where splitting earns its place:

• The single agent measurably gets worse because its context is too full.
• Several tasks need to run in parallel, each with a fresh context you can throw away afterward.
• The single agent struggles to pick the right tool, or its instructions contradict each other.

One more practical point from the guide: there's a ceiling on tools. The guide warns that "once you exceed 30-50 tool definitions in the system prompt, tool choice tends to degrade," so tools should be grouped by what the user is trying to do, not one per API.

And if you do keep a specialist, the guide suggests calling it like a tool so the main agent keeps talking to the customer. A full handoff, where the specialist takes over the conversation, is for when it really needs to talk to the user directly.

So the honest answer to the one-agent-or-a-team question is: start with one, and add a second only when you can point to the reason.

Don't fold everything at once

If you already have a multi-agent system in production, the guide's advice is slow and careful, which we like.

Build a small end-to-end test set first. "Even a set of 10 golden examples is enough to start." Then fold in one subagent at a time and compare the results. Don't just look at the overall score. Look at which tasks flipped from pass to fail.

Anthropic gives a good example of why. When it tested this on a sample support agent, folding one subagent into another made it faster, but it also broke something that had been working. The main agent had the order lookup tool, so it answered on its own instead of asking the shipping specialist for the delivery date. And that break "only showed up in one run out of two," which is why the guide says to run each test more than once.

Its closing advice fits on an index card: "Build a small end-to-end eval, fold in one subagent, and keep it as a subagent only if the folded version scores worse." Anthropic also published a migration kit on GitHub that walks through the same steps on a demo system. If you want a starting point for the test set itself, our note on why you can't promote an agent on a demo transcript covers what goes into one.

What to ask whoever is building yours

If you're being pitched an agent, or you're about to commission one, these questions will tell you a lot in one meeting:

• Why does each agent in this design exist? Which of the three reasons applies to it?
• What would this look like as one agent with skills and tools? Did you try that first?
• Where do the approvals live? Show me the refund, the discount or the account change that needs a person.
• What test set will we use to compare designs, and who owns it?
• How many tools does the agent see at once?
• When the next model comes out, what has to change?

That last question matters more than it sounds. Anthropic notes that in migrations it has helped with, "rigid multi-agent structures were often what stopped the new model from doing more of the work." A simpler agent is easier to upgrade.

None of this makes the hard parts go away. You still need a clear job for the agent, clean data, firm limits on what it can change and a person on the decisions that matter. It just means the structure should follow the work, not the org chart.

If you're weighing a design like this, it's the kind of thing we help with in our AI applications and agents work. Bring us the proposal and we'll go through it box by box.

Related work: Spin:Market.