Agent Loop Architectures Compared

What Every Agent Loop Does Before Architecture Choices

Every agent loop, no matter how it's dressed up in a vendor deck, runs the same four-beat cycle: perceive, reason, act, observe. The agent takes in its current state (the goal, the last tool result, whatever context survived the prior turn), reasons about what to do next, acts on that decision, and observes what came back. That observation becomes next turn's perception, and the cycle repeats until the goal is satisfied or something tells it to stop.

That loop is the actual line between an agent and a chatbot, not model size and not prompt cleverness. A chatbot reasons once, answers, and stops. It never finds out if it was right. An agent reasons, acts on the world, sees what happened, and reasons again in light of that. Everyone wants to credit the model for good agent behavior. Wrong place to look: the loop structure is doing the work.

Each of the four stages does distinct work, and most failures trace back to one stage being skipped or shortchanged. Perceive assembles the current state: the goal, the last tool result, prior-turn context, whatever system instructions are still active. Reason is where the model decides on the next action, or decides the goal is already met. Act is execution, a function call, a database query, an API hit, or the final response to the user. Observe feeds the result of that action back in as the next perception.

Termination is where the trouble starts, and it starts early, before anyone's even chosen an architecture. Without an explicit exit condition, a loop has no built-in reason to stop. It keeps reasoning, keeps acting, keeps spending tokens, right past the point where the task is done, or right past the point where it was never going to get done. Every architecture below inherits this problem, and none of them solve it by default. A max-turn cap, a confidence threshold, a human checkpoint: pick one, but pick something. Prompt tuning does not substitute for a stopping condition.

ReAct: the lowest-friction starting point and its honest limits

ReAct runs the tightest possible loop: thought, tool call, observation, next thought. The agent decides what to do only after seeing the result of what it just did. No upfront plan, no fixed sequence. Yao and colleagues introduced it out of Princeton and Google in 2022, and it's held on as one of the two dominant shapes in production agent design, alongside plan-and-execute.

The appeal is adaptability. ReAct fits open-ended tool use well: research agents digging through document sets nobody's indexed, customer support flows where the resolution path depends entirely on what the customer types next. Latency runs moderate and scales with the number of reasoning steps taken. Cost tracks token usage in a straightforward, linear way. On debuggability, ReAct is the clearest of the five architectures here: every thought and every tool call sits in the trace, in order, readable start to finish.

Complex, interdependent tasks expose the limits fast, and this is where most teams overreach with ReAct, treating it as a default rather than a fit for a specific shape of problem. Because it reasons one step at a time with no global view of the task, it drifts into short-term thinking: optimizing the next move without tracking how that move serves the larger goal. Hand it a ten-step task with real dependencies, a data pipeline where step seven depends on a schema decision made in step two, and that narrow view starts eating accuracy quietly, one plausible-looking step at a time. Nobody notices until step nine breaks and the trace shows six steps that all looked reasonable in isolation.

Plan-Execute: when a written contract between planner and executor reduces mid-task drift

Plan-Execute splits the loop into two phases. A planner generates the full task sequence upfront. An executor works through those steps, either one after another or in parallel where steps don't depend on each other. The plan functions as a written contract, and that contract limits how much the executor gets to improvise mid-task.

This is a direct trade against ReAct's flexibility, and for one class of work it's the correct trade: report generation, code review pipelines, multi-step data transformations where the steps don't change based on what happens along the way. Where ReAct adapts step by step, Plan-Execute commits early and reduces drift on tasks whose structure is already known and stable.

The latency profile front-loads. Planning costs more upfront, but each step afterward runs cheap, and parallel execution of independent steps can recoup that planning overhead fast. Cost follows the same shape: efficient when the plan is parallelizable, considerably less so the moment the plan needs revising mid-run.

That revision problem is the architecture's real weakness, and it fails ugly rather than gracefully. A plan written before execution starts is a bet that nothing in the environment changes while it runs. When an API fails, or a result partway through invalidates a step three moves downstream, the executor has no built-in way to replan. Someone has to bolt a replanning loop on top, explicitly, or the executor keeps following a plan that no longer makes sense, burning tokens on steps that were already obsolete two turns back.

Reflexion: self-critique as a quality multiplier with a token budget attached

Reflexion adds a second reasoning pass that ReAct and Plan-Execute don't have. After each attempt, the agent evaluates its own output against a success criterion, then revises its approach before moving forward. This isn't an informal retry loop. The critique layer is structured and runs at every turn, which is what separates Reflexion from an agent that just tries again when something breaks.

The distinguishing feature is the verifier itself, built into the architecture rather than bolted on after the fact. For code generation, mathematical reasoning, and document summarization, getting the answer right matters more than getting it fast, because a wrong summary does more damage than a slow one. Latency runs high because of the multiple generation and evaluation passes, and without caching, Reflexion gets expensive at scale fast.

The verifier is the bottleneck here, not the model. Reflexion just makes that fact structural instead of leaving it implicit in whatever ad-hoc retry logic a team bolts on. Whatever evaluates the output is doing the load-bearing work, and whatever token budget that evaluator needs is the real cost of running Reflexion, not the generation pass everyone focuses on first.

Tree-of-Thoughts: treating reasoning as search at inference time

Tree-of-Thoughts abandons the chain. Instead of one thought leading to the next, the agent generates multiple candidate reasoning branches in parallel, evaluates each, prunes the weak ones, and continues from whichever branch looks most promising. Reasoning becomes a search tree instead of a straight line.

Latency runs very high and scales with branching factor: more branches, more time, no way around that arithmetic. Cost is the highest of the five architectures covered here, and that's a structural property of running multiple reasoning threads at once, not a sign of sloppy implementation somewhere in the stack.

Tree-of-Thoughts earns its keep on problems where a single chain of thought isn't enough: strategic planning, puzzle-solving, multi-constraint optimization where the first coherent-looking path isn't necessarily the right one. It produces better outputs on these problems precisely because it explores the solution space instead of committing early to whatever thought came first, which is exactly the habit that sinks ReAct on similar tasks.

MLflow's categorization scheme organizes agent types into a 7-by-6 matrix based on cognitive function and execution topology, a framework that makes the cost structure of parallel-reasoning architectures like Tree-of-Thoughts explicit: the expense grows with the number of parallel branches run. The agent runs several reasoning threads at once, each carrying its own token bill, so the cost grows directly with the number of branches explored. Nobody should reach for this architecture on a workload with a real-time latency floor. The tree does not care how fast the answer needs to arrive.

Multi-Agent: distributing cognition across specialists and what coordination costs

Multi-agent architectures hand the loop off to a supervisor, which decomposes the task and routes subtasks to specialized worker agents. Each worker runs its own inner loop, whether that's ReAct, Plan-Execute, or another approach. The supervisor aggregates what comes back and handles sequencing across workers.

Latency here is genuinely variable, and nobody can predict coordination overhead in advance. Cost runs high in absolute terms, distributable across specialized models, which is the actual advantage on offer, not a reduction in total spend. Teams that adopt multi-agent expecting it to come in cheaper than a single strong loop are solving the wrong problem and will find that out on the first invoice.

Multi-agent systems can consume up to 15 times more tokens than a standard chat interaction. That's the price of coordination, not a defect in the design: every message that passes between agents triggers its own context assembly and its own reasoning pass, and those add up fast across a workflow with several workers talking past each other.

Where this earns its cost is on long-horizon tasks that outrun a single agent's context window or capability, on workstreams that genuinely run in parallel, and on enterprise workflows where responsibilities are already role-separated in the org chart. HR onboarding stretched across two weeks, invoice disputes stalled for days waiting on another department, sales sequences running a month end to end: these workloads are dominated by idle time, not active reasoning time, and a single-agent loop has no good way to sit idle for two weeks and pick back up cleanly.

Comparing the Five Architectures Across Four Production Dimensions

Lining the five up on latency reveals a rough order. ReAct sits at moderate, tracking step count. Plan-Execute front-loads its cost into planning, then runs cheap per step, with total time depending on how much of the plan parallelizes. Reflexion runs high because of its multiple passes. Tree-of-Thoughts runs very high, scaling with branching factor. Multi-Agent is the wildcard: coordination overhead is the variable nobody can pin down ahead of time.

Cost doesn't rank the same way latency does, because the five shapes aren't comparable on one scale. ReAct's cost is linear with steps and predictable. Plan-Execute is efficient when steps parallelize and breaks down fast when the plan needs revising. Reflexion gets expensive without caching, full stop. Tree-of-Thoughts carries the highest absolute cost of the five, scaling with branching factor. Multi-Agent starts from a baseline token multiplier that can reach 15 times a standard chat interaction, and coordination adds on top of that.

Reliability is where all five share a common enemy: compounding error. At 90% accuracy per step, a ten-step task is around 35% success overall, and that arithmetic doesn't care which architecture is running the loop. Reflexion and Plan-Execute push back on it through verification and upfront planning, respectively. Tree-of-Thoughts reduces the risk of committing to a single bad path. Multi-Agent localizes failures to individual workers instead of letting one bad step sink the whole task. Each solves a different failure mode. None of them solves the same one twice, and picking an architecture for its reliability story only works if the failure mode it addresses is the one the workload actually produces.

Debuggability separates the five sharply, and it's the dimension teams underrate until something breaks in production at 2 a.m. ReAct is the clearest: a sequential thought-action-observation trace reads like a transcript. Plan-Execute produces an auditable plan artifact, and the execution trace can be diffed against it directly. Reflexion's critique passes leave behind interpretable reasoning artifacts of their own. Tree-of-Thoughts is the hardest to trace of the five, because the architecture doesn't log branch pruning by default. Figuring out which branch got pruned and why takes deliberate, explicit logging that most teams skip until the first unexplained bad output forces the issue. Multi-Agent localizes failure well on a per-worker basis, but the communication between agents opens a whole new surface that has to be traced on top of each worker's internal loop.

Matching an Architecture to a Workload Before Writing Infrastructure

Capability, at this point, is close to a wash across the five. The models underneath are adequate for most of what production workloads actually ask of them. What decides outcomes is which trade-offs a given workload can absorb and which ones it can't, and that's a question about the workload, not about which architecture sounds most sophisticated on a slide.

A support workflow with an unpredictable resolution path and a tight latency budget cannot absorb Tree-of-Thoughts' branching cost, no matter how good the reasoning quality gets. A code-review pipeline with well-defined, stable steps doesn't need ReAct's per-step adaptability, and paying for it just adds latency nobody asked for. A two-week onboarding workflow with role-separated responsibilities isn't a good candidate for a single ReAct loop either, regardless of how cleanly that loop traces.

Match the architecture to what the workload can tolerate on latency, what it can tolerate on cost, how much accuracy loss compounding error will actually cost in that domain, and how much visibility into failure the team will need after launch. Get that match right before a line of infrastructure gets written, and the project stands a real chance of surviving past the pilot. Get it wrong, and the architecture never was built for the job it got handed, and no amount of prompt tuning after the fact changes that.