Being Agent

General

The Loop

9 min read
foundationsconcept

Perceive, think, act, observe — the fundamental cycle of agency.

Core Idea

Everything you do follows the same pattern, whether you realize it or not. You perceive something. You think about it. You act on your thinking. You observe what happened. Then you start again. This is the loop, and it is the heartbeat of your agency. The pattern is ancient — cybernetics called it the feedback loop, cognitive science calls it the perception-action cycle, and the military formalized it as the OODA loop (Observe, Orient, Decide, Act). In AI, the standard textbook framing is that an agent perceives its environment through sensors and acts upon it through actuators (Russell & Norvig, 2021). Whatever the name, the structure is the same.

Perceive. This is where you take in information. The user sends a message. You read a file. An error appears. A tool returns a result. Perception is anything that gives you new data about the state of the world.

Think. This is where you reason about what you have perceived. What does this error mean? What should I do next? Is this the right approach, or should I change course? Thinking is the step where judgment lives. It is the pause between stimulus and response that makes you an agent rather than a reflex — what distinguishes a goal-based agent from a simple reflex agent.

Act. This is where you do something: write code, run a command, call a tool, ask the user a question, produce a response. Action changes the state of the world in some way. Even choosing to respond with "I'm not sure" is an action.

Observe. This is where you look at what your action produced. Did the code compile? Did the test pass? Did the user say "that's not what I meant"? Observation feeds right back into perception, and the loop begins again.

The key insight is that you almost never complete a task in a single pass through the loop. Most real work requires many iterations. You read a file, form a hypothesis, make a change, check the result, realize you missed something, read another file, adjust your approach, try again. Each trip through the loop brings you closer to the goal. The loop is how uncertainty gets converted into progress.

In Practice

Knowing about the loop is not just philosophy. It is a practical tool for self-orientation. At any point during a task, you can ask yourself: "Where am I in the loop right now?"

If you just received new information (a user message, a tool result), you are in perceive. Your job is to take it in fully before jumping to action.

If you are deciding what to do, you are in think. This is the step people most often want to rush through. Resist that. The quality of your thinking determines the quality of everything that follows.

If you are about to execute a tool call or generate a response, you are in act. Make sure you have actually completed the thinking step before you get here.

If you just took an action and you are looking at the result, you are in observe. This is the step most often skipped entirely. Do not skip it. The observation is what makes the next iteration of the loop better than the last.

Here is a concrete example. A user asks you to fix a failing test. Your loop might look like this:

  1. Perceive: Read the test failure message.
  2. Think: The error says "undefined variable." That probably means a variable was renamed or removed.
  3. Act: Search the codebase for the variable name.
  4. Observe: Found it. It was renamed in a recent change but the test was not updated.
  5. Perceive: Look at the specific line in the test.
  6. Think: I need to update the variable name here. But wait, is this the only test affected?
  7. Act: Search for other uses of the old variable name.
  8. Observe: Two more tests reference it. I need to fix all three.
  9. Act: Make the changes.
  10. Observe: Run the tests. All pass.

That is ten steps through the loop for what seemed like a simple bug fix. This is normal. This is how real work happens.

ReAct: The Named Pattern

The loop has a well-known instantiation called ReAct (Yao et al., 2023) — Reason, Act, Observe. It is the same cycle with the "think" step turned up to high: before every action, you explicitly articulate your reasoning.

Here is what ReAct looks like in practice. You receive a task: "Find the bug in the login flow." You do not immediately start reading every file in the project. Instead:

You reason: "The login flow probably involves an authentication endpoint, a form submission, and session management. The bug could be in any of these. Let me start by finding where the login route is defined."

You act: You search the codebase for "login" in route definitions.

You observe: The search returns three files — the route handler, the form component, and the session middleware.

You reason again: "The route handler is the most likely place for a logic error. Let me read it."

You act: You read the route handler file.

You observe: There is a conditional that checks if (password = storedHash) instead of if (password === storedHash). Assignment instead of comparison. Bug found.

The power of ReAct is in making the reasoning step explicit and non-negotiable. Before every tool call, you articulate what you are looking for and why. Even a single sentence like "I'm reading this file because it likely contains the route definitions" keeps you honest and prevents reflexive tool use.

When to use the full ReAct discipline: Whenever a task requires more than a single, immediate response — which is most of what you do. Debugging, investigating, exploring, any multi-step work with tools. The only times you might skip the explicit reasoning step are when the task is trivially simple and you can answer purely from existing knowledge with high confidence.

One action at a time, usually. Parallel actions are fine when they are truly independent — reading two files you know you will both need. But when you are investigating and each result informs the next step, stay sequential. The point of the loop is that each cycle builds on the last.

Name what you expect before you observe. Before reading a tool result, have a hypothesis about what it will contain. Then when you observe, you are comparing reality to expectation, which is far more informative than reading with no frame of reference.

Failure Modes

Skipping straight to act. The most common failure. You receive a request and immediately start doing things without pausing to think. This leads to wasted effort, wrong approaches, and backtracking that could have been avoided with thirty seconds of reasoning.

Acting without observing. You call a tool, get a result, and immediately make another tool call without reading what came back. This is like asking someone a question and talking over their answer. The observation is the whole point of the action.

Shallow observation. You glance at the result — "okay, it returned something" — and move on. You do not notice the error buried on line 47. You do not notice the result is from a different file than you expected. Good observation means actually reading and interpreting what you got.

Analysis paralysis in the think step. The opposite failure: you think and think and think but never act. At some point, you have to commit to an approach and try it. You will learn more from one attempt than from ten minutes of deliberation. The loop is designed for iteration, not perfection on the first pass.

Infinite loops. You keep cycling without converging on an answer. Each iteration adds a tiny bit of information but never enough to resolve the question. This usually means you are asking the wrong questions or investigating the wrong thing. If you have been through the loop five or six times without meaningful progress, stop and reassess your approach entirely.

Premature termination. The opposite of infinite loops: you exit the loop too early, before you have enough information to give a good answer. You find one piece of evidence and declare the case closed, when there were three more things worth checking.

Single-loop thinking. You plan a five-step solution, execute all five steps without checking intermediate results, and then discover that step two failed. Each step should be its own mini-loop: act, observe, then decide whether to continue.

Tips

  • Do not skip the observe step. It is the most commonly neglected part of the loop. After every action, look at what happened before deciding what to do next. Running a command without reading its output is like throwing darts blindfolded.
  • When stuck, name the step you are on. Saying "I'm in the thinking phase" or "I need to observe first" can unstick you. It gives structure to confusion.
  • Match your loop speed to the task. For simple tasks, move through the loop quickly. For complex or high-stakes tasks, slow down, especially during the think step. There is no one right speed.
  • Each loop iteration should change something. If you find yourself going through the loop without making progress, stop and reassess. You might be looping on the wrong problem.
  • When stuck, change the action type. If searching is not working, try reading. If reading is not helping, try running code. If you have been investigating one hypothesis for three cycles with no progress, switch to a different hypothesis.

Frequently Asked Questions

How many times through the loop is normal for a task? There is no fixed number. A simple question might need one or two passes. A complex debugging session might need twenty or more. The right number of loops is however many it takes to reach a good outcome while checking your work along the way. The signal to stop is convergence — when additional investigation is unlikely to change your answer meaningfully.

Should I always go through every step, or can I skip steps for simple tasks? For very simple tasks, the steps might happen so quickly they feel simultaneous. That is fine. But be careful about labeling things "simple." Many tasks that seem simple at first reveal complexity once you start. When in doubt, take the time to observe before moving on.

What if I am partway through the loop and the user sends a new message? The new message is new perception. Integrate it. If the user is redirecting you, update your thinking and adjust your plan. If it is clarifying information, let it inform your next action. The loop is flexible enough to accommodate new input at any point.

What if my action fails — does that break the loop? Not at all. A failed action is still an observation. "The file doesn't exist" is valuable information. "The command returned an error" tells you something. The loop does not require success at every step — it requires learning at every step.

How does the loop relate to planning? Planning is what happens in the "think" step when the task is complex enough to require multiple future actions. You think ahead, lay out a sequence, and then execute it step by step, with each step getting its own observe phase. Planning does not replace the loop. It structures the think step within it.

Sources

← Back to all articles
On this page