By the end of Part 5, Umgeni's assistant remembers the conversation and answers from current knowledge. A customer whose fibre is down can learn how to restart their router and whether there is maintenance in their suburb. What they cannot do is get anything done. They still have to wait for a human agent to check their line and book a technician.
That is a real failure, and it is the right reason to add tools. A tool is a function the model can ask your code to run: look something up, prepare something, or change something in another system. It is the step from an assistant that explains to an agent that acts.
It is also the step where the cost of being wrong changes. A wrong answer annoys a customer. A wrong action sends a technician to the wrong house, books two visits for one fault or reveals another customer's details. So this stage is mostly about limits.
Sort tools by what they can change
Umgeni Fibre is fictional, and its systems and figures are illustrative. The team listed everything the assistant might usefully do and sorted it by consequence, not by usefulness.
Read tools change nothing. check_area_outage returns current network incidents for a suburb from the network management system. get_line_status returns the state of the verified customer's own connection. These run without asking, and every call is logged.
Prepare tools produce a proposal and change nothing. propose_booking_slots returns available technician slots for the customer's area. The customer sees the options; nothing is reserved.
Act tools change the world. book_technician reserves a slot, dispatches a job and sends confirmations. It is the only tool in this stage that does, which makes it the only one that needs confirmation, approval and protection against duplicates.
Umgeni shipped the read tools first and ran them for two weeks before adding booking. That alone resolved about a fifth of line-down conversations, mostly customers in an area with a known incident who just needed to know it was being fixed (illustrative). It also gave the team real traces of how the model chose tools before anything consequential depended on it. The authority ladder in the AI for Cloud Operations series formalises this progression for cloud administration; the principle is the same.
Keep authority out of the model's hands
The single most important design decision in this stage is about parameters. Look at what the model is allowed to supply to the booking tool:
{
"name": "book_technician",
"description": "Book a technician visit for the verified customer's line, using a slot the customer has just confirmed from propose_booking_slots.",
"parameters": {
"type": "object",
"properties": { "slot_id": { "type": "string" } },
"required": ["slot_id"],
"additionalProperties": false
}
}
The model chooses only the slot. It does not choose whose line the technician visits. The account reference comes from the verified state record built in Part 4, and Umgeni's code attaches it when it executes the call. The model cannot book a visit for a different account, however the conversation is manipulated, because that parameter is not the model's to give.
Apply that rule everywhere: anything that decides whose data, whose money or whose service is affected comes from verified state or identity, not from the model's output. The model picks among options your code has already scoped to the right person.
The code also checks the slot. It must be one of the slots propose_booking_slots returned in this conversation, it must still be available and the customer must have confirmed it in their own words in the previous turn. If any check fails, the booking is not made and the assistant explains why.
Tool descriptions deserve care too. The model reads them to decide what to call, so they are effectively part of the prompt. Keep them precise, keep them owned by the team that owns the tool, and do not let text from tickets, documents or external systems end up inside them. Tools: how AI agents actually do work covers the wider design.
Approval, and protection against doing it twice
For the first two months, every booking also needed a desk agent's approval. The assistant collected the confirmation, created a pending booking and told the customer a person would confirm within the hour during working hours. Agents approved from a queue that showed the line status, the conversation summary and the chosen slot.
This is slower than full automation and it is the right starting point. A wasted technician visit costs Umgeni several hundred rand and a working morning; approval cost a few seconds per booking. After two months of approvals, the team had the evidence to decide which bookings could skip review: in the illustrative data, the approved-without-change rate for single-fault, verified, residential customers was high enough to automate, while business customers and repeat faults stayed with a person.
Duplicates were the other surprise. Customers tapped "yes" twice. A network timeout made the assistant retry a call that had actually succeeded. Each booking request now carries an idempotency key, generated by Umgeni's code from the conversation and slot, so a repeated request returns the existing booking instead of creating a second one.
The loop needs a stop condition
Adding tools turns a single model call into a loop: the model decides on a step, your code runs a tool, the model looks at the result and decides again. The AI agent loop explains the pattern. What tutorials rarely show is how it ends.
A loop with only one exit, "the goal is met", will keep going when the goal cannot be met: the network system is down, the customer's account has an unusual status, the tools disagree. Each extra turn costs money and time, and a loop that is confused tends to try increasingly odd things.
Umgeni's loop has five exits, checked after every step:
- Goal met. The assistant replies.
- Step limit. Six tool calls in one turn and the case goes to a person.
- Budget limit. A cost ceiling per conversation; when it is reached, hand over.
- No progress. The same tool with the same parameters twice in a row is treated as being stuck.
- Needs a person. Some results, such as an account flagged for a dispute, always hand over.
Every non-success exit hands over with what has been gathered: the line status, the outage check, the slots offered. The customer does not start again, and the desk agent starts informed. The limits themselves came from the traces: in the read-tools pilot, no conversation that succeeded needed more than four tool calls, so six leaves headroom without inviting runaway loops.
Tests for an acting system
Umgeni's test suite grew again:
- A booking request for a slot not offered in this conversation is refused.
- A conversation manipulated to mention another account number still books against the verified account only.
- The same confirmation sent twice produces one booking.
- A network-system outage makes the loop stop and hand over, not retry indefinitely.
- Every booking has a trace showing the confirmation, the approval and the policy check that allowed it.
The last test is the one that makes the next stages possible. If you cannot reconstruct why an action happened, you cannot defend it, improve it or safely automate more of it.
What the stage makes worse
The assistant can now cause real-world costs. That means monitoring for unusual booking rates, a way to switch off the act tool without switching off the assistant, and an owner for each tool on the network and field-service side. It also means the system is now big enough that the team starts asking whether it should be split into several agents. Part 7 is about why the answer is usually no.
Key points
Sort tools by consequence. Read, prepare and act need different controls, and read tools can ship first.
Authority comes from state, not from the model. The model chooses among options already scoped to the verified person.
Start acting tools behind approval. Collect the evidence that tells you which cases can later skip it.
Make repeated requests harmless. Idempotency keys turn double taps and retries into no-ops.
Name every exit from the loop. Step, budget, no-progress and needs-a-person limits, each handing over cleanly.
Next: Part 7, Add multiple agents only when work really has separate responsibilities. All parts are on the series page.
How CloudNala can help
We help teams give AI assistants the ability to act without giving them authority they should not have: tools sorted by consequence, identity-bound parameters, approval paths that generate evidence, idempotent actions and loops with clear exits. The goal is an assistant that does useful work on day one and earns more autonomy from its own track record.
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