Once an assistant has memory, retrieval and tools, someone will propose splitting it up. An outage agent, a billing agent, an installations agent, a router agent and an orchestrator to send each conversation to the right one. It looks tidy on a whiteboard. It mirrors the organisation chart. And it often makes the system harder to build, harder to test and harder to trust.
More agents do not automatically mean better architecture. Each one is another component with its own prompt, tools, failure modes and evaluation, and, more importantly, another set of relationships with every other agent. Most of the trouble in multi-agent systems lives in those relationships, not in the agents.
This part explains how Umgeni decided, and why it ended up with exactly one split.
The proposal on the whiteboard
Umgeni Fibre is fictional, and its systems and figures are illustrative. After Part 6, the assistant handles outages, router questions, installation status and simple billing queries, with four tools and a loop that hands over cleanly when stuck. Its prompt has grown, and a developer suggested the five-agent design: one per category, plus an orchestrator.
The team asked what problem it would solve. The answers were mostly about tidiness: smaller prompts, clearer ownership in the code, the feeling that each agent could be "specialised". None was a measured failure of the current design. The assistant was not getting outages wrong because its prompt also mentioned billing.
Then they counted the relationships.
Every new agent increases the number of failure relationships
With five agents that can pass work to each other, there are up to ten pairs. Each pair is an interface where something can go wrong:
- Context is lost in the hand-off. The outage agent knows the customer is verified and their line has been down for two days; the billing agent receives "customer wants a refund" and asks them to verify again.
- Each side thinks the other acted. The orchestrator hands a mixed ticket ("my line is down and you billed me twice") to the outage agent, which handles the outage and assumes billing will be picked up somewhere.
- Work bounces. Agent A decides the case belongs to B, B decides it belongs to A. Without a rule, the customer waits while two components pass the case back and forth.
- Blame becomes hard to find. When an answer is wrong, the trace now spans several prompts, several models and the routing decision between them. Which one failed?
In Part 2, mixed-problem tickets were already the classifier's weakest point. A design that splits work by category makes exactly those tickets harder, because they must now be split, handed off and reassembled. The proposal would have turned the system's known weakness into an architectural feature.
Umgeni kept one assistant and gave it better tools and a tighter prompt instead.
Three tests for a real split
The team did not ban multiple agents. They agreed tests a split must pass, and a component would be separated only if it passed at least two:
- Different data permissions. Does this work need access the rest of the system must not have?
- Different owner and reviewer. Is a different team accountable for its outcomes, with its own people reviewing its decisions?
- Different evaluation. Does it need its own test set and its own definition of "good", which would be diluted if mixed with the rest?
Most proposed splits fail all three. Outages, router faults and installations use the same identity, the same support team and overlapping test sets. They are categories of one job, not separate responsibilities.
Billing disputes were different.
The one split that earned its place
Customers disputing a charge need someone who can look at invoices, payment history and adjustments in the billing system, and who is allowed to propose a credit. At Umgeni that authority sits with the finance team, not with support. Giving the support assistant's identity write access to billing would have meant one component holding both customer-service and finance rights, which is precisely the concentration of authority that segregation of duties exists to prevent.
So billing disputes passed all three tests: different permissions (billing system access), a different owner and reviewer (a finance clerk approves every adjustment), and a different evaluation (accuracy of the proposed adjustment against the invoice, which is meaningless for outages).
Notice what the split is: a billing dispute workflow, not a second free-roaming agent. It is a defined sequence owned by finance, with one model step that reads the invoice history and drafts a summary and a proposed adjustment for the clerk. The support assistant hands over, tells the customer what will happen and by when, and stops. Where one agent should end and a deterministic workflow begin is a question worth asking every time; chapter 7 of the Production AI Case Study works through it for a bank.
The hand-off is a contract
The split only works if the hand-off is as carefully defined as the model's output in Part 3. Umgeni's is a small, versioned schema:
{
"contract_version": "dispute_handoff.v1",
"case_id": "C-20461",
"ticket_id": "T-90377",
"account_ref": "acct_tok_2b91",
"verified": { "method": "otp_sms", "at": "2026-10-14T10:40:00+02:00" },
"disputed_invoice": "INV-2026-09-55812",
"customer_statement": "Charged twice for September",
"other_open_issues": ["line intermittent since 2 Oct"],
"promised_to_customer": "Finance will reply within 2 working days"
}
Three fields do most of the work. verified means finance does not ask the customer to prove who they are again. other_open_issues means the line fault the customer also mentioned is not silently dropped: the support assistant keeps that part of the case. And promised_to_customer records exactly what was said, so finance knows what commitment it has inherited.
Two rules complete the contract. The case_id travels with every step on both sides, so one trace shows the whole case. And a case can be handed over once; if finance decides it is not a billing dispute after all, it returns to a person in support, not back to the assistant. That single rule removes the bouncing problem.
How to test a hand-off
Umgeni's tests now include the relationship, not just each side:
- A mixed ticket produces one hand-off for the billing part and keeps the line fault with support.
- Finance receives the verification and does not re-verify.
- The customer is told what will happen, and the promise in the hand-off matches the message they received.
- A case returned by finance goes to a person, never back into the assistant.
- One trace with one
case_idshows both sides end to end.
If you cannot write tests like these for a proposed split, you are not ready to make it.
When to look again
The decision is not permanent. Umgeni wrote down the signals that would reopen it, so the question is revisited on evidence rather than whenever someone redraws the whiteboard.
If installations move to a partner company with its own scheduling system and its own staff reviewing decisions, the installation work would gain a different owner and different permissions, and might pass the tests. If business customers get contractual service levels with credits for breaches, the work of assessing those credits would need its own evaluation and a different reviewer. If the single assistant's prompt and tool list grow until its own evaluation results start to fall in one area while staying steady elsewhere, that is a measured failure worth investigating, though the first fix to try is usually better tools or a clearer prompt rather than a new agent.
What does not reopen it: a new framework that makes multi-agent designs easier to draw, or a feeling that the prompt is long. A long prompt is a maintenance question. A separation of responsibility is an architecture question.
Key points
Agents add relationships, not just capacity. Up to n(n-1)/2 hand-offs, each an interface that can fail.
Do not split by category. Categories of one job share identity, owner and tests; splitting them adds hand-offs and fixes nothing.
Split on responsibility. Different permissions, different owner and reviewer, different evaluation: pass at least two.
A split can be a workflow. A defined, owned sequence with one model step is often better than a second agent.
Make the hand-off a versioned contract. Carry verification, open issues and promises, and allow one hand-over only.
Next: Part 8, How to present an AI portfolio to an architect and a business leader. All parts are on the series page.
How CloudNala can help
We review multi-agent designs before they are built, asking what each split is for, what it costs in hand-offs and testing, and whether a workflow or a better tool would do the job. Where a split is justified, we help define the hand-off contract and the end-to-end trace so that two components can be trusted together.
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.
Plan an AI MVP Build Sprint or write to us at consult@cloudnala.co.za