Up to now, Impala Bank's assistant has received account context the way a contact-centre agent receives a screen: the bank's code decided what to show for a given question type and handed it over. That works for a small, predictable set of questions. It does not work for the long tail: "did my salary come in?", "how much did I spend at Woolworths last month?", "is my travel notification still active?", "which of my debit orders went up this year?"
Each of those could be hard-coded as another question type, but there are hundreds of them. The alternative is to give the assistant tools: named operations it may choose to call, with defined inputs and outputs, that let it look things up as the conversation requires. Chapter 5 introduces tools, and keeps them read-only on purpose.
Where we are in the case study
Impala Bank is fictional, and its systems and figures are illustrative. After Chapter 4, Ask Impala answers public questions from an index that holds no personal information, and reaches account data only through session-checked account services inside a private data boundary. Logs, retention and evaluation data follow that boundary too.
What a tool is, in plain terms
A tool is a function the bank has written and the model is allowed to call. The model sees a name, a description and a list of inputs, such as "get_recent_transactions: returns the signed-in client's transactions for a date range". When a question needs that information, the model asks for the tool to be called with particular inputs. The bank's code, not the model, then runs it, checks the inputs, applies identity and returns the result. The model reads the result and phrases the answer.
That division of labour is the whole safety story. The model decides which approved operation would help and with what parameters. Everything that makes the operation safe, identity, permission, validation, limits and logging, sits in deterministic code the bank already knows how to test. Our article Tools: how AI agents actually do work explains the general mechanism; here we focus on the contract a bank should demand from every tool.
The tool contract
Impala wrote a one-page contract for each tool before any code. The contract for recent transactions looked like this, illustratively.
Three rows carry most of the weight.
Who it is for. The client comes from the session, never from an input. There is no client_id parameter for the model to fill in, so there is nothing to persuade it to fill in wrongly. This is the Chapter 3 principle, applied to every tool.
Inputs the model sets. Only a date range and an account type, both validated: the date range cannot exceed twelve months, the account type must be one the client holds. Anything else in the request is rejected rather than ignored, and the rejection is logged, because an assistant asking for unexpected parameters is a signal worth seeing.
What never comes back. Full card and account numbers are masked by the tool itself, before the model sees anything. If a later prompt or bug causes the model to repeat what it received, there is nothing sensitive to repeat.
Read-only is a property of the system, not a promise
"Read-only" is easy to claim and easy to break. A tool described as read-only that calls an internal API with write permissions is one bug or one changed endpoint away from not being read-only.
Impala made read-only structural. The read tools ran under a service identity that held read permissions only on the account systems, granted by the platform team and reviewed like any other privileged access. Even if a tool's code were changed to attempt a write, the account systems would refuse. The assistant's tool layer had no route to the payment systems at all.
This is the same pattern as Chapter 4's boundary: make the unsafe thing impossible rather than merely forbidden. It also connects to the authority ladder in our AI for Cloud Operations series, where observing comes before recommending, and recommending before acting.
Limits that keep a loop from running away
Tools introduce a new failure mode: the assistant calling them repeatedly. A model trying to answer "how much have I spent on groceries this year?" might call the transactions tool month by month, then again with different categories, then again because a merchant name was ambiguous. Each call costs time, money and load on the account systems.
Impala set limits at three levels. Per tool: at most 20 rows per call and five calls per conversation for the transactions tool. Per conversation: at most twelve tool calls of any kind before the assistant must either answer with what it has or hand off. Per client per day: a ceiling that, if reached, routes the client to a person and alerts the platform team, because it usually means something is wrong.
Our article on the AI agent loop describes why every loop needs a stop condition. In a bank, the stop condition is also a protection for the core systems the tools touch.
Choosing which tools to build
Impala built six read tools in Chapter 5: recent transactions, debit orders, card status and settings, travel notifications, scheduled payments and statement availability. It did not build a "search everything" tool, or a tool that ran arbitrary queries, however convenient that would have been for the long tail.
A small set of specific tools is easier to describe accurately, easier to test and easier to explain to a risk committee. It also makes the model's choices more reliable: a model choosing between six clearly described tools picks the right one far more often than one choosing between forty overlapping ones. When the long tail produced a question no tool covered, the assistant said so and handed off, and the handoff reasons told the team which tool to consider next.
Testing tools, not just answers
Tool testing came in two layers. The tools themselves were tested like any bank service: inputs validated, identity applied, masking correct, limits enforced, failures handled. These are deterministic tests with deterministic expectations.
Then the assistant's use of tools was evaluated: for a set of a few hundred realistic questions, did it choose the right tool, with sensible parameters, and stop when it had enough? Wrong tool choices were reviewed in the weekly quality session and usually fixed by improving a tool's description rather than the model's instructions.
Every tool call was traced: which tool, which parameters, how long it took, what came back (masked) and what the assistant did next. Our Agent Evidence Layer series covers why a trace on its own is not proof the work was good, and Chapter 10 shows how Impala turned traces into evidence.
What changed for clients
With read tools, the long tail opened up. "Did my salary come in?" became answerable in a sentence. So did "which debit orders went up?", one of the most common month-end questions. The illustrative share of signed-in conversations that ended in a handoff fell noticeably, and the handoffs that remained were more often genuine problems rather than lookups.
Nothing in this chapter let the assistant change anything. That is about to change, and Chapter 6 explains why the first actions are small, reversible and confirmed by the client.
Key points
A tool is the bank's code, called by the model. The model chooses which approved operation to use; deterministic code makes it safe.
Write the contract before the code. Identity from the session, minimal validated inputs, masked outputs, limits and evidence.
Make read-only structural. Read-only service identities and no route to payment systems, not just a description.
Limit calls at three levels. Per tool, per conversation and per client per day, with a handoff when limits are reached.
Prefer a few specific tools. Six well-described tools beat one that can query anything, for safety and for accuracy.
Next: Chapter 6, Bounded actions: what the assistant may do, and what it never will. All chapters are on the series page.
How CloudNala can help
We help teams design the tool layer behind an assistant: which operations to expose, the contract for each, read-only enforced through identity and permissions, call limits that protect core systems, and tests for both the tools and the assistant's use of them. We work with the systems you already run rather than around them.
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