The Four Steps of the Agent Loop: Perceive, Decide, Act, Observe

An agent loop has four steps: perceive, decide, act, observe. The model reads its context, picks the next action, the action runs, the result comes back, and the loop runs again. Everything else about agents (tools, memory, planning, bounding) is built around this four-step cycle.

This post is the conceptual companion to Build an AI Agent From Scratch in Python, which implements the loop in working code. If you have read What is agentic AI?, this post is the next step.

The four steps of the agent loop

Each step is one job. Read them in order; the order matters.

Perceive: read the context

The agent reads its context. Context here means the full input the model will see on this turn: the user’s goal, the system prompt, the list of tools available, any memory the agent has access to, and the history of every previous action and observation in this session. Nothing else is “perceived.” If it is not in the context, the agent does not know about it.

Decide: pick the next action

The model takes the perceived context and produces the next action. The action is either a tool call (with structured arguments) or a final answer. The decision is made in one inference pass. This is the only step in the loop where the language model does the heavy lifting.

Act: run the tool

Your code runs the action. If the model emitted a tool call, an executor looks the tool up in the registry, validates the arguments, runs the function, and captures the result. The model does not run the tool itself; it only emits the request to run it. This is a deliberate design.

Observe: append the result

The result of the action is appended to the context. The next perceive will see it. If the act phase produced an error (a malformed argument, a timeout, a tool that returned a string the model did not expect), the observation includes the error, and the next decide step gets to react to it.

Then the loop goes back to perceive, with the appended observation as new context. The cycle continues until the model emits a final answer or a stop condition fires.

The diagram

Four boxes, four arrows, one cycle. That is the entire model.

Why some courses call it reason and not decide

If you learned this loop somewhere else, the second step probably had a different name. Perceive, reason, act, observe is the most common variant. Sense, plan, act is the older robotics version. John Boyd’s OODA loop, written in the 1970s for fighter pilots, runs observe, orient, decide, act, which is the same cycle with the observation moved to the front.

People go looking for the official source of the four-step version. There is not one. No standards body owns this vocabulary and no single paper introduced it. The shape comes out of control systems and robotics, where it is decades old, and every course, vendor certification and framework has renamed the steps to suit its own material.

So use whichever names your team already uses. Reason and decide are the same step: the one inference pass where the model looks at everything it has and picks the next action. I say decide because what comes out of that step is a decision, not an essay. If the exam in front of you says reason, answer reason.

What actually changed recently is not the loop. It is that a language model can now play that second step on open-ended tasks, and that the act step can be a tool call against software rather than a motor command.

A worked example

User goal: “the printer in conference room B is jammed.”

Turn 1.

• Perceive: context contains the system prompt, the tool registry (lookup_room, search_kb, create_ticket), and the user’s message.
• Decide: the model emits search_kb(query="printer jam").
• Act: the executor runs the function, returns the troubleshooting article.
• Observe: the result is appended to context.

Turn 2.

• Perceive: context now includes the troubleshooting article.
• Decide: the model sees that the article requires the printer’s model number, and emits lookup_room(room="Conference B").
• Act: the executor returns {printer: "HP LaserJet 4250"}.
• Observe: appended.

Turn 3.

• Perceive: context now contains both the article and the printer model.
• Decide: the model has enough information and emits a final answer with the resolution steps tailored to the HP LaserJet.
• The loop stops because the decision was “final answer,” not “tool call.”

Three turns, three perceives, three decides, two acts (the final turn does not call a tool), two observes. The agent solved the task by composing two pieces of information that no single tool returned on its own.

What goes wrong without the loop

A plain chatbot does perceive and decide. It reads the user’s message and produces a reply. It cannot act. It cannot observe. It stops after one decide. That is why a chatbot cannot triage a printer jam: it can describe what to do, but it cannot look up the printer model, cannot fetch the right troubleshooting article, cannot create a ticket. The loop is what gives the system the ability to take a step and then make the next decision with new information.

This is the chatbot ceiling. You can prompt-engineer a chatbot to look like an agent for one or two specific tasks, but the moment the task requires the model to read something it did not have at turn one, the chatbot is stuck. The agent loop is what gets past that ceiling.

What goes wrong inside the loop

The loop is forgiving in shape and unforgiving in execution. The common failure modes:

Looping. The agent calls the same tool with the same arguments over and over. Usually because the tool returned something the model did not interpret, so it tries again, hoping for a different answer. Fix: a step limit and repeat-call detection that breaks the cycle and tells the model to try a different approach.

Context bloat. Every observation appends to the context. On a long session, the context fills up, the model loses sight of the earlier turns, and earlier system-prompt instructions silently drop. Fix: summarize old turns into a compressed memory, or use a tool to “remember” facts to an external store instead of letting them sit in the context.

Tool misuse. The model emits a call with wrong argument types or hallucinated parameters. Fix: strict argument schemas, validation at the executor, and a retry pattern where the validation error is sent back to the model as the observation so it can correct itself.

Stale results. A tool returns cached data the model does not know is stale, and the agent reasons against the wrong picture. Fix: explicit freshness in tool responses (a timestamp, a version) so the model can decide whether to trust the answer.

Cost runaway. A confused agent burns through tokens trying to recover. Fix: a hard cost limit that stops the loop and escalates to a human.

Every one of these is a failure of one specific phase of the loop, not of the whole concept. Diagnosing agent bugs is almost always answering “which phase broke.”

Which is harder than it sounds once the agent is running for real users, because a log line tells you the tool was called and not what the agent was trying to do. AI agent observability is about closing that gap: the signals you need to answer “which phase broke” from a trace instead of a guess.

Where the loop ends

A loop that never ends is not an agent; it is a meltdown. The loop ends in one of three ways.

The model emits a final answer instead of a tool call. The decide phase produces a synthesis, the cycle stops, the answer goes to the user.

A stop condition fires. Step limit reached, cost limit reached, repeat detected, time budget exhausted, irreversible action requires human approval. The system returns control to a human or to a fallback path.

An error is unrecoverable. A tool the agent depends on is down and the agent has no alternative. The system fails gracefully, logs the trace, and tells the user what could not be done.

The pattern in all three: the loop has an explicit exit. It is not the model’s job to know when to stop on its own. The surrounding software bounds the loop. Without bounding, you do not have an agent, you have a token-spending process.

Why this is the only mental model you need

Every agent framework, every agent pattern, every paper on agentic AI, is a refinement of these four steps. ReAct is the loop with reasoning interleaved into each decide step. Plan-and-Execute is the loop with one big decide up front and a sequence of acts and observes. Multi-agent systems are multiple loops talking to each other through tools. Memory is a tool the loop reads from and writes to.

If you can hold the four steps in your head and reason about each, you can read any agentic-AI paper, evaluate any framework, and design any agent. The vocabulary changes; the loop does not.

Where to take this next

Build an AI Agent From Scratch in Python implements this loop in about 150 lines, in plain Python with the OpenAI SDK. Same four steps, real code.

Understanding Agentic AI Systems walks the loop one chapter at a time, building a single project (an internal IT helpdesk assistant) from a chatbot into a real agent. Same four steps, longer treatment, more worked examples.

For how this loop scales into production architecture (cost, latency, evaluation, security), the interview questions post is the densest single resource, and Designing Enterprise Agentic AI Systems is the long form.

If you are taking a loop you have already built to real users rather than studying for an interview, the AI agent production readiness checklist is the next step: twelve checks, each naming the person who answers it and the artifact that proves the answer.

For where the loop fits inside the broader 2026 shift in software engineering, the agentic coding mental model post sets the picture.