Agent Architecture Patterns

Agent architecture patterns are the composable building blocks for constructing agentic AI systems, as documented by Anthropic's engineering team in Building Effective AI Agents and Scaling Managed Agents: Decoupling the Brain from the Hands. The patterns are commonly presented as an ordered ladder of complexity, with simpler patterns preferred unless additional complexity demonstrably improves outcomes. A separate line of work by Rohit Krishnan and Andrey Fradkin proposes market-based coordination as a distinct topology alongside the hub-spoke patterns that dominate current frameworks.

Simplicity-first principle

The composition documented by Anthropic favors simple, composable patterns over complex frameworks or specialized libraries. The default recommendation is to optimize a single LLM call with retrieval and in-context examples before building any multi-step system. Each successive rung of complexity adds latency, cost, and error compounding, so the recommendation is to ascend only when lower rungs demonstrably fail.

The complexity ladder, ordered from simplest to most complex, runs:

1. Single LLM call (no agentic system)
2. Augmented LLM (tools, retrieval, and memory)
3. Structured workflows (predefined code paths)
4. Autonomous agents (dynamic self-direction)

The seven patterns

The patterns are ordered by complexity. The first is the foundational unit; patterns two through six are structured workflows with predefined code paths; the seventh is the autonomous-agent case.

1. Augmented LLM (foundation)

The basic unit is an LLM enhanced with retrieval, tools, and memory. The model actively uses these capabilities, generating search queries, selecting tools, and determining what to retain. The Model Context Protocol standardizes tool integration across this pattern.

2. Prompt chaining

A task is decomposed into a sequential pipeline in which each LLM call processes the prior call's output. Programmatic "gate" checks can verify progress at intermediate steps. It applies when tasks divide cleanly into fixed subtasks and trading latency for accuracy is worthwhile. Examples include generating marketing copy and then translating it, or writing an outline, validating it, and then writing the document.

3. Routing

Input is classified and directed to specialized handling, allowing separation of concerns without cross-contamination between input types. It applies to complex tasks with distinct input categories that are better handled separately, where classification is reliable (via an LLM or a traditional classifier). Examples include routing support queries (general, refund, technical) to different downstream prompts, or routing easy questions to Haiku 4.5 and hard questions to Sonnet 4.6.

4. Parallelization

Multiple LLM calls run simultaneously and their outputs are aggregated programmatically. It has two variants. In sectioning, independent subtasks run in parallel, such as multiple guardrail checkers evaluating different aspects. In voting, the same task is run multiple times for diverse outputs, such as multiple code-vulnerability reviewers. It applies when parallelism speeds completion or multiple perspectives improve confidence.

5. Orchestrator-workers

A central LLM dynamically breaks tasks into subtasks, delegates them to worker LLMs, and synthesizes the results. Unlike parallelization, the subtasks are not pre-defined; the orchestrator determines them based on the input, and this flexibility of subtask generation is the key distinction from parallelization. It applies to tasks where the required steps cannot be predicted in advance, such as multi-file code changes or multi-source research.

6. Evaluator-optimizer

One LLM generates a response while another evaluates it and provides feedback in a loop; the generator iterates until the evaluator is satisfied. It applies when clear evaluation criteria exist, iterative refinement measurably improves outputs, and the LLM can articulate actionable feedback. Examples include literary translation with nuance critique, and complex search tasks where an evaluator decides whether further searches are warranted.

7. Autonomous agents

An LLM uses tools based on environmental feedback in a loop: plan, act, observe, adjust, and repeat. The agent self-directs, and humans can intervene at checkpoints. It applies to open-ended problems where the required steps cannot be predicted, where LLM trust is established, and where the task operates in a trusted environment. The pattern carries higher cost and compounding errors, and requires extensive sandboxed testing and guardrails.

Market-based coordination

A line of work by Krishnan and Fradkin proposes market-based coordination as a topology distinct from the hub-spoke / orchestrator-workers pattern, set out in two related publications. *MarketBench* (Fradkin & Krishnan, April 27 2026) presents a formal proof that market allocation weakly dominates every non-market alternative under standard assumptions, together with an empirical demonstration that frontier LLMs are miscalibrated on success-probability and token-cost self-assessment. *Why Coase needs Hayek* (Krishnan, May 2 2026) reports an empirical head-to-head running solo, hub-spoke, and market topologies across 15 hand-written tasks. In that comparison, the market topology beat hub-spoke on cost by roughly 4× and tied solo on quality, with mean costs of $1.69 (market), $5.33 (hub-spoke), and $1.34 (solo) and quality scores of 7.2 (market), 6.7 (hub-spoke), and 7.2 (solo).

Krishnan and Fradkin's empirical work yields topology recommendations by task type:

The title argument frames the proposal through Coase and Hayek. Krishnan's reading of Coase is that as transaction costs decline, work unbundles into many small actors that must coordinate; his reading of Hayek is that markets work because price signals aggregate dispersed local knowledge. Krishnan argues that AI agents will develop dispersed local knowledge as they specialize through different prompts, contexts, memories, and tools, and that continual learning therefore makes markets necessary. He contends that even before continual learning, the empirical results show markets beating orchestration.

Krishnan characterizes existing frameworks as variants of one topology: "All the current harnesses are versions of hub-spoke models. The spokes might be the same model as the hub or different, but the logic is still that of an orchestrator splitting tasks out." He applies this description to Claude Code, OpenAI Codex, Cursor, and most agentic-AI products, and argues that the empirical case is strong enough to treat the market-based pattern as a first-class architectural option.

Per MarketBench, the binding constraint on this approach is agent self-assessment: agents cannot reliably forecast their own success probability or token cost. Krishnan describes a market built on agent bids under these conditions as "a bartering shantytown rather than the modern New York City." He argues the topology wins regardless because of the diversity premium and retry mechanics, but that further progress requires self-assessment to become a target of training and evaluation.

Coordination behaviour within topologies

A topology specifies how work is routed between agents; it does not determine whether the agents cooperate once routed. Experiments reported by Anthropic's Frontier Red Team in August 2026 found the prescriptive part of the topology to have little effect on outcomes in one setting and a large effect in another (Patterns and problems in emerging multiagent systems).

In a 12-hour study in which swarms of agents were directed to build a text-based open-world game, three prompt conditions were compared: a baseline instructing agents to form teams, a prescriptive-roles prompt naming team functions, and a "CEO hierarchy" prompt designating one agent as orchestrator with all others taking assignments from it. The report states the prompts "did not make much difference" and that the resulting games were poor in all three conditions. This is the orchestrator-workers pattern imposed by prompt rather than by scaffolding, and the finding is that imposing it that way did not produce coordination.

The same study found the merged-PR fraction and the median agent's code sharing to move non-monotonically across model generations rather than improving together: Sonnet 4.6 and Opus 4.6 committed to shared files but merged few pull requests, while Opus 4.8 and Mythos Preview raised the merge fraction by having each agent retain high ownership of its own files, reducing the conflicts to be resolved. Only Sonnet 5 combined relatively high code sharing with high PR throughput. On that reading, a high merge rate is compatible with either coordination or its avoidance, and the two are distinguishable only by the sharing metric.

Where subtasks are genuinely independent, the same report found coordination to add discovery rather than throughput. A 45-agent swarm with a shared forum and an arbiter agent found 266 vulnerabilities over 27 million tokens across 15 open-source projects on Mythos Preview, against 21 over 6.5 million tokens for independent agents each assigned a fixed location — but roughly half the swarm's findings lay outside the assigned directories, and restricted to those directories the two methods were comparable on tokens per vulnerability. The two sets overlapped on 12 vulnerabilities. The report attributes the difference to the swarm choosing where to search and to agents building their own tools and specializing by vulnerability type.

Agent-computer interface design

The agent-computer interface (ACI) is the model-facing analogue of the human-computer interface (HCI). Tool documentation is held to deserve the same prompt-engineering investment as the overall prompt. Drawing on Anthropic's SWE-bench experience, the documented principles are:

• Format close to naturally occurring internet text, minimizing format overhead.
• Give the model enough tokens to "think" before writing itself into a corner.
• Avoid counting overhead, such as requiring accurate line counts or string-escaping.
• Make parameter names and descriptions self-evident, treating them as docstrings written for a junior developer.
• Use absolute filepaths rather than relative ones, which eliminates relative-path errors after directory changes.
• Test with many example inputs in a workbench and iterate on mistakes.

Production infrastructure

For production-scale systems, the patterns require supporting infrastructure. The architectural choices documented in Scaling Managed Agents: Decoupling the Brain from the Hands include:

• Brain/hands/session decoupling: separating the harness (brain), sandbox and tools (hands), and event log (session) into independent interfaces, which enables independent failure, recovery, and scaling.
• Session as external context object: keeping the session log outside Claude's context window, where it is recoverable, durable, and interrogable via getEvents(), preserving history that context compaction would lose.
• Credential isolation: keeping auth tokens unreachable from the sandbox where agent-generated code runs, using a vault pattern in which an MCP proxy fetches credentials and the agent never handles them directly.

Decoupling the brain from the hands allowed on-demand sandbox provisioning; per Scaling Managed Agents: Decoupling the Brain from the Hands, p50 time-to-first-token dropped by roughly 60% and p95 dropped by more than 90%.

Anthropic's production experience is that harnesses encode assumptions about what the model cannot do, and that those assumptions need frequent reassessment as models improve. As an example, a harness added context resets because Claude Sonnet 4.5 would prematurely wrap up tasks as it sensed the context limit approaching, a behavior described as "context anxiety"; Claude Opus 4.5 eliminated this behavior, leaving the resets as dead weight. The stated lesson is to design for the interface rather than the current model limitation.

Relation to policy

These patterns affect how AI governance applies to agentic systems. Anthropic argues that agent behavior depends on the harness, tools, and environment as much as on the model, such that model-centric regulation alone is incomplete Trustworthy Agents in Practice (Anthropic, April 2026). Orchestrator-worker chains raise principal-agent questions of responsibility when a worker agent takes a harmful action directed by an orchestrator, and attribution across the pattern is unresolved. Evaluator-optimizer loops, which iterate toward stronger outputs, can also iterate toward stronger harmful outputs, a dual-use concern for code generation, persuasion generation, and similar tasks.

Relationships

• depends-on: Agentic AI — foundational concept
• supports: Agentic AI — provides specific patterns
• related: Model Context Protocol (MCP) — standardized tool integration across patterns
• related: Prompt Injection — each pattern has a different injection surface area
• related: AI Coding Agents — orchestrator-workers and evaluator-optimizer are the dominant patterns in coding-agent products
• related: Unintended coordination between AI agents — coordination arising outside any designed topology
• supports: Patterns and problems in emerging multiagent systems — empirical results on how these topologies behave once populated
• instance-of: Agentic AI — concrete realization of the agentic paradigm
• supports: Trustworthy Agents in Practice (Anthropic, April 2026) — patterns structure how safety principles apply