Agent Loop Explained: How an AI Agent Decides What to Do Next

An AI agent loop is the repeating cycle in which a model reads its current context, chooses an action such as calling a tool, observes what came back, and then decides whether to continue or stop. No fixed script sets the order of steps, so the agent picks each next move from what it has just seen. A company controls that behavior less by trusting the model to choose well and more by setting limits around the loop: which tools exist, what they can touch, how many turns are allowed and when a person must approve.

Key takeaways

• The loop has repeating parts: read context, choose an action, observe the result, and decide whether to stop.
• The model proposes each action, but the surrounding software decides what is actually permitted and executed.
• Most loop failures come from poor context, vague tools or missing stop rules, not from a lack of model intelligence.
• Useful limits include a tool allowlist, narrow permissions, a turn budget, approval gates for risky actions and a written definition of done.
• Every turn should leave a record, so a person can later see why the agent did what it did.

What is an AI agent loop, in plain terms?

Think of a capable new colleague who is given a task and a toolbox. They look at what they know, pick a tool, use it, check the outcome and decide what to do next. They repeat this until the task is finished or they get stuck and ask for help. An agent loop is the same pattern, run by software around a language model.

The model alone does not do anything in the world. It produces text, and some of that text says, in effect, that it wants to call a particular tool with particular inputs. The surrounding software reads that request, checks it, runs the tool if it is allowed, and feeds the result back. That surrounding layer is usually called a harness, and What is an AI harness? A practical business guide explains it in business terms.

This is also what separates an agent from a fixed automation. In a deterministic workflow, a designer chose the sequence ahead of time. In an agent loop, the sequence is chosen as the work unfolds. Anthropic's engineering guidance on building effective agents draws the same line between predefined workflows and agents that direct their own process, and it advises choosing the simpler option whenever it is enough.

What happens in each turn of the loop?

Every pass through the loop has the same parts, even when the task is different.

• Read context: the model receives the task, the instructions, earlier messages, any memory it was given and the results of earlier turns. This is everything it knows at that moment.
• Choose: it decides between answering, calling a tool, asking a question or stopping.
• Act: the harness validates the requested call, applies permissions, and either runs it or refuses it.
• Observe: the tool output returns to the context. It might be data, a confirmation or an error.
• Continue or stop: the model and the harness rules around it decide whether the task is done, blocked or needs another turn.

Notice that the context grows with each turn. Observations are added, and the next decision depends on them. That is the strength of the loop, because the agent can correct course after an error. It is also the weakness: a misleading observation or an outdated note can steer every later turn.

Anthropic's writing on context engineering treats context as a limited resource that must be curated, not simply accumulated. That matches what operators see in practice. An agent that reads a clean, current, relevant context tends to choose well. An agent that reads a crowded or stale one tends to wander.

How does an agent choose which tool to use?

The model chooses from the tools it has been shown. Each tool is presented with a name, a description and a list of inputs. The model compares the task and the current context with those descriptions and picks the closest match. This means tool descriptions work as instructions. A vague description such as handles orders invites wrong calls. A precise one that says what the tool does, what it needs and what it returns reduces them.

Several design habits follow from this:

• Prefer a few clear tools over a long menu of overlapping ones.
• Keep read-only tools and write tools separate, so their permissions can differ.
• Write error messages that say what to fix, not only that something failed.
• Keep outputs concise, because everything a tool returns is added to the context.

These points echo Anthropic's guidance on writing tools for agents. Designing inputs and outputs well is a discipline of its own, covered in AI tool contracts: design inputs and outputs that work.

The model can also choose not to use any tool. Asking a clarifying question or handing the work to a person are valid moves. A good setup makes them easy and normal, not a sign of failure.

Why do agent loops go wrong?

Most failures fall into a few recognizable patterns.

• Repeating: the agent calls the same tool with the same inputs because the result did not change its mind.
• Drifting: after many turns, the original goal is buried under accumulated detail.
• Premature stopping: the agent declares success without evidence.
• Overreach: the agent uses a permitted tool in a way nobody intended.
• Following planted instructions: text inside an email, web page or document tells the agent to do something, and the agent treats it as an instruction instead of as data.

The last pattern deserves particular attention. Anything the agent reads during the observe step is untrusted input. OWASP's prompt injection prevention guidance recommends treating external content as data, limiting what tools can do, and requiring human approval for high-risk actions. Those controls live in the harness, not in a sentence added to the prompt.

None of the five patterns is fixed by a cleverer paragraph of instructions alone. They are reduced by structure around the loop: clear tools, narrow permissions, visible limits and a defined way to stop.

Where can a company set limits on the loop?

Limits sit at specific points in the cycle. Use this checklist when reviewing any agent role.

• Tools: list exactly which tools the agent can call, and remove everything else.
• Permissions: give each tool the narrowest access that does the job, under the agent's own account and not a person's.
• Turn and time budget: set a maximum number of turns and a maximum duration, after which the agent stops and reports what it found.
• Repeat detection: stop or escalate when the same call with the same inputs recurs.
• Approval gates: require a named person to approve anything that sends, pays, deletes or changes records outside the company.
• Stop conditions: write down what done looks like and what evidence proves it. A definition of done for AI agents: demand evidence shows how.
• Logging: record each turn's chosen tool, inputs, output and outcome. AI agent observability: what should you actually log? goes through the details.
• Escalation path: define who receives the work when the agent stops and what the agent must pass along.

Most of these are decisions for the business, not technical details. Which actions need approval is an operating question that the owner of the process should answer. The engineering job is to make each rule enforceable by the harness instead of merely advisory in the instructions.

What does a loop look like in practice? An illustrative scenario

Illustrative scenario: a distributor wants an agent to answer internal questions about late supplier shipments. The task is to find the order, check the supplier's latest status and draft a note for the account owner.

• First turn: the agent reads the request and its instructions, then chooses the order lookup tool. The result shows the order and the supplier.
• Second turn: it chooses a read-only supplier status tool. The result shows that the status was last updated several days ago.
• Third turn: instead of assuming the shipment is still on schedule, the agent notes that the status is stale. It writes a draft that says so and saves it, without sending anything.
• Stop: the definition of done required a draft with the order reference, the latest status, the date of that status and a flag if the status is old. The agent has all four, so it hands the draft to the account owner for approval.

Several limits were at work. Every tool except the draft saver was read-only, sending required a person, and the stop rule demanded evidence of a date. Had the supplier tool returned errors repeatedly, the turn budget would have ended the loop with a short report instead of endless retries. The account owner would then have seen exactly where the agent stopped and why.

How does Be Human's managed approach handle the loop?

Be Human treats the loop as part of a defined role, not as a property of the model. A first engagement sets one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. The tool allowlist, permissions, turn limits and stop conditions are configured in the harness under human control, so they do not depend on the agent following instructions. In managed operations, the team monitors the logs, runs recurring evaluations, reviews permissions and makes controlled improvements when a loop shows repeated or drifting behavior.

Frequently asked questions

How many turns should an agent be allowed to take? There is no universal number. Observe how many turns a normal successful run needs, add reasonable headroom, and make the agent stop with a report when it exceeds that. Review the limit as real runs show whether it is too tight or too loose.

Is an agent loop the same as a chatbot conversation? No. A chatbot turn usually ends with a reply to a person, who then decides what happens next. An agent turn often ends with a tool call and an observation, and the loop continues without a person until a stop condition or an approval gate is reached.

Can the agent change its own limits? It should not. Tool lists, permissions, turn budgets and approval rules belong to the harness, and people should change them through a reviewed process. An agent that can edit its own boundaries is not operating within boundaries at all.

Do I need an agent loop at all? Not always. If the steps are known and stable, a fixed workflow is simpler to test and cheaper to run. A loop earns its place when the next step genuinely depends on what the work reveals along the way.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.