A familiar proposal arrives once an agent starts working well: split it up. Instead of one HR agent that answers policy questions, reads payslips and opens cases, build an orchestrator that understands the request and hands it to specialists. A policy agent. A payroll agent. A leave agent. Each one smaller, each one easier to test.
There are good reasons to do this sometimes. Specialists can run with narrower permissions and smaller context, and a team can own each one. But the proposal often hides an assumption: that delegating a task to another agent also delegates the responsibility for it. It does not. When something goes wrong three hops down a chain of agents, an employee still received a wrong answer, a payslip was still shown to the wrong person, or a correction was still made twice. Someone in the organisation still answers for it.
CloudNala's view is that a multi-agent design is acceptable only when every hop carries an owner, a bounded authority and a record, and the person's identity and scope travel with the request. Without that, adding agents adds failure paths faster than it adds capability.
This is Part 2 of The Agentic Enterprise. Our earlier piece Add multiple agents only when work really has separate responsibilities covered when to split. This one is about what each split must carry once you do.
The Karoo proposal
Karoo Mills is fictional, and its systems and figures are illustrative. After the durable-state work in Part 1, Karoo's HR service agent was handling around 1,800 conversations a week across WhatsApp and Teams. The payroll team asked for its own agent. Payroll questions were the most common category, and the payroll operations lead wanted a specialist that understood payslip codes, tax directives and deduction rules in more depth than the general agent did.
The architecture team drafted an orchestrator with three specialists: policy, leave and payroll. On paper it looked cleaner. The review that followed asked one question of every arrow in the diagram: who answers for what happens here?
Four things a hop must carry
Every time one agent passes work to another, four things need to cross the boundary with it.
The person's identity and scope. The orchestrator knows it is talking to a verified employee at the Kroonstad mill. The payroll agent must act on behalf of that employee, with that employee's access, not with its own broad service permissions. If the payroll agent can read any payslip because it runs under a powerful service account, the orchestrator has effectively granted every employee access to everyone's payslip through a single mistaken routing decision. This is the same principle covered in Identity before intelligence: the model's request should carry the caller's authority, never replace it.
A typed task, not a chat transcript. When the orchestrator forwards "the user is asking about a deduction they don't recognise, see the conversation above", the specialist has to infer what is being asked. A typed record (employee ID, payslip period, deduction code, the employee's question in their own words) is testable and auditable. A pasted transcript is neither.
An owner. Each agent needs a human owner who is responsible for its behaviour, its evaluation set and its changes. Not "the AI team", a named role. For Karoo, the orchestrator belongs to the HR service desk lead and the payroll agent belongs to payroll operations.
A record. Each hop writes what it received, what it did and what it returned, linked to the same thread ID. Without that, a failure three hops down is indistinguishable from a failure at the first.
Where handoffs fail
Karoo's review produced a short list of failures that every multi-agent design should expect. None of them is exotic. They are the predictable cost of adding boundaries.
The last row deserves emphasis. When a specialist returns a fluent paragraph to the orchestrator, the orchestrator tends to pass it on, and any failure inside it is smoothed over. A payroll agent that could not reach the payroll system might return "Your deduction appears to relate to a standard adjustment." That sentence is plausible and wrong. If instead the specialist returns a structured status (lookup_failed, answer_with_source, needs_human), the orchestrator can respond honestly. We explored this pattern in depth in When the tool fails but the answer looks complete.
Accountability does not divide
There is a tempting arithmetic in multi-agent designs: four agents, four owners, so each owner carries a quarter of the risk. It does not work that way. The employee experiences one service. When it fails, the organisation is accountable for the whole outcome, and someone needs to own that whole.
Karoo resolved this with a simple rule. The service owner, the HR service desk lead, is accountable for the end-to-end employee outcome regardless of how many agents sit behind it. Component owners (payroll operations for the payroll agent, the HR policy team for the policy agent) are accountable to the service owner for their component's behaviour and evaluation results. The service owner can refuse to route to a component that is failing its evaluations, the same way a product owner can refuse a dependency that keeps breaking.
That mirrors how organisations already run shared services. A call centre does not stop being accountable for a customer's experience because the query was transferred to the billing department. The agent version simply makes the transfers faster and less visible, which is exactly why they need to be recorded.
When the split is still worth it
None of this argues against multi-agent designs. It argues for paying their real price. Karoo's review approved a payroll specialist, with conditions, because three things were true:
- Separate permissions. Payslip and tax data needed narrower access than policy content. A separate agent with its own scoped access made that boundary easier to enforce and audit.
- A separate owner with a separate evaluation set. Payroll operations was willing to own the agent, maintain 120 test questions with known answers, and review failures weekly.
- A stable, typed interface. The orchestrator and the payroll agent agreed a small contract: the fields in, the statuses out, the timeout and the fallback when the payroll agent is unavailable.
The review rejected the separate leave agent. Leave questions used the same data and permissions as the general agent, had no distinct owner, and the split would have added a handoff without removing any risk. Leave stayed in the main agent.
A checklist for every arrow
Before approving a multi-agent design, draw every handoff and ask:
- Whose identity and scope does the receiving agent act under?
- What typed record crosses the boundary, and is it validated on arrival?
- Who owns the receiving agent, by role?
- What statuses can come back, and does the caller handle each one honestly?
- What prevents the same business action being taken twice if a hop retries?
- Where is the hop recorded, against which thread ID?
- Who owns the end-to-end outcome when a hop fails?
If any arrow cannot answer all seven, it is not ready. Either fix the arrow or remove it.
For the bigger picture of how a single agent's loop works, see The AI agent loop. For the evidence a production agent should leave behind, see Your agent spent the money. Can you prove why?.
Next: Part 3, An HR service agent is an integration project. All parts are on the series page.
How CloudNala can help
We review multi-agent designs one handoff at a time: identity propagation, typed contracts, statuses, idempotency, ownership and the end-to-end accountable owner. Where a split does not earn its place, we say so and help simplify the design before it reaches production.
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 Agentic AI Architecture Review or write to us at consult@cloudnala.co.za