Success creates its own pressure. By Chapter 6, Impala Bank's assistant could answer public questions, explain a client's own account, look up transactions and debit orders, and take three bounded actions. Clients liked it. The obvious next proposals arrived quickly: let it handle debit-order disputes, fraud reports and complaints too. And from the architecture side: split it into a team of specialist agents, a disputes agent, a fraud agent, a complaints agent, coordinated by a supervisor.
Both proposals assume the assistant should keep growing until it does everything. Chapter 7 is about where that assumption breaks, and why the right boundary for a bank is usually not between one agent and many agents, but between conversation and case.
Where we are in the case study
Impala Bank is fictional, and its systems and figures are illustrative. After Chapter 6, Ask Impala can request confirmation letters, freeze cards and order replacements, each prepared from the bank's records, confirmed on a native app screen, submitted idempotently and recorded. Payments, payees, limits and contact details remain permanently outside its scope.
Questions end; cases continue
The questions Ask Impala handles so far share a shape. They begin and end within one conversation. The client asks, the assistant answers or acts, and it is done.
Disputes, fraud reports, hardship requests and formal complaints have a different shape. They are cases. They run for days or weeks, involve several people and often other organisations, follow rules with deadlines and evidence requirements, and end with a decision someone is accountable for. A debit-order dispute may involve the creditor and the payment system's dispute rules. A fraud report triggers card blocks, investigation and possibly a criminal case. A complaint has internal handling timelines and, if unresolved, a route to an external ombud.
Impala already had systems for all of these: a case-management platform, a fraud operations team, a complaints unit, a collections and hardship team. Each had trained staff, documented procedures and audit trails built over years.
An assistant that tried to own these cases would be rebuilding, in a conversational layer, work that already had a home. Worse, it would be making judgements, about whether a dispute is valid or whether a client qualifies for relief, that carry real consequences and belong to accountable people following documented rules.
The assistant starts; the workflow owns
Impala's answer was a clear division. For case-shaped work, the assistant's job is to start the case well and then step back.
Starting well means three things. Recognise early that the conversation is case-shaped. Gather the facts the case will need, using the read tools: which debit order, which transaction, when, how much. And open the case in the bank's existing system, with those facts attached, so the person who picks it up does not have to ask the client again. The client receives a case reference and an honest description of what happens next and how long it usually takes.
From that moment, the workflow and its people own the outcome. The assistant may tell the client the case status if asked, using a read tool on the case system. It does not make decisions in the case, communicate decisions, or negotiate.
Two kinds of conversation skip the assistant's part almost entirely. Financial hardship and bereavement go straight to trained people, with the assistant doing no more than recognising the situation and connecting the client quickly and kindly. These conversations need judgement, empathy and discretion that Impala decided should come from a person, every time.
Why not a team of agents?
The multi-agent proposal deserved a serious answer, because multi-agent designs are fashionable and sometimes right. Impala's architects asked what problem splitting the assistant would solve.
The honest answer was: not much that a workflow did not already solve better. A "disputes agent" would need the same identity, tools, boundaries and controls as the main assistant, plus the dispute rules. Those rules already lived in the case system, maintained by the disputes team. A separate agent would duplicate them, in prompts, where they are harder to version, test and audit.
Splitting would also add failure relationships. With one assistant and a case system, there is one handoff to get right. With a supervisor and four specialist agents, there are handoffs between every pair, each a place where context can be lost, instructions misread or responsibility left unclear. Each additional agent multiplies the paths a conversation can take and the number of ways it can fail between them. Our From Chatbot to Agent series describes the loop inside one agent; this is the cost of connecting many.
Multiple agents make sense when work genuinely has separate responsibilities, different permissions or different owners, and when a deterministic workflow cannot express the coordination. For Impala's case-shaped work, a deterministic workflow already did, and it came with accountable owners.
Designing the handover into a case
The quality of the handover decides whether this design feels seamless or bureaucratic to the client. Impala specified each case type's handover as a small contract, much like the tool contracts in Chapter 5.
For a debit-order dispute, illustratively: the debit order identified by creditor, amount and date from the read tool; the client's stated reason chosen from the dispute categories the case system recognises, plus free text; confirmation that the client has seen how disputes work, including the time limits that apply; and the conversation transcript, masked. The case is opened only when all required fields are present. If the client cannot identify the debit order, the conversation goes to a person instead of opening an incomplete case.
For a suspected fraud report, the order is different. Stopping harm comes first: the assistant offers to freeze the card immediately, a Chapter 6 action, then connects the client to the fraud team as a priority handoff rather than opening a queued case. Fraud is the one case type where speed of human contact matters more than completeness of the case file.
What the workflow teams asked for
The case-owning teams were initially wary. They had seen channels that dumped poorly described cases into their queues and increased their workload. Their requirements shaped the design.
The disputes team wanted every assistant-opened case flagged as such, so they could compare quality with cases opened by agents. The fraud team wanted to be able to change, without a software release, which phrases trigger an immediate fraud handoff. The complaints unit wanted any conversation in which a client expressed dissatisfaction with the bank to be offered the formal complaint route, rather than the assistant trying to resolve the complaint itself.
Those requests turned the case teams from sceptics into owners of their part of the assistant's behaviour. That is the operating-model point of this chapter: the boundary between assistant and workflow is also a boundary between teams, and both sides need a say in where it sits.
The boundary will move, deliberately
None of this means the assistant can never do more with cases. Over time, Impala expects some case steps to become routine enough to automate: confirming that a disputed debit order has been reversed, or telling a client which documents a hardship application needs. When that happens, the change will follow the same path as every other capability in this case study. The case team proposes it, the step is specified as a contract, the policy and evaluation work from Chapter 9 and Chapter 10 is done, and the risk committee approves it with evidence.
What will not happen is the boundary drifting because the assistant turned out to be good at conversation. Fluency is not authority. The case teams own their decisions, and any step that moves into the assistant moves with their agreement, not around it.
Key points
Questions end; cases continue. Disputes, fraud, hardship and complaints have deadlines, rules, evidence and accountable decisions.
The assistant starts the case; the workflow owns it. Gather facts with read tools, open the case with them, then step back.
Some conversations go straight to people. Hardship and bereavement get a trained person, quickly, every time.
More agents mean more failure relationships. Split only for genuinely separate responsibilities that a workflow cannot express.
Let case teams own their boundary. Their requirements on flags, triggers and routes made the design work.
Next: Chapter 8, Hosted or self-hosted: choosing a model path from South Africa. All chapters are on the series page.
How CloudNala can help
We help organisations decide where an assistant should stop: which work is conversation and which is a case, how handovers into existing workflows are specified, and when multiple agents genuinely earn their complexity. We bring the teams who own disputes, fraud and complaints into the design, so the boundary works for them as well as for the client.
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 AI Production Readiness Review or write to us at consult@cloudnala.co.za