Agent Architectures

Chapter 1: The Agent Loop

Let's make "an agent is a model in a loop" concrete, because that loop is the atom of everything that follows. A single-agent system operates in a continuous cycle: perceive the environment, decide the next step, act to make progress, then observe the result — and repeat.

Spelled out as the guide does, interacting with an agent follows three beats. First, a user gives the agent a task. Second, the agent formulates a plan, executes actions using its available tools, observes the results, and adjusts its approach based on the feedback. Third, it keeps repeating that cycle until the task is complete or it hits a stopping condition — like "pause here for human review."

Four components make the loop run, and naming them precisely matters because the rest of the lesson just rearranges these four:

• The model — the reasoning engine. It's the part that plans, decides, and judges. Swap it and you change how smart and how expensive the loop is.
• The prompt — defines the agent's role and capabilities. It's the job description: who the agent is, what it's allowed to do, when to stop.
• The tools — integrations that let the agent act on the outside world: a web search, a SQL query, an email send. Often wired in through MCP, the standard plug for connecting models to systems.
• Skills — optional packages of specialized domain knowledge and workflows that extend the agent beyond its base training (the subject of the Agent Skills lesson). They let an agent apply a proven framework instead of reasoning from scratch.

Step through a real example below. A research agent gets the task "research remote-work productivity tools engineering teams are adopting, and see if any correlate with our internal metrics." Watch it think, decompose, fire tools in parallel, reflect, and synthesize.

Trace the data flow, because that's where understanding lives. The task text goes in. The model first emits a thought — "this needs two independent data sources; I'll decompose into parallel searches and correlate at the end." That thought isn't idle; it's produced by a "think tool" that gives the model a scratchpad to reason before committing to an action. Then the model emits two tool calls at once — a web search and a SQL query — because it recognized they don't depend on each other. The two results come back, the model reflects ("I have baseline metrics but need engineering-specific adoption data"), issues refined follow-up calls, and finally synthesizes everything into one answer.

Chapter 2: Start Simple — the Cost of Complexity

Before we tour the fancy multi-agent patterns, we have to install the discipline that keeps you from misusing them. It's the most important sentence in the whole guide: start simple, scale intelligently. Begin with a single agent that does one thing well, and add complexity only when the data proves you need it.

Why such insistence on restraint? Because simple systems win on three axes at once. They're cheaper to run — fewer tokens, less compute. They're easier to debug when something breaks. And they give you clear metrics that tie directly to business outcomes. Every layer of architecture you add taxes all three.

The first lever is model choice. There are many models with very different abilities, and choosing well means balancing three factors: capabilities, speed, and cost. The guide's image is perfect — you wouldn't use a sledgehammer to hang a picture frame, and you wouldn't use a tack hammer to demolish a wall. A complex multi-agent coding framework wants the most capable model available. But processing thousands of routine support tickets? A lighter, faster model does the job just as well at a fraction of the cost.

And those fractions compound. Running a simple task through a premium model isn't just wasteful — it's slower and more expensive, and when you're doing it across hundreds of thousands of requests, the difference explodes. Play with the calculator below: set your daily volume, pick a model tier, pick an architecture, and watch the monthly token bill move.

Let's do the multi-agent arithmetic, because it's the number that should make you pause before reaching for orchestration. Multi-agent systems use roughly 10–15× more tokens than a single agent. Say a single-agent task costs about 6,000 tokens. The multi-agent version of the same task costs:

At 10,000 requests a day, that's the difference between 60 million and 720 million tokens a month. The guide is blunt: do the math on your expected volume before committing to a complex architecture. The performance had better justify the bill.

Chapter 3: Single Agents and Their Limits

We've championed the single agent. Now let's find its edge — the precise place where one agent stops being enough — because knowing that edge is what stops you from scaling too early and from scaling too late.

First, where single agents excel: open-ended problems where the path forward isn't clear from the start. You can't predetermine the solution because you don't know how many steps it'll take or what obstacles will appear. That's the agent loop's home turf — exactly the research task from Chapter 1.

And where to avoid them: when you need the perfect answer on the first try, 100% of the time. A single agent is powerful, but for the highest accuracy on genuinely complex problems, you'll want more structure. Here, though, the guide plants a flag you must not miss: before scaling to multi-agent, ask whether adding specialized Skills to your single agent gets you there more efficiently. Skills often buy the accuracy you wanted without the 12× token bill.

So what actually breaks a single agent? The research is sharp about it: single agents fall off sharply when there are two or more distractor domains. A "distractor domain" is a second, unrelated area of expertise the agent has to juggle at the same time — ask one agent to be simultaneously a legal expert, a financial analyst, and a marketing strategist, and its attention fractures. The widget below makes this cliff visible.

The flip side of that cliff is the headline statistic of the whole multi-agent case. Internal Anthropic research found that for complex tasks requiring the pursuit of multiple independent directions simultaneously, multi-agent systems outperform single-agent systems by 90.2%. The reasoning mirrors human organizations: intelligence reaches a threshold where groups of specialized agents accomplish far more than any individual generalist could.

So the decision rule sharpens into three triggers. Reach for multi-agent when: (1) the task is open-ended and you can't predict the steps in advance, needing the freedom to pivot and explore; (2) you need specialized expertise that would overwhelm a generalist — remember, two-plus distractor domains is the cliff; or (3) the problem demands pursuing multiple independent directions at once, where parallel processing pays off.

Chapter 4: Workflows vs. Agents — the Big Divide

Here is the conceptual spine of the entire field, and once you see it, the zoo of named patterns organizes itself. Every architecture sits on one axis: who controls the flow — your code, or the model?

On one end are agentic workflows. A workflow defines the structure of how things run — the sequence and conditions of each step — and, crucially, it is predefined and static. You, the engineer, map the path in advance. The model fills in each box, but the arrows between boxes were drawn by your code.

On the other end is the agent from Chapters 0 and 1, with dynamic control: the model decides its own next step at runtime. The path emerges as it goes. Nobody drew the arrows in advance because nobody could.

Toggle between the two on the same task below. The workflow shows a fixed graph — the same arrows every single run. The agent shows branching that's decided live, so two runs can take different shapes.

This single axis is a genuine trade-off, not a ranking — neither end is "better." The static workflow buys you operational predictability: you can map the entire process, estimate its cost ahead of time, and debug by examining a specific stage. It gives clear audit trails and deterministic behavior — which is why regulated environments love it. The price is flexibility: when an edge case appears that the predefined path never anticipated, the workflow has no branch for it (the rigid-script failure from Chapter 0, in a smarter costume).

The dynamic agent is the mirror image: it handles the unanticipated edge case gracefully, because it re-decides every lap — but you give up the ability to predict, pre-cost, and easily audit exactly what it'll do. Control versus flexibility. That's the whole game, and the next two chapters are simply the named patterns at each end: workflows (Chapter 5) and multi-agent systems (Chapter 6).

Chapter 5: The Workflow Patterns

Let's name the workflow end of the axis. There are three shapes you'll use constantly: sequential, parallel, and evaluator-optimizer. Explore each in the widget, then we'll dissect them.

Sequential workflows use a predetermined path: stage one feeds stage two feeds stage three. Their superpower is captured in one line — they trade latency for accuracy by making each AI call an easier, more focused task. Instead of asking one call to do a hard composite job, you break it into a chain of simpler calls, each more reliable. Use it when tasks decompose into clean linear dependencies: a draft→review→polish pipeline, or "write an outline, validate it meets criteria, then write the full document from the approved outline." The canonical example: a data-science pipeline — a scoping agent classifies the request, a data-engineering agent prepares the dataset, an analysis agent runs the models, a review stage validates or escalates, and finally results are delivered. Each stage depends on the last; none can be skipped.

Parallel workflows distribute independent tasks across agents simultaneously, then merge the results — the classic fan-out/fan-in shape. Reach for it when subtasks can run at once for speed, or when multiple perspectives raise confidence. The guide flags two flavors: sectioning, where each agent handles a different aspect (one model answers the user while another screens for inappropriate content — a guardrail), and voting, where several prompts independently judge the same thing and you set a vote threshold (great for reviewing code for vulnerabilities). The worked example: a financial-risk assessment fires credit, market, operational, and regulatory risk agents all at once, then a decision engine consolidates their scores.

Evaluator-optimizer workflows pair two AI roles in a loop: a generator creates content, an evaluator judges it against explicit criteria and returns actionable feedback, and the generator revises — repeating until the bar is met. It's writer-and-editor. Use it when clear evaluation criteria exist and iteration demonstrably helps: literary translation, code with security requirements, professional comms where tone matters. The example — an API-documentation generator looping with a technical evaluator that checks the docs against the actual code — typically runs 2–4 cycles, materially improving quality.

When do you avoid each? Skip sequential when a single agent already handles it, or when the task needs backtracking and iteration rather than clean hand-offs. Skip parallel when agents must build on each other's work or share mutable state with no conflict-resolution strategy. Skip evaluator-optimizer when the first attempt is already good enough, the criteria are subjective, or you're under hard real-time or token constraints — the extra cycles cost real money.

Chapter 6: Multi-Agent — Hierarchical vs. Collaborative

Now the other end of the axis: true multi-agent systems, where several specialized agents coordinate. They organize around two fundamental philosophies — centralized and decentralized — and the difference is entirely about who's in charge.

Hierarchical (supervisory) systems are centralized. A supervisor agent analyzes the incoming request, routes it to the right role-specific specialists, and synthesizes their responses into a coherent whole — a clear chain of responsibility. The clever mechanism: individual subagents are treated as tools. The supervisor uses its ordinary tool-calling ability to "invoke" a subagent exactly as it would call a search function. Subagents can even have their own subagents, hidden from the supervisor, which only talks to the team leader — just like a manager who delegates to a lead and never sees the lead's team.

Collaborative systems are decentralized. Autonomous peer agents communicate directly, negotiate roles dynamically, and solve the problem through distributed intelligence — no central controller. The defining property: coordination emerges from the agents' interactions rather than being imposed from above. Three common coordination mechanisms: group chat (agents collaborate in a shared conversation thread), event-driven (agents react to structured events as a shared language), and the blackboard (a shared knowledge repository all agents read from and write to, like a collective memory).

Toggle between the two below and watch the message flow. In the hierarchical view, everything routes through the supervisor. In the collaborative view, messages crisscross peer-to-peer and land on a shared blackboard.

The worked examples make the two concrete. Hierarchical: a marketing-campaign system where a "director" supervisor receives the brief, then delegates to a market-research agent, a creative-design agent, a copywriting agent, and a media-planning agent — reviewing and approving each, then synthesizing everything into one integrated campaign. Every arrow passes through the director. Collaborative: a competitive-intelligence system where pricing, product, marketing, financial, and social-media agents continuously share findings in real time — the pricing agent alerts the product agent about feature-price correlations, all of them cross-reference to resolve contradictions — and a report agent assembles the corroborated picture. No one's in charge; the insight emerges from the cross-talk.

Each philosophy has a signature failure mode, and naming it now sets up Chapter 8. Hierarchical systems struggle with context management: the supervisor's context can balloon past what one agent can coherently hold. Collaborative systems struggle with communication complexity and emergent behavior: all that peer chatter is expensive, and small changes can ripple unpredictably — agents can bounce a task back and forth forever without a conflict-resolution mechanism.

Chapter 7: The Architecture Chooser · showcase

Everything so far has been building toward one skill: looking at a real problem and naming the architecture it needs. The guide distills that into a decision framework, and here it becomes a tool you can drive. Answer the questions on the left; the architecture on the right redraws itself, with the reasoning.

The framework rests on a handful of questions. What level of control do you need? High control — regulatory compliance, financial transactions, safety-critical work where you must explain every decision to an auditor — pushes you toward single agents or sequential workflows. Low control — research, brainstorming, open exploration — makes collaborative multi-agent systems viable, where unpredictability becomes a feature. How complex is the domain? Single domain → a single agent handles it; multi-domain but predictable → sequential or parallel workflows; complex and open-ended → multi-agent. What are your resource constraints? Tight budget or time-to-market pressure argues for single agents you can ship in weeks, not multi-agent systems that take months and 10–15× the tokens.

Try a few combinations and watch the logic. Set control to high, domain to single, budget tight — it lands on a single agent (with Skills), because you need auditability and low cost, and one well-scoped domain doesn't trip the distractor cliff. Now bump domain complexity to multi-domain but predictable — it shifts to a sequential or parallel workflow, giving you per-stage structure without multi-agent unpredictability. Push domain to complex, open-ended and control to low — now multi-agent earns its cost.

A subtlety the Chooser encodes: even when several signals point "up," the right move is often to start one rung lower and design an evolution path. You can deploy a single agent in weeks; multi-agent systems take months to get right. Build something that works, instrument it, and add complexity only where the data shows it pays. That evolution path is Chapter 9.

(No quiz here — the Chooser is the test. If you can predict its recommendation before it draws, and explain why, you've internalized the framework.)

Chapter 8: Context, Observability & Failure Modes

Picking the right architecture is half the job. The other half is keeping it alive in production, where two specific gremlins bite agentic systems harder than ordinary software: context overflow and opaque failure.

Start with context. Every lap of the agent loop appends more to the model's context window — the user request, each thought, every tool call, and every tool result. Tool results are the silent killer: a single database query can return tens of thousands of tokens. Left unchecked, the window fills, and you get the classic multi-agent failure the guide names exactly: context window overflow, degraded reasoning, and coordination failures. The supervisor's context, in particular, grows "too complex for one agent to manage effectively."

Watch it happen, then watch the fixes work, in the widget below.

The three mitigations the guide prescribes map onto what you just toggled. Context editing automatically clears stale tool calls and results as you approach the token limit, while keeping the conversation flow intact. Memory tools let agents store and retrieve information outside the window — file-based systems that persist across sessions, so the working context stays lean. And well-designed tools include pagination, range selection, filtering, and truncation with sensible defaults — capping any single response at something like 25,000 tokens so one fat query can't exhaust the window.

Put numbers on why the cap matters. Start with a 200,000-token window and ~20,000 tokens of base context (system prompt + task). An uncapped tool returning 60,000 tokens per call gives you:

Now cap each tool response at 25,000 tokens instead:

Same window, more than double the working headroom — just by truncating fat tool outputs at the source.

The second gremlin is observability. AI applications already function like black boxes; agents add layers on top. When an agent fails, you can't just read a stack trace — the core logic happened inside a neural network. You need visibility into prompt chains, model decision paths, retrieval contexts, token consumption, and the whole reasoning workflow. The key insight: debugging an agent means understanding not just what happened but why the model made each decision and how context flowed through the multi-step chain. In multi-agent systems this gets worse — you must trace not just individual agent behavior but the interaction structure between agents, or emergent coordination bugs become nearly impossible to diagnose.

Chapter 9: Evolve — Hybrids, the Journey & the Cheat Sheet

One last idea ties the whole lesson into a strategy: your architecture should evolve with your needs. Start simple, measure everything, add complexity only when it delivers measurable value. The best architecture is the simplest one that meets today's requirements while leaving a path to tomorrow's.

The guide's e-commerce example is the perfect illustration of climbing that ladder one rung at a time. Step through it below — each phase adds exactly one capability, justified by a need the previous phase exposed.

Production systems rarely stay pure — they become hybrids that combine patterns strategically. Three common ones are worth memorizing. Hierarchical with parallel processing: a supervisor delegates to specialists, and each specialist runs its own parallel workflow — a risk supervisor delegating to credit, market, and operational agents that each fan out internally. Sequential with dynamic routing: a linear process that invokes different agent types based on intermediate results — classify the request, then route to a simple resolver or a full multi-agent research team depending on complexity. Single agent with multi-agent escalation: a cheap single agent handles routine cases but automatically triggers a sophisticated multi-agent system on edge cases — optimizing cost while preserving capability.

Here's the whole field on one page.

And the three questions to ask before any of it: What level of control do I need? How complex and multi-domain is the problem? What are my resource constraints? Answer those honestly and the architecture mostly chooses itself.

Where to go next

• Agents & Tool Use: the mechanics inside one loop — function calling, ReAct, state, error recovery. The engine this lesson arranges into patterns.
• Agent Skills: the "Skills" rung of the ladder — how to give a single agent deep domain expertise before scaling to multi-agent.
• MCP: the standard plug that wires tools (and subagents-as-tools) into your agents.
• Agent Evaluation: how to measure whether the architecture you chose is actually working — the observability of Chapter 8, done rigorously.
• RAG: the retrieval layer many single agents lean on for grounded answers.
• Harness Engineering: the system around every architecture on this page — workflow automation, file-system memory, sub-agent process management, and why the deployment layer rivals raw intelligence.
• Harness Optimization: stop hand-picking architectures — ADAS and AFlow search the space of agentic workflows automatically, and beat hand-designed ones.

"Start simple, measure everything, add complexity only when it delivers measurable value. Generative AI answers questions; agents solve problems."