"Our platform uses multiple intelligent agents" has become a standard line in supplier presentations. The slide usually shows an orchestrator in the middle and five or six specialist agents around it: an intake agent, a research agent, a planning agent, a compliance agent, a communication agent. It looks sophisticated. It tells you almost nothing about whether the system is well designed.
A multi-agent design is a decision about how to divide work, permissions and accountability. In that sense it resembles an organisation chart more than a feature list. Like an organisation chart, it can create useful separation of duties, or it can create handoffs, duplicated effort and nobody owning the result.
Our article Delegation does not remove accountability examined what each handoff between agents must carry. This part addresses the earlier question: should you split at all? We continue with Ubuntu Municipal Services, the fictional municipal entity in this series.
Ubuntu's two proposals
Ubuntu received two designs for its service-resolution agent.
The first had six agents: one to read the complaint, one to check the schedule, one to verify the address, one to manage the case, one to write to the resident and one to decide escalation. Each was a separate prompt with its own model call. An orchestrator passed the work between them.
The second had one agent for the whole resolution, with a small set of tools, and a separate checking agent that reviewed every work order before it went to a supervisor. The checker had read-only access and a different set of instructions, and it was evaluated against a different test set.
The second design had fewer agents and more real structure. The first design's six agents all ran with the same permissions, served the same goal and shared nearly all their context. Splitting them added five handoffs and no new boundary.
When a split earns its place
A separate agent is justified when it creates something a single agent cannot:
- Separation of duties. The maker and the checker must be independent. A checker that shares the maker's context and instructions tends to agree with it. Ubuntu's work-order checker sees the proposed order and the evidence, not the maker's reasoning.
- Different permissions. One part needs write access to a system and another must not have it. Splitting lets each run under its own identity with its own limits, which is the authority principle from Part 4 applied to structure.
- Different evaluation. Parts are judged by different criteria or experts. A resident-facing writer is evaluated on clarity and tone; an escalation decider on policy compliance. Separate agents make separate test sets easier to maintain.
- Independent failure. One part must keep working when another fails, or must be replaceable without retesting the rest.
If none of these applies, a single agent with well-designed tools is usually simpler, cheaper and easier to trace.
What every split costs
Each additional agent adds four things the organisation has to pay for and govern:
- A handoff contract. What information passes, in what form, and what the receiver may assume. Lost context at handoffs is one of the most frequent multi-agent failures.
- A separate trace. Reconstructing a run now means stitching together several agents' records. Without a shared run identifier, that becomes guesswork, as we noted in A trace is not an evaluation.
- A separate evaluation. Each agent needs its own tests, and the combination needs end-to-end tests as well, because correct parts can produce an incorrect whole.
- A named owner. Someone must be accountable for each agent's behaviour and changes, and someone for the outcome of the whole.
There is also a direct running cost. More agents usually means more model calls per case, more tokens spent restating context, and more latency. Our article Subagents are a cost-control pattern shows that splitting can reduce cost when it isolates expensive work, and increase it when it simply repeats context.
Coordination debt
When a multi-agent system grows without these disciplines, it accumulates what we call coordination debt: implicit assumptions between agents that nobody documented, failures that bounce between agents without resolution, and outcomes that no single owner can explain. The symptoms are familiar from human organisations. Work stalls between teams. Each part reports success while the whole fails. Changes to one part break another in ways nobody predicted.
Coordination debt is invisible in a demo, because demos use happy-path cases. It appears in production, under load and with odd cases.
What Ubuntu chose
Ubuntu chose the second design and made one change to it. The checking agent's verdict is shown to the supervisor alongside the work order, but it cannot approve anything itself. It can only flag a concern, with the evidence. That keeps the separation of duties without creating a second approver whose judgement nobody had tested.
The team also agreed a rule for the future: a new agent can be added only when its proposer can name the boundary it creates, the identity it will run under, the test set it will be judged against and the person who will own it. During the pilot, that rule turned down two proposals and approved one, a resident-facing translation agent with no write access at all.
Questions to ask about a multi-agent design
- What boundary does each agent create that a single agent could not?
- Do the agents run under different identities and permissions?
- What exactly is passed at each handoff, and where is that contract written?
- Can you reconstruct one case end to end across all agents, from a single identifier?
- How is each agent evaluated, and how is the whole evaluated?
- Who owns the outcome when every agent reports success and the resident is still unhappy?
If the answer to the first question is "each agent is a specialist", ask what makes it special: a different tool set, a different permission, a different evaluator. If the answer is a different prompt, the split is cosmetic.
Key points
- A multi-agent design is an organisational decision about duties, permissions and accountability.
- Split for separation of duties, different permissions, different evaluation or independent failure.
- Every split adds a handoff contract, a trace, an evaluation and an owner, plus running cost.
- More agents on a slide is not evidence of production maturity.
Next: Part 8, They say they have agents. Ask these questions. All parts are on the series page.
How CloudNala can help
CloudNala reviews multi-agent designs before they are built or bought. We test whether each agent creates a real boundary, design the handoff contracts and identities, and set up end-to-end traces and evaluations, so that the structure supports accountability rather than hiding it.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Agent Due-Diligence Review or write to us at consult@cloudnala.co.za