The agent loop in plain English: how it chooses, and how it stops

Every agent diagram has a circle in it. Goal, plan, act, observe, repeat. The circle is accurate and almost useless for decision-makers, because it hides the two questions that determine cost and risk: how does the system decide what to do next, and what makes it stop?

We have already explained the basic loop in The AI agent loop: perceive, reason, plan, act, observe. This part does not repeat it. It looks at the loop the way an executive, an auditor or a buyer needs to see it: as a series of choices made at run time, each of which costs money, can fail, and must be able to end.

We continue with Ubuntu Municipal Services, the fictional municipal entity from Part 1, and its service-resolution agent for missed-waste-collection complaints.

Fixed path or chosen path

The first question is whether the path is written in advance or chosen while the system runs.

Both designs handle the same missed-collection complaint at Ubuntu. In the workflow, the order is written in code and the model fills in text. In the bounded agent, the model chooses which allowed tool to use next based on what it has observed. The dynamic path handles odd cases better and is harder to test, so it needs tighter limits and better traces.

In a fixed workflow, the order of steps is code. The model fills in text or makes a classification at known points, but it does not decide what happens next. You can test every path because there are only a few.

In a bounded agent, the model chooses which allowed tool to use next, based on what it has seen so far. For a simple complaint it might check the schedule, open a case and reply. For a messy one it might check the schedule, find the address does not match, look up the property record, find an earlier case, and decide to escalate. The path is different every time.

That flexibility is the reason to use an agent, and the reason it costs more to assure. You cannot test every path, so you test representative scenarios, watch real runs through traces, and rely on limits to contain the paths you did not anticipate.

What one turn of the loop actually involves

In plain terms, each turn is:

Look at the situation. The goal, the case so far and the results of earlier actions.
Choose one action from the tools it is allowed to use, or decide it is finished, or decide it cannot continue.
Take the action through a tool: a lookup, a write, a message.
Read what came back, including errors, empty results and contradictions.
Record progress, so the run can resume if it is interrupted.

Each turn usually calls the model at least once and a tool at least once. Turns are therefore the unit of cost, latency and risk. A run that takes three turns for a simple complaint and thirty for an awkward one has a very different cost profile from a workflow that always takes four steps. Our work on AI cost observability applies directly here.

Adaptation is the point, and the hazard

Adapting means the agent changes its next action based on what it observed. When the schedule lookup times out, it might retry, try a different source or tell the resident it will follow up. When the route log shows the truck did visit, it might ask the resident for a photo rather than booking a re-collection.

Adaptation is also where things go wrong in ways a workflow cannot. An agent can retry the same failing action repeatedly. It can treat an empty result as "no problem found". It can pursue a side issue that is not part of its goal. It can take an action twice after a timeout, which matters a great deal if the action was booking a truck. We covered the second failure in When the tool fails but the answer looks complete.

The controls are not exotic: limits on turns, time and cost; actions designed so that repeating them does no harm; and explicit rules about what counts as "done".

The five exits every loop needs

A loop is defined as much by how it ends as by how it runs.

Every iteration of Ubuntu's service-resolution agent must be able to leave the loop through one of these exits. Each exit is designed in advance, produces a record, and hands the case to a known next owner. A loop that can only end by succeeding will eventually end by wasting money or doing something nobody approved.

Goal met and checked. Not "the model says it is done", but a check against a definition of done. For Ubuntu: the case exists, the resident has been told the outcome, and any booking is confirmed by the scheduling system.
Budget used. A maximum number of turns, a time limit and a cost ceiling per run. Anthropic's Building effective agents note mentions stopping conditions such as a maximum number of iterations as a common way to keep control. When the budget runs out, the agent reports what it achieved and hands over.
Missing information. The agent asks the person for what it needs, then waits without holding resources or repeating itself. Waiting is a state, not an error, as we argued in An agent without durable state cannot own a long-running process.
Beyond authority. The next sensible action is one it is not allowed to take. It escalates to an official with the case file. This exit is the one most often missing from demos.
Repeated failure. The same error twice stops the run and flags it, rather than trying a third time with growing confidence.

Every exit should produce a record and hand the case to a known next owner. If an exit leaves the case in limbo, it is not an exit, it is a leak.

What to ask when someone shows you a loop

Show me a run where the path differed from the happy path. Why did the agent choose each step?
What are the turn, time and cost limits, and what happens when each is reached?
Which actions are safe to repeat, and how are the others protected against repetition?
How does the agent decide it is finished, and who checks that decision?
Show me a run that ended in escalation. What did the official receive?

A team that can answer these with traces and test results has designed its loop. A team that can only redraw the circle has not.

Key points

The governance question is not whether there is a loop, but who chooses the next step and how the loop ends.
Dynamic paths handle messy cases better and are harder to test, so they need limits and traces.
Each turn is a unit of cost and risk; awkward cases can cost many times more than simple ones.
Design five exits in advance: done, budget, missing information, authority and repeated failure.

Next: Part 4, Agent capability is not agent authority. All parts are on the series page.

How CloudNala can help

CloudNala reviews agent designs at the level of the loop: how actions are chosen, which tools are available, what limits apply and how every run ends. We test the exits with real scenarios, including the awkward ones, and leave you with a loop specification that engineering, risk and operations can all sign.

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