Every assistant programme reaches the point where looking things up is not enough. A client asks why their card was declined, learns that it has expired, and asks the obvious next question: can you send me a new one? Sending them to another screen to do it themselves, after the assistant has just explained the problem, feels like a failure of the whole idea.
So the assistant starts to act. This is the chapter where the risk changes character. Until now, the worst outcome of a mistake was a wrong or unhelpful answer. From here, a mistake can change something real: a card cancelled, a document sent, a request submitted in a client's name. The questions are no longer only "is it right?" but "was it allowed, did the client mean it, and can it be undone?"
Where we are in the case study
Impala Bank is fictional, and its systems and figures are illustrative. After Chapter 5, Ask Impala has six read-only tools that run under a read-only service identity, take the client from the session, return masked data and stop after a fixed number of calls. It can tell a client almost anything about their own accounts and change nothing.
Choosing the first actions
Impala's team listed every request clients made in the contact centre and scored each on four questions. Is it already something clients can do for themselves in the app? Is the harm small if it is done wrongly? Can it be undone? Is it attractive to a fraudster?
Three actions came out clearly on top.
Request a bank confirmation letter or stamped statement. Clients need these constantly, for landlords, visa applications, employers and accounts. The document is delivered into the client's secure app inbox, never emailed to an address typed into the chat. The harm of an unwanted request is close to zero.
Temporarily freeze a card. A client who thinks they have lost their card should be able to stop it immediately. Freezing reduces risk rather than adding it, and the client can unfreeze it in the app.
Order a replacement card. More consequential: the current card stops working, and a new one is issued. It is delivered only to the client's registered address or for collection at a branch, both already on record.
Several popular requests were deliberately excluded, and the reasons matter as much as the choices.
The line the assistant does not cross
Some actions were ruled out of Ask Impala's scope permanently, not just for now: making or scheduling payments, adding or changing beneficiaries, raising transaction limits, and changing contact details such as the registered cellphone number or email address.
The logic is simple. These are the actions fraud depends on. A fraudster who has persuaded a client, or compromised a device, wants to add a beneficiary, raise a limit, redirect one-time PINs to a new cellphone number and move money. Each of those already has hardened journeys in the app, with their own verification, cooling-off periods and monitoring built up over years. Recreating them inside a conversational channel would add a new, less tested route to the same outcome, and a conversational route is precisely the one a social engineer is best at exploiting.
The chapter's most important design decision was therefore a negative one. Where an action belongs in a hardened journey, the assistant explains how to do it and opens that journey. It does not perform it. This is the "assistance does not inherit authority" idea from our AI Before the Rulebook series, applied to a bank's own channel.
Prepare, confirm, then submit
For the actions it may perform, Ask Impala never acts on its interpretation of a sentence alone. Every action follows the same three steps.
Prepare. The assistant assembles the request: which card, which letter type, which delivery option. It does this using the read tools, so the details come from the bank's records rather than from the conversation.
Confirm. The app shows a native confirmation screen, not a chat message, with the exact request in plain language: "Order a replacement for your Gold card ending 4417, to be delivered to your registered address in Midrand. Your current card will stop working immediately." The client taps to confirm. For the replacement card, the confirmation also requires step-up authentication, the same biometric prompt the app uses for other sensitive changes.
Submit. Only then does the bank's code submit the request through the same service the app's own screens use, under a service identity that can perform those three actions and nothing else.
Using native confirmation screens rather than asking the client to type "yes" matters for two reasons. A typed "yes" can be ambiguous or misread, and text injected into the conversation cannot press a button in the app's own interface. The confirmation is a step outside the model's reach.
Designing for repeats and failures
Actions bring engineering problems that answers do not. Two caught Impala's team early.
Duplicates. A client on a weak mobile connection taps confirm, sees nothing happen and taps again. Or the assistant retries a request after a timeout. Without protection, the client receives two letters or, worse, two replacement cards with the first one cancelled by the second. Each submitted request carries a unique request reference, and the card service treats a repeated reference as the same request. This property, called idempotency, is dull to describe and essential to have.
Uncertain outcomes. Sometimes the card service accepts a request and only confirms later that the card has been issued. The assistant must not tell the client "your new card is on its way" when the true state is "your request has been received". Ask Impala reports exactly the state the service returns and, for the card, the client gets a notification when the status changes. Our AI for Cloud Operations series explores the same gap between "the call succeeded" and "the change happened" in a different setting.
Undo, where undo exists
The three actions were chosen partly because each has a sensible reverse. A frozen card can be unfrozen. An unwanted letter can be ignored. A replacement card cannot be un-ordered once the old card is cancelled, which is exactly why it requires step-up authentication and a confirmation screen that says so in plain words.
For every action, the client receives a notification through the app's normal channel saying what was done and when, with a route to a person if they did not request it. That notification is a fraud control as much as a courtesy: a client whose device has been compromised learns about the action immediately.
Telling clients what the assistant can do
Clients do not read scope documents, so the assistant has to make its limits clear in the moment. When a client asks for something outside its scope, Ask Impala says so plainly and opens the right journey: "I can't add a beneficiary for you, but I can open the screen where you do it." It never implies that a limit is temporary or that a person could be persuaded to bypass it.
That consistency is itself a fraud control. Impala's clients are told, repeatedly, that the assistant will never move money, add payees or change their contact details. A message that claims otherwise, whether it arrives by SMS, email or a cloned website, is therefore easier for a client to recognise as fake. A boundary that is simple to state is a boundary clients can help enforce.
Evidence for every action
Every action leaves a record linking the conversation, the prepared request, the confirmation screen shown, the authentication result, the submission and the service's response. When a client disputes an action, "the assistant did it" is not an answer the bank can give. The record shows what the client was shown, what they confirmed and what the system did.
That record is the start of the evidence chain Chapter 10 builds on, and it is also what lets the risk committee review the assistant's authority with facts rather than impressions.
Key points
Choose first actions by harm, reversibility and fraud appeal. Letters, card freezes and replacement cards passed; much else did not.
Some actions stay outside the assistant permanently. Payments, payees, limits and contact changes keep their hardened journeys.
Prepare, confirm, then submit. Details come from records, confirmation happens on a native screen, and sensitive actions need step-up.
Engineer for repeats and uncertain outcomes. Request references prevent duplicates, and the assistant reports the true state.
Notify and record every action. The notification is a fraud control, and the record is the evidence when a client disputes it.
Next: Chapter 7, Where one agent stops and workflows begin. All chapters are on the series page.
How CloudNala can help
We help organisations decide which actions an assistant may take and design them safely: a scoring of harm, reversibility and fraud appeal, prepare-confirm-submit flows on native screens, idempotent submissions, notifications and an evidence record per action. Just as important, we help you write down what the assistant will never do, and why.
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