Comparing the Main Approaches to AI Agent Architecture

A loop has more than one way to be wired

“Agent architecture” is usually said as if there were one shape under the word — a model, a prompt, a handful of tools. In practice, teams that ship these systems choose among a small number of named, documented topologies for organizing planning, memory, delegation, and tool use, and the choice is not cosmetic. Four patterns recur across shipped systems and their own primary documentation: a single-agent loop in the style of ReAct, a planner/executor split, a hierarchical multi-agent supervisor, and an event-driven workflow graph. Each is a different answer to the same control problem, and each vendor that documents its own pattern is candid that the choice trades latency, cost, failure containment, and debuggability against one another — none claims to dominate on all four at once.

Strip away the branding and every one of these systems is choosing an action from a history of observations rather than from the true state of the world, because the true state is never directly available to it. That is the founding move of decision theory under partial observability: an agent’s policy must be a function of a belief built from what it has seen, not of the world as it actually is, and the two can silently diverge ^[11]. Write the general shape once, for a single decision-maker at a single step:

where $o_{\le t}$ is the observation history, $h_t$ is whatever state the system has chosen to retain, and $g$ is the task goal. Nothing here is specific to language models; it is the generic shape of a controller. What actually distinguishes the four patterns below is not this equation but what each one does with $h_t$: whether it is one growing transcript, a plan object computed once and then held fixed, a set of disjoint per-worker histories that never touch each other directly, or a position in an explicit graph whose edges may or may not be permitted to fire. The rest of this article works through each shape in turn, using the tradeoffs their own architects have written down, not a synthetic score.

The single-agent loop: reason, act, observe, repeat

The clearest documented version of the single-agent loop is ReAct, which interleaves a reasoning trace with an action at every step rather than reasoning once and acting once. The original paper reports that this interleaving directly addresses a specific failure of pure chain-of-thought: reasoning traces alone hallucinate facts and let early errors propagate unchecked through the rest of a solution, because nothing outside the model’s own text ever corrects it. Grounding each reasoning step in an actual observation from the environment overcomes this, and the authors report absolute success-rate improvements of 34 and 10 percentage points over baselines without that interleaving on interactive decision-making tasks, alongside trajectories that read as more interpretable because the reasoning that led to each action is written down next to it ^[7].

A natural extension keeps the same single transcript but adds a step at the end of an attempt: a verbal self-critique, stored in an episodic buffer and fed back in on the next try. Reflexion reports this lifts HumanEval pass@1 to 91%, against 80% for a single attempt from GPT-4 without the reflective loop ^[8]. The mechanism is honestly priced, though: each reflective round is a further complete pass over the same task, so the technique buys accuracy by spending additional full loop iterations, not by making any one iteration cheaper.

This is also the shape that Anthropic documents as the default agent loop behind the Claude Agent SDK: gather context, take an action, verify the work, and repeat, with each stage’s own tradeoff spelled out rather than papered over. On the gathering step specifically, the documentation states that agentic search — repeated, live tool calls into the file system — is slower than semantic search over a pre-built index but more accurate, more transparent, and easier to keep current, and recommends starting with the slower, more legible option before optimizing it away ^[3]. That is the single-agent loop’s general character in miniature: every efficiency gain is available, but it has to be taken deliberately, because the default is one long, readable, and expensive transcript.

The tradeoffs that follow from the architecture itself, not from any one implementation, are symmetric. A single transcript means a single trace to inspect after the fact, which is the loop’s real advantage for debugging in the narrow sense that there is exactly one document to read. But that same transcript is also the system’s only channel of memory: an early wrong observation or a hallucinated intermediate conclusion stays in context indefinitely and can bias every decision built on top of it, because nothing in the architecture separates one step’s error from the next step’s premises. Latency and cost both scale with the number of loop iterations, since each iteration re-invokes the full policy over an ever-growing context — the loop has no built-in notion of a cheaper way to spend a step.

The planner/executor split: compute the plan once

A second pattern separates the question “what should be done” from the question “do it,” and answers the first only once. ReWOO implements this directly: a Planner produces a complete multi-step plan with placeholder variables for tool outputs in a single pass, a set of Workers execute the plan’s tool calls, and a Solver assembles the final answer, with no further reasoning calls interleaved between them. The reported result is a 5x improvement in token efficiency alongside a 4-percentage-point accuracy gain on HotpotQA, a multi-step reasoning benchmark, compared with an interleaved reasoning-and-acting baseline — and the authors report the decoupled design is specifically more robust when a tool call fails, because recovering does not require re-deriving the entire reasoning trace that produced it, only re-running the affected step ^[9].

Formally, this replaces the single-loop policy with two functions and one artifact:

The plan $P$ is computed against the belief state available at time zero and then held fixed; the executor applies it against a stream of later observations without necessarily invoking the planning policy again. That is precisely the assumption a classical open-loop plan makes, and it is a specific instance of the belief-state fragility decision theory already names: a policy computed once from a belief state is only as good as that belief state stays accurate, and nothing in the equation above notices when the two have quietly come apart ^[11].

The tradeoffs are a direct consequence of that structure. Cost and latency fall relative to the single loop for any task whose full step sequence can be foreseen up front, because only one call produces the plan and the steps that follow it can be cheap or fully deterministic. Debuggability improves in a way the single loop cannot offer: the plan is a static, inspectable artifact that a person — or another process — can review before any tool call actually executes, rather than something that can only be reconstructed after the fact from a transcript. The failure mode this pattern trades in for is different, not smaller: a stale plan can keep driving the executor through actions premised on a world that has already changed, and unless something outside the pattern is explicitly watching for that divergence, the architecture has no internal signal that a replan is overdue.

The hierarchical supervisor: delegation with a documented price

A third pattern keeps one lead policy in charge of the overall task but gives it the ability to spin up several subordinate policies, each working in its own separate context. Anthropic’s account of building its own multi-agent research system describes exactly this: a lead agent plans an approach and spawns three to five subagents in parallel, each independently using its own tools and its own context window, then synthesizes their distilled findings into a final answer ^[2]. The numbers in that account are unusually specific for a vendor engineering write-up, and worth stating precisely because they name the price rather than hiding it: multi-agent configurations consume roughly 15 times the tokens of a single chat turn; running subagents concurrently rather than issuing tool calls one after another cut research time by up to 90% on complex queries; and in the team’s own internal evaluation, the multi-agent configuration outperformed a single-agent baseline by 90.2%. The same source is just as specific about where the pattern fails — agents over-spawning subagents for simple queries, duplicated work when a task description under-specifies who owns what, and an explicit statement that the architecture is a poor fit for domains that need shared context or have many dependencies between agents’ work, naming coding as an example of the latter.

AutoGen formalizes the same general structure independent of any one application: customizable, conversable agents coordinated through explicitly defined interaction patterns, demonstrated across domains from mathematics and coding to operations research and open-ended decision-making rather than tied to any single task type ^[10]. And the pattern is not confined to research demos — Claude Code documents a lead agent that spawns subagents to work on different parts of a task simultaneously, coordinating assignments and merging results, with a separate Agent SDK exposed specifically for building custom orchestration on top of that same primitive ^[4]. The OpenAI Agents SDK documents the equivalent choice from the manager’s side, calling it “agents as tools”: a manager agent keeps control of the conversation and invokes specialist agents the way it would invoke any other tool, explicitly contrasted against a “handoffs” pattern in which control passes to the specialist entirely rather than staying with the manager ^[5].

Formally, the supervisor’s policy chooses a subgoal for each worker, and each worker then runs its own instance of the general loop against a history that never touches its siblings’:

Because $h^{(i)}$ and $h^{(j)}$ are disjoint by construction, worker $i$’s error cannot enter worker $j$’s context directly — it can only reach the supervisor, and only in whatever compressed form the worker chooses to report. That disjointness is the formal reason this pattern offers stronger containment than the single loop for genuinely independent subtasks, and it is also exactly why the pattern is documented to struggle when subtasks are not independent: the architecture has no channel for worker $i$ to see worker $j$’s intermediate state even when the task actually requires it. Cost rises with the documented multiplier, latency improves only to the extent that subtasks are truly parallelizable, and debuggability gets harder in a specific way — failures are now spread across several separate transcripts that something has to reconcile after the fact, rather than sitting in one place.

The event-driven workflow graph: making the path an object

The fourth pattern replaces the implicit path of a transcript with an explicit one: a graph of nodes and edges through which execution moves, with the graph itself as a durable, inspectable object rather than a byproduct of a conversation. LangGraph documents itself as “a low-level orchestration framework and runtime for building, managing, and deploying long-running, stateful agents,” built from nodes that read and update a shared state object, edges that route between them, and durable execution: runs persist through failure and resume from where they left off rather than restarting. The same documentation is explicit that deterministic, hand-coded steps and LLM-driven steps can be mixed in one graph, and that human-in-the-loop interrupts can inspect or modify state “at any point” in the run ^[6].

The OpenAI Agents SDK documents the same distinction from the opposite direction, naming it directly: “LLM orchestration,” where the model decides its own flow through handoffs or tool calls, against “code-based orchestration,” where structured outputs route between agents and chains, evaluator loops, and parallel branches are wired explicitly in code ahead of time. The documentation states plainly that the code-based approach is more deterministic and predictable in speed, cost, and performance, and that this predictability is bought by giving up the flexibility an LLM-decided flow offers on genuinely open-ended tasks ^[5]. Anthropic’s own vocabulary draws the same line under different names: a workflow is a system “where LLMs and tools are orchestrated through predefined code paths,” as against an agent, which “dynamically directs its own processes” ^[1]. The event-driven graph pattern is, structurally, that workflow definition made durable and resumable, with individual nodes free to be as agentic as a task requires.

Formally, this pattern replaces the time-indexed loop with execution over a graph:

where each node $v \in V$ is either a deterministic function or an invocation of some policy $\pi_v$, and $\gamma$ is an explicit gate on the edge — a test, a validation check, or a human approval — that must pass before the transition is permitted. That is the structural reason human approval is a first-class primitive in this pattern rather than a wrapper bolted around it from outside: approval is just one kind of $\gamma$, attached to one particular edge, rather than a blanket condition on the whole run.

The tradeoffs follow the same logic as the other three. Debuggability and recoverability are the strongest of the four patterns in this specific sense: because the graph’s state is an explicit, checkpointed object, a failed run can resume from its last completed node instead of starting over, and any node’s state can be inspected in isolation. Cost and latency are whatever the graph’s author designed them to be — potentially cheaper than either the single loop or the hierarchical supervisor for a well-understood, repeatable task, or just as expensive as either if one of the nodes itself wraps a full agent loop. The price is paid up front: someone has to author the nodes and edges before the system can run at all, so a genuinely novel task that does not correspond to any existing edge has no path through the graph until a person adds one.

Four patterns, one bench

Collecting the four architectures’ own documented tradeoffs against the axes this article set out to compare makes the shape of the disagreement visible without forcing a ranking across them:

Every figure in that table is self-reported by the team that built the system being described, measured against its own internal baseline, not a third-party benchmark, and none of the four sources ran a shared task suite against the others. The 90.2% figure, the roughly 15x token multiplier, and the 5x token-efficiency figure each describe what one architecture cost relative to itself without the pattern in question, not a ranking of one architecture against another. Reading them as a cross-architecture leaderboard would overstate what any of them actually measured.

Where human approval actually sits

The four patterns place a human’s veto in structurally different locations, which matters more than any latency number for tasks where an ungated action is expensive to undo. In the single loop, approval is typically external and coarse: a permission prompt wrapped around the tool-call step, gating every action at the same granularity regardless of its stakes, because the loop itself carries no internal notion of a checkpoint to gate more selectively. In the planner/executor split, approval can attach to the plan as a single object, reviewed once before any tool actually runs — a real reduction in review effort compared with watching a transcript unfold, paid for by the risk of not catching a problem that only becomes visible once execution has already diverged from the plan that was approved. In the hierarchical supervisor, approval is naturally diffuse: a human can gate the supervisor’s decision to delegate, but by the time a worker’s own action would be visible, it may be several steps and a synthesis pass removed, bounded by the same reporting channel that limits what the supervisor itself ever sees of a worker’s failures ^[2]. In the event-driven graph, approval is not a special case at all — it is one instance of the gate function $\gamma$ attached to a specific edge, which is exactly what LangGraph’s documented human-in-the-loop interrupts implement: the ability to pause and inspect or modify state at a chosen point before the run is allowed to continue ^[6].

Choosing a pattern for a job

None of the primary sources behind this article claims its own pattern is the right default for every task, and two independent ones converge on the same underlying advice while using different vocabulary for it. Anthropic’s guidance is to begin with the simplest workflow that solves the problem and add agentic autonomy only once simpler, more predictable approaches fall short, because autonomy is explicitly framed as trading latency and cost for flexibility ^[1]. The OpenAI Agents SDK documentation draws what is functionally the same line under the label of code-based versus LLM-decided orchestration, recommending the deterministic, code-based option for workflows that are understood in advance and reserving model-decided flow for tasks that are genuinely open-ended ^[5]. Neither source frames this as a dispute to be resolved; both are stating the same tradeoff from their own product’s vantage point.

Read against the architecture and not the vendor, the shape of a task points fairly directly at a pattern. A single bounded task with a clear, checkable success condition fits the single-agent loop, where the cost of one long transcript is tolerable because the task is short enough that it stays legible. A task whose full step sequence can reasonably be foreseen before execution starts fits the planner/executor split, trading the ability to improvise mid-task for a cheaper, front-loaded, reviewable plan. A task that decomposes into subtasks that are genuinely independent of one another’s intermediate results fits the hierarchical supervisor — but only then, since the same sources that report its speed and quality gains are equally explicit that dependent subtasks are exactly where it is documented to fail. A task that recurs, must survive process restarts, or needs to pause for approval at specific, identifiable points fits the event-driven graph, where the cost is the upfront design work of actually drawing the graph.

What would change this

Three claims follow from the architecture rather than from any single vendor’s roadmap, stated as falsifiable predictions with a horizon of 12 August 2028.

One. The four patterns will stop being documented as mutually exclusive top-level choices and start being documented as composable primitives — a workflow graph with a hierarchical-supervisor node, or a planner whose executor is itself a small ReAct loop. Disconfirmed if the major agent SDKs in 2028 still present these four as alternative, non-nestable top-level architectures rather than parts that combine.

Two. The token multiplier reported for hierarchical patterns will fall as providers document shared context and caching techniques across subagents, rather than staying near the current reported figure. Disconfirmed if 2028 documentation from a comparable multi-agent system reports a similar or larger multiplier than the approximately 15x figure current today ^[2].

Three. Durable, checkpointed graph execution will become the substrate the other three patterns are commonly implemented on top of, rather than a separate offering competing alongside them — a “loop” becoming one kind of node inside a graph rather than a rival to it. Disconfirmed if the major agent SDKs in 2028 continue to treat the graph pattern as a distinct alternative rather than as infrastructure the other patterns run on.

None of these predictions requires a new capability from any underlying model. They follow from the architectural structure already documented today: four different shapes for the same retained state, each with a cost its own designers have written down.

What to take away

The single loop, the planner/executor split, the hierarchical supervisor, and the event-driven graph are not four competing guesses about how to build an agent — they are four documented, shipping answers to the same question, each with its price stated by the people who built it. A single transcript is the easiest thing to read and the easiest thing to corrupt. A plan computed once is cheap and reviewable and can go stale without noticing. A supervisor’s workers fail in isolation from each other, right up until the task requires them not to. A graph’s every transition is a place a human or a check can stand, at the cost of having to be drawn before it can run. The question worth asking about a new task is not which architecture is best in the abstract, but which one’s documented failure mode this particular task can actually afford.