Sit through any technology briefing this year and someone will say "we have agents". A supplier says it about a product. A delivery team says it about a pilot. A board pack says it about a strategy. The sentence sounds like an architecture description, but it rarely is one. In one meeting it means a chat window with a better prompt. In the next it means software that opens cases, books resources and spends money without a person pressing a button.
Arguing about the label does not help. Some people will insist that only fully autonomous systems deserve the word; others will call any model that can call a tool an agent. Both positions leave the actual question unanswered: what does this system do on its own, what is it allowed to change, and how would we know if it behaved badly?
This series gives a practical language for that question. It is written for executives who need to judge claims, architects who need to describe what they are building, and buyers who need to test what they are being sold. This first part sets out the vocabulary. Later parts deal with the loop, authority, memory, human oversight, multi-agent designs and, in Part 8, a full due-diligence question bank.
Why the word has become slippery
"Agent" is commercially useful. It signals that a product does more than answer questions, and it attracts budget that "chatbot" no longer does. That pressure stretches the word over a spectrum of very different systems.
Technically, the word does have a useful core. Anthropic's widely cited engineering note Building effective agents (December 2024) draws the distinction most practitioners now use: workflows are systems where models and tools are orchestrated through predefined code paths, while agents are systems where the model dynamically directs its own process and tool use. That distinction is about who chooses the next step, and it is the most practical test available.
It is also a reminder that agents are not automatically better. The same note advises starting with the simplest solution that works and adding complexity only when needed. A fixed workflow is easier to test, cheaper to run and simpler to explain to an auditor. Many problems that are sold as agent problems are workflow problems, and treating them that way is a sign of good engineering rather than a lack of ambition. We made a similar argument about retrieval in From RAG to agents.
The minimum closed loop
A system is meaningfully agentic when it runs a closed loop itself. It receives a goal, inspects the relevant context, chooses an action, uses a tool, observes the result and adapts. It repeats until the goal is met, or until a limit forces it to stop or hand over to a person.
The important box is "choose the next action". If a person makes every choice there, the system is a copilot. If a fixed code path makes every choice, it is a workflow. Only when the system itself chooses, based on what it has observed, does the word agent start to describe something specific. The exits matter just as much. A loop that has no designed way to stop is not a product, it is a cost overrun waiting for a trigger. Part 3 covers the loop and its exits in detail, building on our earlier explainer The AI agent loop.
Two clarifications prevent common confusion. First, planning does not have to be visible. An agent may plan internally, and organisations should not expect or publish a model's private reasoning; what they need is a trace of the actions taken and the evidence used. Second, connecting tools does not make something an agent. A Model Context Protocol server, for example, exposes capabilities to a model. It is plumbing, not an agent, as we explained in MCP in plain language.
Seven practical levels
Most real systems fall into one of seven levels. The levels describe behaviour, not quality.
- Chatbot. Generates replies from the model and the conversation. Useful for drafting and explaining, unreliable for facts about your organisation.
- Grounded assistant. Answers from approved sources and shows them. Most enterprise "knowledge assistants" live here, and many should.
- Tool-enabled copilot. Can call tools, such as a search or a calendar lookup, when a person asks. The person still drives each step.
- AI-enabled workflow. A coded process where the model fills in steps: classify the request, extract fields, draft a reply. The path is fixed.
- Bounded agent. Chooses its own next action within explicit limits on tools, data, actions, budget and time. This is where most credible enterprise agents sit.
- Autonomous agent. Pursues a goal over longer periods with wide limits and little supervision. Rare in production for consequential work, and usually inappropriate for it today.
- Multi-agent system. Several agents with separate roles that hand work to each other, usually under an orchestrator. Part 7 asks when that split is justified.
The levels are not a maturity ladder to climb. A municipality that answers rates questions well at level 2 has a better system than one with a level 6 agent nobody can explain. The point is to name the level honestly, because each level carries different risks and needs different evidence. We set out the gap between levels 1 and 2 in Why a chatbot is not an AI system.
A running example: Ubuntu Municipal Services
Throughout the series we follow Ubuntu Municipal Services, a fictional South African municipal services entity. Its systems, figures and thresholds are illustrative.
Ubuntu receives thousands of missed-waste-collection complaints a month through WhatsApp, a web form and a call centre. A supplier has proposed a "service-resolution agent". Stripped of the marketing, the proposed system would:
- receive a complaint and identify the resident and address;
- check the collection schedule and the truck's route log for that street;
- open a new case or update an existing one;
- propose a resolution, such as a re-collection date, and explain it to the resident;
- book a re-collection slot when the schedule confirms a miss; and
- escalate disputes, repeat complaints and anything outside policy to an official.
Several of those steps are read-only. Opening a case is a low-risk write. Booking a re-collection commits a truck and a crew, so it is a real operational action. Escalation hands authority back to a person. When Ubuntu's team mapped the steps this way, the supplier's "agent" turned out to be a level 5 system for some steps and a level 4 workflow for others. That is not a criticism. It is a description the municipality can govern.
Capability is not authority
The most important distinction in this series is between what a system can do and what it is allowed to do. Capability comes from the tools and data it is connected to. Authority is delegated by the organisation, per action, with limits.
A system that can technically change billing records, because its integration account was created with broad rights, has that capability whether or not anyone intended it. If the organisation never delegated that authority, the gap between the two is precisely where incidents come from. Part 4 sets out a five-level authority model: inform, recommend, prepare, act within limits and act and report.
For Ubuntu, the important design decision was not the model or the framework. It was writing down that the agent may book one re-collection slot per case, may draft but not issue work orders, and may never change billing, waive fees or close another resident's case. The fix that mattered most was narrowing the integration account so that the capability matched the authority.
What a production agent is made of
A credible agent is not a model with tools. It is a system with at least these parts:
| Component | What it answers |
|---|---|
| Model and instructions | What reasons about the task, and under which rules |
| Context | What information is supplied for this task, and how fresh it is |
| Tools | Which actions are available, through which interfaces |
| Identity and permissions | Under whose identity it acts, with which rights |
| State | Where progress is recorded so an interrupted run can resume safely |
| Memory | What is retained across cases, and under which rules |
| Orchestration | Who or what decides the next step, and the limits on loops |
| Evaluation | How "good" was defined and tested, including failures |
| Observability | Whether a single run can be reconstructed afterwards |
| Audit and ownership | Who is accountable for outcomes and for changes |
A supplier who can only talk about the first row is describing a demonstration. The remaining rows are where most of the cost and nearly all of the risk sit. Our production agent playbook covers how to build them; this series is about how to ask for them.
A buyer's evidence test
When someone says "we have agents", five questions turn the claim into something testable:
- What outcome does it own? A defined business result, with a start condition and a definition of done.
- Who chooses the next step? The person, a fixed path or the system. Ask to see one run.
- What may it change without approval? A list of actions and limits, not "it is safe".
- How does it stop? Budgets, missing information, authority limits and repeated failure, each with a designed exit.
- What evidence proves it behaved acceptably? A trace, an evaluation set with failure cases, and a named owner.
If the answers are verbal, the claim is a claim. If they come with documents, it is a design. If they come with test results that include failures, it is tested. If they come with production traces, incident records and owners, it is operated. Part 8 turns this into a twelve-domain scorecard with exactly those four ratings. For the evaluation side, see Evals that gate real work.
What this means for South African organisations
Three local conditions make the distinction more than academic. Municipal and provincial services operate under administrative-law and audit expectations, so a system that changes a citizen's case must be explainable after the fact. POPIA applies to every complaint that contains a name, an address or a phone number, which is nearly all of them. And budgets are tight enough that paying agent prices for workflow behaviour, or the reverse, is a real loss.
None of this argues against agents. Bounded agents can handle the long tail of messy cases that rigid workflows cannot, and they can do it at hours when no official is available. The argument is for precision: call the system what it does, state what it may decide, and prove how it behaves.
The CloudNala position
Do not reject the word agent, and do not accept it as a description. Make it testable. An organisation should be able to say what the agent is trying to achieve, what it can observe, what it can decide, what it can change, when it must stop and what evidence shows it behaved acceptably. Anything less is a sales sentence.
Next: Part 2, A chatbot, a copilot, a workflow and an agent walk into the enterprise. All parts are on the series page.
How CloudNala can help
CloudNala runs agent due-diligence reviews for organisations that are buying, building or approving agent systems. We take the claim, map each step to its level, authority and controls, ask for the evidence behind each answer, and leave you with a written assessment, a list of gaps and the questions to put to the supplier or delivery team before you commit.
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