What Are AI Agent Architecture Patterns? A Practical Guide for Builders

TLDR: AI agent architecture patterns are the reusable shapes for combining a model with tools and control flow: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer workflows, plus the autonomous agent loop itself. The key architectural decision is how much control you hand the model. This guide walks each pattern, when it earns its complexity, and where web retrieval fits, with the core taxonomy sourced from Anthropic's published engineering guidance.

What are AI agent architecture patterns? They are the standard ways to arrange a large language model, its tools, and the code that controls them. Anthropic's engineering essay on building effective agents, which introduced this taxonomy to most teams, draws one distinction that carries the whole field: workflows are systems where LLMs and tools are orchestrated through predefined code paths, while agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

That distinction is the real decision. Every pattern below sits somewhere on the axis between code decides and model decides, and the further you move toward the model, the more you trade predictability for flexibility. Anthropic's own advice is to find the simplest solution possible and only increase complexity when needed, which might mean not building agentic systems at all.

What Are the Five Workflow Patterns?

Anthropic names five workflow patterns, each for a different task shape. All descriptions below are from the essay, fetched 2026-09-09.

Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one, with programmatic gates between steps to check the process is on track. Use it when a task splits cleanly into fixed subtasks, like generating an outline, checking the outline meets criteria, then writing the document from it.

Routing classifies an input and directs it to a specialized followup task, which keeps prompts focused: optimizing one kind of input in one branch does not hurt performance on other kinds. Use it when your inputs come in distinguishable types, like separating a simple factual question from a research request.

Parallelization runs LLM calls simultaneously and aggregates their outputs programmatically, in two variations: sectioning, breaking a task into independent subtasks, and voting, running the same task multiple times for diverse outputs. Use it when subtasks are independent or when you need multiple passes to be confident.

Orchestrator-workers has a central LLM dynamically break down tasks, delegate them to worker LLMs, and synthesize the results. Use it for tasks where you cannot predict the subtasks in advance, which is why coding assistants gravitate toward this shape: the number of files to change is not knowable until the model has looked.

Evaluator-optimizer has one LLM call generate a response while another evaluates it in a loop. Use it when you have clear evaluation criteria and iterative refinement provides measurable value, like translation with a critic, or search iterations that keep digging until a fact is confirmed across sources.

How Does the Autonomous Agent Loop Differ From a Workflow?

An agent is the pattern where the model runs the loop. It starts with a task, plans, calls tools, observes results, and decides whether to continue or finish, without a predefined code path deciding the sequence. Anthropic's framing: agents dynamically direct their own processes and tool usage. The practical consequence is that agents handle open-ended tasks where the number of steps is unknown, and they cost more to run and debug, because every execution can take a different path.

The failure mode is specific and detectable: an agent that never terminates, looping on tool calls that do not move it closer to the task. The standard defenses are a step budget, a token budget, and a stop condition in the prompt. Detect runaway loops in your traces by counting tool calls per session, which is also how you find the subtler variant: an agent that technically terminates but burns most of its budget re-querying for information it already retrieved.

How Do You Choose a Pattern for a Given Task?

The decision framework, in order:

Can a single model call do it? Then do that. A retrieval step plus one grounded generation is not an agent, and calling it one adds cost without capability.

Is the task decomposable in advance? If you can write down the steps before runtime, use a workflow: chaining for sequential steps, parallelization for independent ones, routing for input types you can enumerate.

Is the decomposition only knowable at runtime? Use orchestrator-workers, or a full agent loop if the task also requires the model to decide when it is done.

Is there a verifiable quality bar? Evaluator-optimizer earns its loop only when you can state the evaluation criteria concretely. Vague criteria produce a loop that refines tone forever without improving correctness.

The tradeoff to name in your design doc is predictability against flexibility: workflows offer predictability and consistency for well-defined tasks, while agents are the better option when flexibility and model-driven decision-making matter. That sentence is close to a paraphrase of Anthropic's guidance because it is the correct framing.

Where Does Web Retrieval Fit in These Architectures?

Retrieval is the most common tool in every one of these patterns, because most agent tasks start with figuring out the current state of something the model was not trained on. The architectural question is not whether to add retrieval but where: inside a workflow gate, inside a worker, or inside the agent loop.

In a chaining workflow, retrieval is one link: search, then gate on whether the results contain the needed fact, then generate. In orchestrator-workers, each worker can carry its own retrieval tool scoped to its subtask. In an agent loop, the model calls search when it decides it needs to, which is where runaway-query loops live.

A retrieval primitive like the You.com Web Search API slots into any of these positions: it returns web and news results in one request as structured JSON with URLs, titles, descriptions, and snippets per result, so the gate, worker, or agent reads fields instead of parsing pages. For the branches of a routing pattern that need full page text, the Contents API extracts markdown from URLs you specify, and for an evaluator-optimizer loop over research questions, the Research API returns a multi-step cited answer the evaluator can check against sources.

Here is the retrieval link as code, a workflow gate that searches and checks whether results exist before generating, using the You.com Web Search API's documented endpoint and parameters:

import json
import os
import urllib.request
import urllib.error

def retrieve(query, count=5):
    """Search gate: return web results, or None on empty."""
    req = urllib.request.Request(
        "https://ydc-index.io/v1/search",
        method="POST",
        headers={
            "X-API-Key": os.environ["YDC_API_KEY"],
            "Content-Type": "application/json",
        },
        data=json.dumps({
            "query": query,
            "count": count,
            "freshness": "month", # gate on recent results
        }).encode(),
    )
    try:
        with urllib.request.urlopen(req, timeout=30) as resp:
            data = json.loads(resp.read())
    except urllib.error.HTTPError as e:
        raise RuntimeError(f"search gate failed: HTTP {e.code}")
    web = data.get("results", {}).get("web", [])
    return web or None # None means: do not generate, re-plan instead

The gate pattern matters more than the specific vendor: the two failure modes it prevents are generating from an empty retrieval and generating from stale results, and both are cheaper to catch at the gate than in review.

How Do Tool Standards Like MCP Change the Architecture?

The Model Context Protocol is an open-source standard for connecting AI applications to external systems: data sources, tools, and workflows, with the spec's own analogy being a USB-C port for AI applications (modelcontextprotocol.io, fetched 2026-09-09). Its architectural effect is on the tool layer: instead of writing a custom integration per tool per framework, you expose tools through a server any MCP-compatible client can call. You.com runs an MCP server for web search, so an agent built in any MCP client gains retrieval without bespoke glue code.

What MCP does not change is the pattern choice. A routing workflow with MCP tools is still a routing workflow. The standard replaces integration plumbing, not architecture.

What Should You Watch When Composing Patterns?

Two composition rules keep multi-pattern systems debuggable. First, every pattern boundary needs a logged artifact: the routing decision, the gate result, the orchestrator's task decomposition. Without those, a failure inside a composed system is indistinguishable from a failure of the composition. Second, resist pattern stacking as a default. An evaluator-optimizer wrapped around an orchestrator-workers with voting inside each worker is sometimes the right design, and it is always the right design to justify in writing first, because each added loop multiplies the paths an execution can take.

For evaluating whether a composed architecture actually performs, the AI agent evaluation guide covers scoring an agent end to end, and the LangChain web search tool guide shows retrieval wired into a specific agent harness. For the tool layer underneath, the search API hub is the starting point.

Next action: take one task you were about to give an autonomous agent, write down whether its steps are knowable in advance, and if they are, build it as a workflow with a retrieval gate first. Ship that, measure it, and only then decide whether the agent loop earns its complexity.