When Ubuntu Municipal Services, the fictional entity we follow in this series, asked three suppliers to demonstrate their "agents", it saw three impressive screens. One answered questions about collection days. One drafted case notes when a call-centre operator clicked a button. One read incoming complaints, checked a schedule, opened a case and replied to the resident. All three were described with the same word.
They were not the same kind of system, and the difference matters more than the quality of the demo. Each pattern has a different owner for the next step, a different relationship with the organisation's records, a different typical failure and a different kind of evidence that proves it works.
This part compares four patterns: chatbot, copilot, AI-enabled workflow and bounded agent. They correspond to levels 1 to 5 of the ladder in Part 1, with the grounded assistant folded into the chatbot column for simplicity.
The four patterns side by side
Chatbot. A person asks, the system answers. Nothing in the organisation's systems changes. The typical failure is a wrong answer that someone believes, which is why grounding and source display matter, as we covered in RAG explained simply.
Copilot. A person drives, the system suggests and can call tools on request. Records may change, but only when the person accepts the suggestion. The typical failure is subtle: suggestions get accepted without reading. The evidence that matters is how often people accept, edit or reject what the copilot proposes.
AI-enabled workflow. An event or a schedule starts a coded process, and the model performs defined steps inside it: classify, extract, draft, summarise. The path is fixed. Records change at known points. The typical failure is brittleness when a case does not fit the expected shape. The evidence is step-level logs and an exception queue.
Bounded agent. A goal is assigned and the system chooses which allowed action to take next, observes the result and continues. Records change within set limits. The typical failure is a wrong action taken quickly, possibly several times. The evidence needed is a full run trace and a clear record of what authority applied.
One complaint, four ways
Take a single message to Ubuntu: "Bins not collected in Mthatha Street again, third week running."
- Chatbot: replies with the published collection day and a reference number for logging a complaint. The resident still has to log it.
- Copilot: a call-centre operator reads the message, clicks "summarise and suggest", gets a draft case and a suggested reply, edits both and submits.
- Workflow: the message is classified as a missed collection, the address is extracted, a case is opened against the route, and a templated reply is sent. A third complaint in three weeks does not change the path unless someone coded that rule.
- Bounded agent: the system checks the route log, sees the truck skipped the street twice, notices the earlier complaints on the case, decides this is a repeat failure outside its authority, prepares an escalation with the evidence and tells the resident when to expect a call.
The agent handled the odd case best. It is also the hardest of the four to test, because its path depends on what it observed. That trade-off is the whole decision.
Choosing the pattern, not the label
A sensible rule is to start at the simplest pattern that solves the problem and move right only when the work demands it.
| If the work is mostly | Prefer | Because |
|---|---|---|
| Answering questions from known sources | Grounded assistant | Nothing changes, so the risk is answer quality |
| Helping skilled staff go faster | Copilot | The expert stays in control of every change |
| High volume, predictable shape | AI-enabled workflow | Fixed paths are testable and cheap |
| Messy cases needing several lookups and judgement within rules | Bounded agent | Dynamic paths handle variation that workflows cannot |
Many organisations end up with a mixture: a workflow handles the common case and calls a bounded agent only for the exceptions. Ubuntu's eventual design looked like that. The common "missed once" complaint goes through a workflow. Repeats, disputes and addresses that do not match the schedule go to the agent, which may prepare actions but books only within its limits.
Questions that reveal the real pattern
Labels on a slide do not tell you which pattern you are looking at. These questions do:
- Who starts the work: a person, an event or an assigned goal?
- Show one run. Who chose each step?
- Which records can change, at which step, and under whose identity?
- What happens with a case that does not fit the usual shape?
- What does the system do when a tool returns an error?
If the honest answer to question 2 is "the code", it is a workflow, however it is marketed. That is often good news, because workflows are easier to assure. If the answer is "the model, based on what it found", ask to see the limits, the trace and the failure cases, which later parts of this series cover.
What changes for governance
Each move to the right in the comparison shifts accountability. With a chatbot, the person who acts on an answer owns the outcome. With a copilot, the person who accepts the suggestion does. With a workflow, the designer of the path owns most of the risk. With an agent, the organisation must decide in advance who owns each action the agent may take, because no person is pressing the button at the time.
That is why the pattern should be named in approval documents, risk registers and contracts. A procurement that buys a "workflow" and receives an "agent", or the reverse, has bought a different risk from the one it assessed.
Key points
- The same model can power all four patterns; the pattern is set by who chooses the next step and what can change.
- Each pattern has a characteristic failure and needs different evidence.
- Prefer the simplest pattern that solves the work, and combine patterns where it helps.
- Name the pattern in approvals and contracts, not only the product.
Next: Part 3, The agent loop in plain English. All parts are on the series page. For background on why chat is the smallest part of an AI system, see Why a chatbot is not an AI system.
How CloudNala can help
CloudNala helps teams choose the right pattern before they choose a product. We map the work, separate the predictable cases from the messy ones, and design a combination of assistant, workflow and bounded agent that matches the risk, with the evidence each part needs to pass review.
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 Agent Due-Diligence Review or write to us at consult@cloudnala.co.za