Agent Architectures

Different ways to structure the loop between reasoning and acting, each with different tradeoffs between reliability, cost, and how much the agent can handle on its own.

How We Got Here: Prompt → Context → Harness → Loop → Graph

Every pattern on this page is a point along one evolution, and it helps to see the whole chain before the individual stops:

• Prompt — a single completion. No memory of anything not already written into it, no way to act.
• Context — retrieved documents, tool outputs, and conversation history get assembled into the prompt before generation. Richer input, still one shot.
• Harness — code wraps the model so it can actually execute a tool call and get the real result back, not just describe what it would do.
• Loop — the harness repeats: reason, act, observe, reason again. This is ReAct, below — the first stage that can course-correct mid-task instead of committing to one shot. For what actually makes one loop trustworthy on its own (a real pass/fail condition, not "looks good"), see Loops and Graphs: The Actual Anatomy.
• Graph — multiple loops, tool calls, and sub-agents become nodes; the edges between them (including conditional edges) carry shared state. This is the Supervisor Pattern below, and what a framework like LangGraph makes concrete: an explicit state machine instead of one long linear transcript. For the actual node types, real-vs-fake edges, and how rejections get routed, see Loops and Graphs: The Actual Anatomy.

Why bother reaching Graph instead of stretching a single Loop further: a graph makes failure paths explicit rather than buried in one prompt's instructions ("if the search comes back empty, branch to a different node" is a real edge, not a hoped-for instruction the model might follow); it supports splitting a writer node from a checker node so one call's output gets independently verified rather than the same call grading its own work, which is where a lot of hallucination in long single-loop agents actually comes from; and because each node can be a smaller, tightly-scoped call instead of one enormous prompt carrying the whole task, well-designed graphs are often cheaper to run, not more expensive, despite having more moving parts.

ReAct (Reasoning + Acting)

The foundational pattern: at each step, the model produces a short reasoning trace ("I need to find X"), then an action (a tool call), observes the result, and loops — reason, act, observe, reason, act, observe — until it has enough information to answer. Interleaving reasoning with action lets the model course-correct based on real results, rather than committing to a full plan upfront that might be wrong. See Prompt Engineering — ReAct for the prompting technique this is built on.

Step through a scripted example of the loop, one step at a time or on autoplay:

Plan-and-Execute

Instead of interleaving reasoning and action one step at a time, the model first produces a full multi-step plan, then executes each step (possibly with a separate, cheaper model), only returning to re-planning if a step fails or new information changes the picture. Generally more efficient than pure ReAct for tasks with a predictable structure — but less adaptive to surprises mid-task. See Plan-and-Execute for the real Planner/Executor/Replanner architecture, a stepped-through worked example including a real replanning-on-failure trace, and when this pattern loses to ReAct.

Reflection / Self-Critique

After producing an output, the agent (or a separate call) critiques its own work against the original goal, and revises if needed — a form of using the same model's judgment as a lightweight quality gate. See Reflection / Self-Critique for the real Actor/Evaluator/Self-Reflection architecture from the Reflexion paper, a real trial from the paper (not a constructed example), and the paper's own named failure modes.

Routing & Supervisor Pattern

Two different answers to "which agent handles this?" — a router classifies once and dispatches to exactly one specialist, no looping back; a supervisor sits in a loop, inspecting each sub-agent's result and deciding whether another one needs to run before the task is actually done. The distinction matters more than it sounds: a router can't notice a request needs more than one specialist's output combined, and a supervisor pays a real coordination cost (extra LLM calls) for the ability to notice. Real code for both, and the same request handled both ways so the difference is concrete, not asserted: see Routing & Supervisor Pattern.

Single-Agent vs. Multi-Agent

A single, well-prompted agent with good tools can handle a surprising amount. Multi-agent systems (see Multi-Agent Systems) add value when a task genuinely benefits from specialization — different agents with different tools, instructions, or models for different sub-problems — but they also add coordination overhead, latency, cost, and (the part usually left out) a real expansion of the attack surface, since every inter-agent handoff is a point where one agent's output becomes another's trusted input. A worked cost/complexity comparison and the specific security tradeoffs: see Single-Agent vs. Multi-Agent.

Sub-Agents and Orchestrator Patterns

A common middle ground: one orchestrator agent breaks a task into sub-tasks and delegates each to a specialized sub-agent, then combines their results. The orchestrator doesn't need deep expertise in each sub-task — it just needs to know which sub-agent to call and how to combine their outputs, similar in spirit to how a manager delegates without doing the work themselves. This is the "hierarchical" topology among the coordination patterns Multi-Agent Systems covers:

Memory and State

An agent's context window holds everything it currently "knows" during a run — but that's not the same as memory across steps or across sessions, and conflating the two is a common design mistake:

• Short-term (working) memory: the current conversation/task's context window itself — everything the agent has seen or done so far in this run. Bounded by the model's context length, and the reason long-running agents need an explicit strategy (below) once a task's history stops fitting.
• Long-term memory: information that needs to persist across runs/sessions — stored externally (a database, a vector store for semantic recall) and explicitly retrieved back into context when relevant, the same retrieval pattern as RAG applied to an agent's own history instead of a document corpus.

• Episodic vs. semantic memory: episodic memory stores specific past events/interactions ("last Tuesday, this user asked about X and we resolved it by Y"); semantic memory stores generalized facts/knowledge extracted from those events ("this user prefers concise answers") — the same distinction cognitive science draws for human memory, and a useful design split for what an agent should store as a raw log vs. what it should distill and keep.
• Context management for long tasks: as a task runs longer than fits in context, common strategies are periodic summarization (compress older history into a shorter summary, keep recent turns verbatim), offloading (write detailed intermediate state to external storage, keep only a reference/pointer in context), or a sliding window (simply drop the oldest history) — chosen based on whether old detail still matters later in the task.

Recursive Language Models (RLM)

A specific, recent instance of the offloading idea above, precise enough to name on its own: Zhang, Kraska, and Khattab's "Recursive Language Models" treats an oversized prompt as an external environment rather than something that has to fit in context at all. The full input lives outside the model — stored as a variable in a Python REPL the model can execute code against — and the root LM never sees it directly; it only sees the user's actual query plus instructions for programmatically examining, slicing, and querying that external variable. When a piece needs real reasoning rather than mechanical lookup, the root LM makes a recursive call to itself (or a sub-instance) over just that slice, then folds the result back in — a controller loop around the model, not a single oversized completion.

The reported results are a genuine step beyond ordinary long-context handling, not just a marginal gain: RLM successfully processes inputs up to two orders of magnitude beyond the underlying model's context window, with median improvements of 26% over context-compaction methods and 130% over CodeAct-style sub-calls, approaching vanilla GPT-5 quality on long-context benchmarks at comparable compute cost. The mechanism is why it beats plain summarization/sliding-window offloading (above): those strategies throw information away or flatten it; RLM keeps the full input intact externally and lets the model recursively decide what to look at, rather than deciding once, upfront, what to keep.

Human-in-the-Loop

Not every agent action should happen fully autonomously — human-in-the-loop (HITL) patterns insert a person at specific points:

• Approval gates: the agent proposes an action (send this email, execute this trade, delete this file) and pauses for explicit human approval before proceeding — standard for any action that's costly to reverse (see AI Security's "excessive agency" concern, which HITL approval gates directly mitigate).
• Escalation: the agent recognizes it's stuck, uncertain, or outside its competence, and hands off to a human rather than guessing — requires the agent to have an explicit "I don't know/can't do this confidently" path, not just always producing an answer regardless of confidence.
• Active correction: a human reviews and can edit the agent's intermediate reasoning or output mid-task, not just approve/reject the final result — common in coding agents (reviewing a proposed diff before it's applied) and research agents (correcting a bad search direction early rather than after significant wasted work).

Durable Execution: Retries, Checkpoints & Long-Running Agents

Agent tasks that run for minutes, hours, or days (a research task, a multi-day workflow) need infrastructure guarantees ordinary short-lived function calls don't:

• Retries: a failed step (a tool call timeout, a transient API error) should retry automatically with backoff rather than failing the entire task — the same general retry/backoff reliability pattern production systems use everywhere, applied to individual agent steps.
• Checkpoints: periodically persist the agent's full state (conversation history, intermediate results, current plan) so a crash or restart doesn't lose all progress — the task resumes from the last checkpoint instead of starting over.
• Durable execution frameworks: purpose-built orchestration (e.g. Temporal, or a graph-based agent framework's own persistence layer) that automatically checkpoints and can resume a long-running, multi-step workflow across process restarts, deployments, or even infrastructure failures — treating a long agent task as a durable workflow rather than a single in-memory function call that dies if the process does.
• Long-running agents specifically: tasks that legitimately take hours/days (deep research, large codebase migrations) need all of the above plus a way for a human to check progress asynchronously (rather than waiting synchronously for a response) — the UX shifts from "chat and wait" to "kick off and check back."

Sandboxing

Agents that execute code or interact with a real computer (below) need to do so in an isolated environment, not the host system directly — the same container isolation principle applied specifically to untrusted, model-generated actions: a sandboxed environment (a container, a VM, a restricted execution runtime) limits what damage a bad tool call or a prompt-injected malicious instruction (see AI Security) can actually do — file system access, network access, and resource limits are constrained regardless of what the agent tries to do inside the sandbox.

Agent Application Patterns

Named categories of agent, each with a characteristic tool set and environment:

• Browser agents: control a real (or headless) web browser — navigating pages, clicking, filling forms, reading rendered content — for tasks that require interacting with sites with no API, or that need to see a page exactly as a human user would.
• Coding agents: operate on a codebase — reading files, writing/editing code, running tests, using version control — the category this very assistant belongs to, typically sandboxed to a specific repository/environment.
• Computer-use agents: control a full desktop environment directly (mouse, keyboard, screen) rather than a scoped API or browser — the most general and highest-risk category, since the action space is "anything a human could do on this computer," making sandboxing and approval gates especially important.
• Autonomous research agents: given an open-ended research question, iteratively search, read, synthesize, and refine their own follow-up questions over an extended run — the long-running-agent pattern above, applied specifically to information-gathering-and-synthesis tasks rather than code or UI actions.

Next: MCP (Model Context Protocol) and A2A (Agent-to-Agent) — the standards that let agents connect to tools and to each other without custom integration for every pair.