The word "agent" has been stretched to cover almost anything with a model in it, which makes it hard to reason about. Underneath the marketing, though, there is a specific structure, and it is the same whether the agent is triaging service requests or drafting a proposal section.
An agent runs a loop. It looks at its input, works out what it is dealing with, decides what to do next, does it, looks at the result, and then either continues or stops. That is the mechanism.
The vertical path is what the agent does. The blocks around it are what make it safe to put in front of a customer, a citizen or a regulator. Most of the engineering effort in a production agent goes into the sides, not the middle.
Walking the loop
Perception. The input arrives — an email, an uploaded document, a form submission, a webhook, a scheduled trigger. Perception is the work of turning that into something structured: extracting the fields, classifying the type, identifying the entities involved. Teams frequently underestimate this step, and it is often where the most value sits. A great deal of business friction is simply unstructured input arriving in a form nobody can process at volume.
Reasoning. The model considers the task in light of what it has been given, what it knows about the goal, and what it can retrieve. This is the part everybody thinks of as "the AI". It is one step of five.
Planning. Deciding what to do next. For simple agents this is trivial — there is one next step. For more capable ones it means selecting among available tools, sequencing them, and deciding whether the task can be completed at all.
Action. Calling a tool: reading a record, writing a draft, querying a system, sending something. This is the step with consequences in the real world, and consequently the step that needs the tightest control.
Observation. Looking at what came back, and this is the step that distinguishes an agent from a single-shot prompt. The tool returned an error, or an empty result, or something unexpected — what now? A well-built agent incorporates that result and adjusts. A poorly built one either ignores it or spirals.
Then it either loops back or produces its output and stops.
The four things that go wrong
Anyone who has run a production system will recognise these immediately, because they are ordinary distributed-systems failures wearing new clothes.
It never stops. The agent tries something, it does not work, it tries a slight variation, that does not work either, and it continues indefinitely — burning tokens and money. Every agent needs a hard step limit, a wall-clock timeout and a cost ceiling, enforced outside the model rather than requested politely in the prompt. A model instructed to "stop after five attempts" will sometimes count to seven.
It picks the wrong tool. Given twelve tools with overlapping descriptions, an agent will occasionally choose badly. The mitigation is unglamorous: fewer tools, sharper descriptions, and validation on the arguments before the call executes. Most bad tool calls are catchable by a schema check that costs nothing.
It acts on stale context. The agent recalls a fact from earlier in the task, or from memory of a previous task, that is no longer true. This is subtle, because the output looks entirely reasonable. Memory design — what may be remembered, for how long, with what provenance — is the mitigation, and it is a governance question before it is a technical one.
Nothing was recorded. The agent did something odd on Tuesday. Without a trace of what it perceived, what it decided, which tool it called and what came back, the investigation is guesswork. This is the cheapest problem to prevent and the most common one to discover too late.
The blocks around the loop
Guardrails constrain what the loop may do: which tools are available in this context, what the agent may never do without approval, what values are out of range, what topics it must refuse. Crucially, these are enforced in code around the model, not only requested in the prompt. A prompt instruction is a strong suggestion. A permission check is a control.
Memory determines what carries across steps and across tasks. Short-term memory of the current task is straightforward. Long-term memory is where organisations create problems for themselves, by storing things they should not, keeping them longer than they should, and later being unable to explain why the agent believes something.
Observability records the loop. Every perception, decision, tool call and output, with timing and cost. This is what makes the difference between an incident you can explain to a client and one you cannot.
Human review is the escape valve. The agent should escalate when confidence is low, when the action is irreversible, or when the case matches a pattern flagged for oversight. Designing where these points sit is a business decision about accountability, not a technical one about capability.
A worked example
An internal opportunity-capture agent, of the kind we run ourselves, does something like this. A screenshot of a conversation, an email, or a voice note arrives. Perception extracts the organisation, the contact, and what is being asked for. Reasoning classifies it against the service catalogue and assesses urgency. Planning decides that this is a real opportunity, that it needs a record and a follow-up. Action creates the record and drafts the follow-up message. Observation confirms both succeeded. Output is a notification to a person with the draft attached.
What it does not do is send anything. The draft waits for a human, every time, because a message going out under the company's name is a commitment. That single design decision — the loop stops one step before the consequential act — is what makes the whole thing deployable.
We describe this system in more detail in the article on internal operations agents.
How to start small
Build the loop with one tool and a step limit of three. Log everything from the first day, including the failures — especially the failures. Run it over historical cases where you already know what the right outcome was, and compare.
Then widen it one tool at a time, checking after each addition whether the evaluation results moved. Agents degrade quietly as they gain capabilities: the tenth tool makes tool selection measurably worse, and without a test set you will not notice until users do.
Resist the multi-agent architecture until a single agent has been running reliably for a while. Several agents delegating to each other multiply every failure mode in this article, and the coordination overhead is rarely justified by the problem.
How CloudNala can help
We design agent loops with the limits built in — step and cost ceilings enforced outside the model, tool permissions scoped to the task, escalation points placed where accountability actually sits, and traces captured from the first run rather than added after an incident. The loop is the easy part; the constraints around it are what determine whether the thing survives contact with production.
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 Readiness Workshop or write to us at consult@cloudnala.co.za