'Agent' gets applied to a single LLM call with a system prompt, to a genuinely autonomous multi-step tool-using loop, and to everything in between, which makes the word nearly useless in a technical conversation unless you name the actual architecture underneath it. There are really only a handful of distinct patterns in production use, each with a real name, a specific mechanism, and specific tradeoffs, and picking the wrong one for your problem shape is one of the most common and most expensive mistakes in building an 'agentic' feature.
The ReAct pattern: reason, act, observe, repeat
ReAct (short for reason-and-act) is the foundational pattern behind most tool-calling agents: the model reasons about what to do next, calls a tool (a function, an API, a search), observes the result, and loops back into reasoning with that new information, continuing until it decides the task is complete or it hits a step limit. The mechanism is simple and the failure modes are specific: the model can get stuck in a loop repeating a failed action with minor variations, it can decide it's 'done' prematurely when it isn't, or it can burn through step budget on a task that turns out to be more open-ended than it looked at the start. ReAct works best when each tool call produces a clear, checkable signal about whether it succeeded, a search that returns results or doesn't, a code execution that passes tests or throws an error, because that signal is what lets the model's reasoning step actually correct course. It works worst on tasks where 'success' is subjective and the model has no external signal to tell it whether the last action actually helped.
Planner-executor: separating what to do from doing it
The planner-executor pattern splits the agent into two distinct phases run by two distinct model calls (or two distinct roles within one model, though a genuine split usually works better): a planner that reads the task and produces a concrete, ordered plan of steps before anything executes, and an executor that carries out each step, often with its own tool access and its own error handling, without re-deciding the overall strategy. The real advantage isn't capability, it's auditability: the plan is a discrete artifact that can be reviewed, logged, and in higher-stakes settings, approved by a human before execution starts. This costs something, an extra model call's worth of latency and the engineering overhead of a plan format both phases agree on, but it buys a system where you can answer 'what was it about to do and why' with a concrete document instead of reconstructing intent from a chain of tool calls after the fact. This pattern is the right default whenever a task has enough steps that a single ReAct loop would be hard to review after something goes wrong.
Multi-agent orchestration: real value, real overhead, often overused
Multi-agent orchestration, multiple distinct agents with different roles, tools, or context windows, coordinated by an orchestrator or by passing messages to each other, solves a genuine problem: a single agent juggling too many roles and tools in one context window tends to lose track of instructions and confuse which tool applies to which sub-task. Splitting into specialized agents (a research agent, a drafting agent, a review agent) each with a narrower job and a cleaner context solves that specific problem well. The honest tradeoff is that every additional agent is an additional failure surface and an additional coordination problem: agents can talk past each other, an orchestrator's routing logic can send a task to the wrong specialist, and debugging a failure now means tracing through inter-agent messages instead of one linear log. In practice, multi-agent architectures are reached for more often than they're actually needed; a single well-designed ReAct loop or planner-executor split with good tool scoping handles a large share of tasks that get over-engineered into a multi-agent system, and the added coordination overhead often costs more in reliability than it buys in capability.
Human-in-the-loop: not a fallback, an architecture decision
Human-in-the-loop checkpoints, points where the agent pauses and requires explicit human approval before taking an action, get framed as a compromise for a system that isn't fully autonomous yet, but that framing is usually backwards. A checkpoint is the correct architecture, not a stopgap, whenever the cost of a wrong autonomous action is high and the action is hard or expensive to reverse: sending an email to a customer, executing a financial transaction, deleting data, deploying code to production. The design question isn't whether to add a human checkpoint, it's where in the loop to put it: before an irreversible action specifically (cheapest in friction, catches the highest-stakes moment), or after every step (safest, but slow enough that it defeats the purpose of automating the task at all). The pattern that tends to work is a middle path: full autonomy for reversible, low-stakes steps (searching, drafting, reading), and an explicit checkpoint gating only the irreversible or customer-visible actions.
A decision table: which pattern fits which problem shape
The right pattern follows from the shape of the problem, not from which architecture is currently getting the most attention. Four questions settle it in most cases: is the task bounded or open-ended, does a failed action produce a clear external signal, does the action need to be auditable or reviewable after the fact, and how reversible and high-stakes is the final action.
| Problem shape | Best-fit pattern | Why |
|---|---|---|
| Bounded task, clear success/failure signal per step (e.g. code execution, structured search) | ReAct tool-calling loop | The model can self-correct using the tool's own feedback; no extra coordination needed |
| Multi-step task where the plan itself needs review or logging before execution | Planner-executor | Produces a concrete, auditable artifact before any action runs |
| Task naturally splits into distinct roles needing separate context or tools | Multi-agent orchestration | Prevents one agent's context from getting overloaded with unrelated roles and tools |
| Any task with a high-stakes, hard-to-reverse final action | Human-in-the-loop checkpoint (layered on any of the above) | Autonomy is fine for the reversible steps; the irreversible one needs a human gate |
| Open-ended task with no clear definition of 'done' | None of the above cleanly; needs a bounded sub-scope carved out first | All patterns above assume some checkable notion of task completion; without one, the agent can't reliably self-terminate |
The tradeoff underneath all of them: latency and auditability vs. speed and simplicity
Every step away from a single, simple LLM call, adding a ReAct loop, splitting planner from executor, adding more agents, adding human checkpoints, buys some combination of reliability, self-correction, or auditability at the direct cost of latency, engineering complexity, and more places for something to silently break. The right amount of architecture is the minimum that satisfies your actual requirement for auditability and error tolerance, not the maximum that's technically impressive. A team that reaches for multi-agent orchestration and human checkpoints on every step for a low-stakes internal drafting tool has traded away speed and simplicity for safety guarantees the task never needed; a team that ships a bare ReAct loop with no checkpoint on an agent that can issue refunds has made the opposite, more dangerous mistake.