One agent per department
When a larger business starts building AI agents, the same pattern keeps showing up. HR gets its agent. Finance gets its own. Customer service gets its own. And on top sits an agent whose job is to hand out tasks between them.
It looks tidy. It resembles how the business is already organised.
According to a new article from Anthropic, that is often exactly the problem.
This is the fifth post in a series. We have written about the loop, about the stopping condition, about the night watch and about what happens when output becomes twelve times larger. This post is about how the agent itself should be built.
The agent becomes a copy of the org chart
There is an old rule in systems design called Conway's law: systems end up mirroring the organisation that builds them.
Anthropic sees the same thing with AI agents. Businesses often build subagents along team lines, so the architecture becomes a copy of the org chart. It is easy to see why. That is how responsibility is already divided, so it feels natural to build the same way.
The problem is that the customer, the employee or the case does not care about the org chart. One enquiry can involve an invoice, a contract and an access request at once. Then it has to pass through three agents, each of which only sees its own part.
What it costs
The article describes the costs quite concretely.
Details get lost along the way. Each subagent sends a summary back to whoever asked. It is like the telephone game: with every handoff, the picture gets a little less precise.
The instructions drift apart. When many specialists are written by different teams, you get rules that contradict each other and no shared voice. One company with a dozen specialist subagents struggled to keep them consistent.
Each team only measures its own part. Every department optimises its own agent, and leadership gets an overall picture that looks better than the whole actually works.
It takes time and costs money. Every subagent is its own loop with its own calls to the model. One customer got roughly twice the speed by moving to a single loop.
What they recommend instead
The alternative is one agent that brings in what it needs, when it needs it.
The article separates two things. Skills describe how a job is done: the domain knowledge and the routines. Tools take actions, fetch live data and enforce hard limits such as validation and approval. The agent only loads what is relevant to the task in front of it.
Tools should also be grouped by what the user is trying to get done, not one per system. The article points to experience that an agent gets worse at choosing the right tool once it has more than roughly 30 to 50 of them.
The result it describes is that one such agent often beat both a single large prompt and a setup with many subagents, on quality, time and cost.
When several agents actually are right
None of this means subagents are wrong. The article says they still belong, among other things in these cases:
When a single loop gets measurably worse because it is holding too much at once.
When work can run in parallel and each part needs a clean slate, such as independent lines of research.
When something needs to be checked by someone who did not do the work, what the article calls black-box verification.
The last one is worth pausing on, because it is exactly how we described the night watch plans. There, one agent does the work and another checks it without having seen the reasoning. That is not one department per agent. It is two roles that have to be kept apart. So the article and the night watch say the same thing: use several agents when the roles need to be independent, not because the organisation has several departments.
Rules belong in the tool
One point in the article deserves to be brought forward. Hard limits, such as approval and validation, belong in tools.
It is the same thing we did in the CRM we built in SharePoint. The requirement in the Norwegian marketing law is not in a procedure document. It is a lock in the board. An instruction is something an agent can misread or forget. A lock in the tool is something it cannot get around.
Responsibility can sit per department. The agent should not.
It is easy to mix up two things here.
We have previously recommended an AI committee with one owner per department. We still stand by that. The committee is about responsibility: who knows how the department works, where the limits should be, and who gets to say no.
How the agent is built is something else. There, Anthropic recommends that a small central team owns the whole agent from end to end.
That is not a contradiction. The departments own the knowledge and the rules. The central team owns the loop that uses them. The expertise from each department becomes skills and tools in one agent, instead of each department getting its own agent that nobody has an overview of.
How to go about it
The article gives a simple approach for those who already have many subagents:
Build a small test first. Around ten examples where you know what the right answer is, run from start to finish.
Fold in one subagent at a time, starting with the one that is used most.
Keep it only if the result gets worse without it. Otherwise it can be folded in.
Run every test more than once. In one of their examples, a regression only showed up in one of two runs.
And we would add one question before you split an agent at all: what is the user actually trying to get done? Start there, not with which department owns the task.
A caveat
The article is written by Anthropic, and it ends by pointing to a tool it offers itself for restructuring agents this way. The figures it uses are also few: "one customer", "one company". Read them as experience, not as measured truths.
But the main point holds whichever vendor you use. Structure comes first, and the structure that matters is the task's. Not the org chart's.