Inside the Agent Loop: Perceive, Reason, Act, Observe
Most agent systems look complex from the outside: tools, prompts, memory, frameworks, retries. Underneath, almost all of them run the same cycle again and again.
That cycle is the agent loop: the model sees the current situation, decides what to do next, does it (often via a tool), then folds the result back into the situation before deciding again.
Agent Loop Basics walks a single turn in code-shaped terms. This page is the mental model underneath that walkthrough: what each phase is, how phases hand off, and why the loop (not a single prompt) is the real unit of agent behavior.
Summary
- An agent loop is a repeating perceive → reason → act → observe cycle that turns goals into multi-step work by feeding each action's result back into the next decision.
- Insight: Almost every production failure (runaways, wasted tokens, wrong tools, "stuck" agents) is a failure of some phase or of the handoff between phases, not of "the model being dumb" in the abstract.
- Key Concepts: perceive, reason, act, observe, turn, trajectory, tool result, stopping condition.
- When to Use This Model: Designing a first agent, debugging a weird multi-step run, choosing between single-shot LLM calls and a looped runtime, or explaining agent behavior to non-agent teammates.
- Limitations/Trade-offs: The four-phase label is a teaching model, not a wire protocol. Frameworks collapse or rename steps (ReAct, plan-and-execute, graph nodes). The loop still costs tokens every iteration and needs explicit stops.
- Related Topics: reasoning traces, stopping conditions, context windows, ReAct vs plan-and-execute, runaway loops.
Foundations
A plain chatbot answers once. An agent keeps going until a stop rule says it is done.
The difference is not "smarter model." The difference is a control loop around the model that can call tools and re-prompt with new evidence.
Think of one iteration as four jobs:
| Phase | Job | Typical inputs | Typical outputs |
|---|---|---|---|
| Perceive | Assemble what the model is allowed to "see" | User goal, prior messages, tool results, system policy | A context package (messages / prompt state) |
| Reason | Decide the next move | Context package + tool schemas | Plan fragment, tool call(s), or final answer |
| Act | Execute side effects or pure lookups | Structured tool call | Tool result, error, or text reply |
| Observe | Record what happened for the next pass | Tool result / environment feedback | Updated trajectory in context |
Nothing magical happens between phases. Each one is software you own (or a framework owns for you).
A useful analogy: a human researcher reading a ticket, thinking, running a query, reading the output, then deciding again. The agent loop is that same rhythm, automated with an LLM as the decision maker.
goal / user message
│
v
┌──────────┐
│ Perceive │ build context for this turn
└────┬─────┘
v
┌──────────┐
│ Reason │ model chooses tool call or final answer
└────┬─────┘
│
final? ──yes──> stop (return answer)
│ no
v
┌──────────┐
│ Act │ run tool / API / shell / retrieval
└────┬─────┘
v
┌──────────┐
│ Observe │ append result to trajectory
└────┬─────┘
│
└──> back to Perceive (next iteration)Mechanics & Interactions
Perceive
Perceive is context assembly, not sensors in the robotics sense.
On turn 1, the package usually includes system instructions, tool definitions, and the user goal. On later turns, it also includes the conversation so far and prior tool results.
What you put in (and what you omit) shapes the next decision. If a critical tool error is truncated out of context, the model may retry blindly. If policy says "never refund without approval" and that line is missing, the model cannot honor it.
Reason
Reason is the model call that chooses the next step.
That choice is usually one of:
- Call one or more tools with structured arguments.
- Ask a clarifying question (if your product allows it).
- Emit a final answer and end the loop.
Some stacks expose intermediate "thinking" or chain-of-thought-style traces before the structured decision. Others only show the final tool call or text. See Reasoning Traces: How Agents "Think" Before Acting.
Reasoning is bounded by the model and by the context you assembled. It is not free-floating intelligence outside that window.
Act
Act is where side effects happen: search, database read, ticket update, code edit, browser click.
The host runtime (not the model) should execute tools. The model proposes a call; your code validates, runs, and returns a result string or structured payload.
Good act-phase design includes:
- Schema validation of tool arguments
- Timeouts and error envelopes
- Permission checks for dangerous tools
- Deterministic formatting of results back into messages
A weak act phase makes the reason phase look worse than it is. Garbage tool errors produce garbage next decisions.
Observe
Observe is writing the environment's feedback into the trajectory.
The model does not magically remember the tool call. Your loop must append something like: "tool X was called with Y; result was Z" (or the framework's equivalent message roles).
That observation becomes part of the next perceive package. This is the feedback arrow that turns a single LLM call into an agent.
One full iteration, concrete story
Goal: "What's the open ticket count for acme-corp?"
- Perceive: system policy + tools
lookup_org,count_open_tickets+ user goal. - Reason: model emits
lookup_org(name="acme-corp"). - Act: host runs lookup →
{ "org_id": "org_9f2" }. - Observe: append tool result to messages.
- Perceive (next): same history, now including org id.
- Reason: model emits
count_open_tickets(org_id="org_9f2"). - Act / Observe: result
14. - Reason: model returns final text "Acme Corp has 14 open tickets."
- Stop: no more tool calls; loop ends (or a stop rule fires).
That is one short multi-turn agent run: two tool steps plus a final answer.
What "a turn" means
Teams overload the word turn.
| Meaning | What it counts |
|---|---|
| User turn | One human message |
| Model turn | One completion from the LLM |
| Agent iteration | One pass through perceive→reason→act→observe |
| Tool turn | One tool execution inside an iteration |
When someone says "max 8 turns," ask which definition they mean. Production budgets usually cap model turns or tool calls, not human messages.
Advanced Considerations & Applications
Parallel tool calls
Some models can request multiple tools in one reason step. Act then fans out, observe concatenates results, and the next reason step sees the batch.
This speeds independent lookups. It complicates error handling when one of three tools fails.
Graph and multi-agent variants
LangGraph-style systems and multi-agent handoffs still implement the same feedback idea. They may split "reason" across nodes or agents, but each specialist still consumes context, acts, and returns observations.
For architecture patterns built on this loop, see the Agent Architectures section, especially ReAct and plan-and-execute pages under ../agent-architectures/.
Cost and latency
Every iteration re-sends growing context (unless you trim or cache). Long loops burn tokens on repeated system prompts and history, not just on the "smart" new reasoning.
Design the loop for the shortest path that still gets evidence. Do not celebrate long trajectories as "more agentic."
| Loop style | Strength | Weakness | Best fit |
|---|---|---|---|
| Single model call, no tools | Cheap, simple | Cannot fetch live facts or act | Pure drafting |
| One tool then answer | Bounded cost | Fails when step order is unknown | Known lookup patterns |
| Full agent loop | Flexible multi-step work | Cost, latency, runaway risk | Ambiguous goals needing evidence |
| Plan then execute loop | Fewer wasted steps on long tasks | Bad plans need replan logic | Multi-stage workflows |
Stopping is part of the loop
Without stops, the diagram's back-edge is infinite. Max turns, goal checks, timeouts, and user cancel are first-class design, not afterthoughts.
See Stopping Conditions: How an Agent Knows When It's Done.
Common Misconceptions
- "The agent is the model." The agent is model + tools + loop + stop rules + host policy. The model is the reasoner inside that system.
- "Perceive means multimodal sensors." In software agents it usually means assembling text (and sometimes images) into the prompt state.
- "If the model is smart enough, the loop will self-correct forever." Without caps and good observations, smart models still thrash, retry, or invent progress.
- "Act and observe are the same step." Act is execution; observe is recording the result in a form the next reason step can use.
- "Frameworks remove the need to understand the loop." Frameworks implement the loop for you. You still design tools, context, and stops.
- "More iterations always mean better answers." Past a point, iterations mostly add cost, drift, and repetition.
FAQs
What is an agent loop in one sentence?
A controlled cycle that lets a model repeatedly see state, decide, use tools, and incorporate results until a stop condition ends the run.
How is an agent loop different from a chatbot reply?
A chatbot typically produces one model response per user message. An agent may perform many model and tool steps for a single user goal before answering.
Who executes tools: the model or the host?
The host runtime executes tools. The model only proposes structured calls; your code must validate and run them.
Do I need all four phases as separate code modules?
No. Many frameworks fold them into one orchestrator. The four labels are for reasoning about failures and design, not mandatory package layout.
Where does memory fit in the loop?
Short-term memory is mostly the trajectory in context (perceive/observe). Long-term memory is extra retrieval injected during perceive before reason.
What should I log for debugging?
Log each model decision, tool name and args, tool result summary, latency, token counts, and the stop reason. That is the trajectory.
Can the reason phase skip tools entirely?
Yes. If the model already has enough context, it should emit a final answer. Forcing tools on every turn wastes cost.
What happens if a tool throws?
Observe should capture a clear error payload, not crash the whole process silently. The next reason step can retry, choose another tool, or stop with a partial answer depending on policy.
Is ReAct the same as this loop?
ReAct is a popular way to interleave reasoning and acting inside this loop shape. The loop is the general control pattern; ReAct is one policy for how reason and act alternate.
Why does context grow every iteration?
Because observe appends new tool results and messages. Without trimming or summarization, the perceive package gets longer and more expensive each turn.
When should I use a loop versus a fixed workflow?
Use a fixed workflow when step order is known and stable. Use a loop when the next action depends on intermediate evidence you cannot hardcode.
How does this map to Python code structure?
A typical shape is while not stopped: context = build(); decision = llm(context); if final: break; result = run_tool(decision); append(result). Frameworks hide the while, not the idea.
What is a trajectory?
The ordered record of messages, tool calls, and tool results for one agent run. It is the primary artifact for debugging and evaluation.
Can multiple agents share one loop?
Multi-agent systems often give each agent its own loop and pass messages between them. Handoff is observe-for-the-other-agent, not a different physics of agency.
Related
- Agent Loop Basics - hands-on single-turn tool call and result handling
- Reasoning Traces: How Agents "Think" Before Acting - what happens inside the reason phase
- Stopping Conditions: How an Agent Knows When It's Done - how the loop ends safely
- How Context Shapes Every Decision an Agent Makes - perceive-phase discipline
- Why Agents Loop Forever: Debugging Runaway Agent Behavior - when the back-edge never stops
- Agent Loop Best Practices - operational habits for bounded loops
- What Actually Makes Software an "Agent"? - autonomy and the perceive-decide-act spectrum
Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana
@solana/web3.js+@solana/spl-token.