Most AI agents you'll evaluate as a PM run the same basic loop: think about what to do, take an action, observe the result, repeat until done. ReAct, Reflexion, and plan-execute are different tunings of that loop — where the reasoning happens, how much memory carries forward, and when the agent stops. Understanding the loop tells you where cost, latency, and infinite-spin bugs actually live.
Quick Answer: The reason-act loop (reason → act → observe → repeat) is the engine inside almost every agent. ReAct interleaves thought and action every step; Reflexion adds a self-critique pass after failures; plan-execute front-loads planning and only loops on execution. All three fail the same way — they spin — without an explicit stopping condition.
What is the reason-act loop, exactly?
The reason-act loop is a repeating cycle — reason, act, observe — that lets a language model use tools, take multi-step actions, and adjust based on results instead of producing one static answer. It's the mechanism that turns a chat model into something people call an "agent." Every framework you'll hear about — ReAct, Reflexion, plan-and-execute — is a variation on this same three-part cycle.
Here's the sequence in plain terms:
- Reason — the model generates a short piece of internal reasoning about what to do next, given the goal and everything observed so far.
- Act — the model calls a tool, a function, a search query, or an API endpoint based on that reasoning.
- Observe — the result of that action (search results, an API response, an error) gets appended to the model's context.
- Repeat — the loop runs again with the new information, until the model decides it has enough to answer, or some external limit stops it.
The core paper behind this pattern is Yao et al.'s 2022 ReAct: Synergizing Reasoning and Acting in Language Models (Princeton/Google Research), which showed that interleaving explicit reasoning traces with actions outperformed either reasoning-only or acting-only prompting on multi-step tasks. That paper is the reason "ReAct" became shorthand for the whole pattern, even though plenty of agents today don't use its exact prompt structure.
Why PMs need to understand this, not just the demo
This is the layer where things actually go wrong in production, and it's invisible in a polished demo. A demo shows you the happy path — three loop iterations, clean tool calls, a correct answer. It doesn't show you the tenth run where the agent calls the same search tool four times because the observation didn't change its reasoning, burning tokens and latency with nothing to show for it.
If you're building product intuition around agents more broadly, our complete guide to AI agents covers the surrounding vocabulary — this piece goes one layer deeper, into the loop itself.
ReAct: reasoning and acting in the same breath
ReAct interleaves a short "thought" with every action, so the model explains its intent before each tool call and reads the result before generating the next thought. This is the default pattern most agent frameworks (LangChain's agent executors, early AutoGPT-style loops) implement, because it's simple to prompt for and reasonably interpretable.
A single ReAct step looks like this in the transcript:
Thought: I need the customer's current plan tier before I can answer the billing question.
Action: lookup_account(customer_id=4471)
Observation: { "tier": "Pro", "renewal_date": "2026-08-15" }
Thought: I have the tier. Now I need the pricing difference for an upgrade.
Action: get_pricing(tier="Enterprise")
Observation: { "monthly": 899, "annual_discount": 0.15 }
Thought: I have enough information to answer.
Final Answer: ...
Each Thought is generated by the model as free text; each Action is a structured call the surrounding code executes; each Observation is appended verbatim to the context window before the next Thought is generated. Notice that the transcript grows every iteration — that's the direct link to both cost and latency, since every prior thought, action, and observation gets re-sent to the model on the next call.
Where ReAct tends to break
- Repetition loops — if an observation doesn't meaningfully change, the model can generate a near-identical thought and repeat the same action.
- Context bloat — long transcripts push earlier observations out of the effective attention window, so the model "forgets" something it saw three steps ago.
- Premature stopping — the model decides it has "enough" before it actually does, especially under prompt pressure to be concise.
Reflexion: adding a self-critique pass
Reflexion extends ReAct with a verbal self-critique step after a failed or unsatisfactory attempt, storing that critique as a kind of episodic memory the agent consults on the next attempt at the same or a similar task. It doesn't change weights — it changes what's in context next time.
The pattern, from Shinn et al.'s 2023 Reflexion: Language Agents with Verbal Reinforcement Learning (Northeastern University / MIT), adds a fourth phase to the loop:
- Run the reason-act loop as usual until it terminates (success or failure).
- An evaluator (often the same model, sometimes a separate rule or scorer) judges the outcome.
- On failure, the agent generates a reflection — a short natural-language note on what went wrong.
- That reflection is prepended to the next attempt's context, and the loop runs again.
The practical PM-relevant distinction: Reflexion is designed for tasks that get retried, like coding benchmarks or puzzle-solving, where the same task recurs and prior failure is useful signal. It's less applicable to one-shot production requests where there's no "next attempt" at the exact same task — the value is in accumulated critique, not a single pass.
Plan-execute: separating the "what" from the "how"
Plan-execute splits the loop into two phases — a planning phase that decomposes the goal into steps up front, and an execution phase that loops through those steps one at a time, only re-planning if execution reveals the plan won't work. This trades ReAct's step-by-step flexibility for more predictable cost and easier debugging.
| Dimension | ReAct | Plan-execute |
|---|---|---|
| When reasoning happens | Every step, interleaved with action | Mostly up front, in one planning pass |
| Cost predictability | Lower — step count is emergent | Higher — plan defines the step count |
| Adaptability mid-task | High — reasons fresh each step | Lower — needs explicit re-plan trigger |
| Debuggability | Harder — reasoning scattered across steps | Easier — plan is a single artifact to review |
| Best fit | Exploratory, tool-heavy tasks | Well-scoped, multi-step tasks with known shape |
Frameworks like Plan-and-Solve prompting and LangChain's plan-and-execute agent executor formalize this split. The intuition PMs should carry: plan-execute is a governance choice as much as a technical one — it gives you a reviewable artifact (the plan) before any tool call happens, which matters a lot if the actions are irreversible or costly.
Walking through one loop iteration end to end
A single iteration has four moving parts, and each one is a place a PM should be asking "what does this actually cost, and what could go wrong here."
- Context assembly — the model receives the goal, tool definitions, and the full transcript so far. This grows every iteration, which is the main driver of per-call cost in a long-running agent.
- Reasoning generation — the model produces a thought (and, in ReAct, an action choice). This is a real inference call with real latency, typically the slowest single step in the loop.
- Tool execution — the chosen action runs against a real system: a database query, an API call, a search. This is where side effects happen, and where a hallucinated or malformed call does damage outside the model entirely.
- Observation append — the result gets folded back into context for the next reasoning pass. Malformed, oversized, or noisy observations here directly degrade the next reasoning step.
Every one of those four steps costs tokens, time, or both. A ten-iteration loop isn't "the model thinking ten times" in the abstract — it's ten inference calls, up to ten tool invocations, and a transcript that's roughly ten times longer by the end than at the start. That compounding is the thing to model explicitly before you approve an agent's scope, not after it's in production. Our piece on agents versus workflows and where non-determinism creeps in goes deeper on why that per-step unpredictability is structurally different from a deterministic pipeline.
The stopping-condition decisions PMs actually have to make
The loop needs an explicit exit condition, or it will run until something else stops it — a token budget, a timeout, or a human. This is the single most consequential design decision in any agent build, and it's frequently left as a framework default nobody reviewed.
There are four stopping mechanisms in common use, and most production agents need more than one layered together:
- Max iteration count — a hard ceiling on loop turns (e.g., 10 or 15). Simple, cheap, but can cut off a legitimately long task right before completion.
- Confidence/completion signal — the model itself declares "I have enough to answer." Flexible, but unreliable on its own — models can be overconfident or underconfident.
- Cost or token budget — the loop halts once cumulative spend crosses a threshold, regardless of iteration count. Directly protects the metric finance cares about.
- Human checkpoint — the loop pauses for approval before a costly or irreversible action, then resumes. This is the mechanism you want for anything touching money, customer communication, or production data.
The decision isn't "pick one" — it's which combination, at what thresholds, for which class of task. A research-summary agent can tolerate a generous iteration cap and no human checkpoint. An agent that can issue refunds should have a low action-count ceiling and a mandatory checkpoint before the action fires, not just before the final answer. This is exactly the territory covered by an agent autonomy levels framework: the stopping condition and the autonomy level are two sides of the same governance decision, and guardrails on agent actions are what enforce it at the point of execution rather than hoping the model self-regulates.
A quick gut-check for reviewing any agent spec
Ask three questions before approving scope: What happens on iteration 20 if nothing has resolved yet? What's the most expensive single action this loop can take, and is it gated? Does the transcript get summarized or truncated before it silently degrades reasoning quality?
Where Prodinja fits into this
None of the above is something Prodinja's prototype claims to solve automatically — the loop still runs, still costs tokens, still needs bounds you set. What Prodinja's Agentic Workflows tool is designed to do is give you a structured place to frame the goal and the tool set before a reason-act loop starts operating over them, so the loop has a defined boundary rather than an open-ended one. It's a framing surface for the decisions above, not a replacement for making them.
Key Takeaways
- The reason-act loop (reason, act, observe, repeat) is the shared engine behind ReAct, Reflexion, and plan-execute — they differ in when reasoning happens and what carries forward between iterations.
- ReAct interleaves thought and action every step, from Yao et al.'s 2022 paper; it's flexible but its transcript grows every iteration, driving cost and latency.
- Reflexion adds a verbal self-critique after failure, useful for tasks that get retried, less relevant to one-shot production requests.
- Plan-execute trades flexibility for predictability by front-loading reasoning into a reviewable plan before execution begins.
- Every loop iteration has a real cost profile — context assembly, reasoning generation, tool execution, and observation append each add tokens, latency, or both.
- A missing stopping condition is the most common source of agent cost overruns and looping bugs — max iterations, confidence signals, budgets, and human checkpoints should be layered, not chosen singly.
- Framing the goal and tool set before the loop starts is a governance decision PMs can make explicit, rather than leaving it to framework defaults.
Frequently Asked Questions
What is the difference between ReAct and a plan-execute agent?
ReAct reasons and acts one step at a time, generating a fresh thought after every observation, while plan-execute decomposes the goal into a full sequence of steps up front and only re-plans if execution reveals a problem. ReAct suits exploratory tasks; plan-execute suits well-scoped multi-step tasks where a reviewable plan matters.
Why do AI agents get stuck in loops?
Agents loop when an observation doesn't meaningfully change the model's reasoning, causing it to repeat a near-identical thought and action indefinitely. This usually means the stopping condition (iteration cap, confidence check, or budget) wasn't set tightly enough, or the tool's response format isn't informative enough to move reasoning forward.
Is ReAct the same as chain-of-thought prompting?
No — chain-of-thought prompting asks a model to reason step by step toward a single final answer with no tool calls or environment interaction, while ReAct interleaves that reasoning with real actions and observations from the outside world. ReAct is closer to chain-of-thought with a feedback loop attached.
How many loop iterations should an agent be allowed to run?
There's no universal number — it depends on task complexity and cost tolerance, but most production agents cap iterations somewhere in the 5-15 range and pair that cap with a cost or token budget as a second backstop. The right number comes from testing the task's typical completion length, not a framework default.
Does adding more reasoning steps always improve agent accuracy?
No — beyond a certain point, a longer transcript can degrade reasoning quality because earlier observations get diluted or pushed out of effective context, even before a hard context-window limit is hit. More steps also mean more chances for an action to introduce an error the model then reasons from as if it were correct.