No. One agent doing everything is harder to certify, harder to bound and harder to stop without stopping all your work. Split agents by role, and within a role by how reversible the actions are. The opposite mistake, a separate agent for every small task, creates coordination overhead. Aim for roles a person could describe in a sentence.
Why is one agent for everything a problem?
Certification gets harder. Each capability must be proven on real cases. An agent that answers questions, processes refunds, updates records and drafts letters needs evidence for all of them. When one capability fails, the whole agent's standing is in question.
Bounds blur. An agent with many tools is likelier to pick the wrong one, and its data scope grows to cover every task. It ends up able to see and do far more than any single task needs.
Separation of duties breaks. If the same agent prepares a payment and validates it, you have removed a control that exists for people for good reason.
Stopping it stops everything. When something goes wrong with an all-in-one agent, reducing its depth affects every process it serves. A narrower agent can be stopped while the rest carry on.
Accountability spreads thin. Several business owners share one agent, and nobody owns its behaviour end to end.
What is the opposite mistake?
Splitting too finely. A separate agent for each step of a process means many handoffs, more coordination, more places for context to be lost, and more certificates to maintain. If two agents always run together and never separately, they are probably one role.
The balance is roles, not tasks: "accounts payable matching" is a role; "extract the invoice date" is a task inside it.
How should you split?
| Split by | Example | Why |
|---|---|---|
| Business role | Support, collections, onboarding | Each has its own owner, data and limits |
| Reversibility | Draft letters versus send payments | Different depths, different certification |
| Separation of duties | Prepare versus approve | A control you keep for people should hold for agents |
| Data sensitivity | Fraud investigation versus customer service | Keeps sensitive data out of customer-facing agents |
| Coordination | Orchestrator versus workers | Coordination is its own capability at depth 5 |
What does this look like in practice?
Take a small online lender that started with one agent handling everything after a loan application: document checks, affordability, decision drafts, customer emails, repayment set-up and arrears contact.
When a model update caused the agent to misread one bank's statement format, its affordability work failed certification. Because it was one agent, its depth dropped across the board, and customer emails and repayment set-up stopped too. The lender split it into four agents: application review, customer communication, servicing and collections. Each was certified on its own cases. The next time a statement format changed, only application review dropped to depth 1, and the other three kept working. Running them together is covered in how to run several AI agents under one orchestrator.
What does splitting require from the platform?
More agents means more to keep consistent. The platform has to hold every agent's authority in one source of truth for what agents may do, route handoffs between them through one governing layer, and stop one agent's mistakes reaching the others, as covered in how to stop one agent's mistake spreading to others. The jobs involved are taken one by one in the seven jobs of an agentic OS.
Start with one narrow agent in one team. A pilot of a single, well-bounded role teaches you how certification, limits and approvals work in your business before you add more; see how to run a pilot of an AI agent in one team. Add the second agent when the first is stable and the next role is clear.
What stays with a person?
Deciding how roles are split, who owns each one, and which actions stay with people regardless of how agents are arranged. The full governing design is in the governed agentic operating system guide.
Questions people ask
Is a general assistant agent ever the right choice?
For internal, read-only help, such as answering staff questions from policy documents, a broad agent can work well. The problems arise when one agent also acts across many processes.
Do more agents cost more to run?
Not necessarily. Cost follows model calls and work done, not the number of agents. Narrow agents often use fewer tokens per task because their context is smaller.
How do customers experience several agents?
They should not notice. A single front door, such as a chat or email address, can route to the right agent behind the scenes, with handoffs carrying the context.