Architecture Patterns

There Is No Universal Agent Pattern

In mid-2025, a Fortune 50 insurance company started building an AI system for claims processing. The vision: an automated pipeline that could receive a claim, extract information from uploaded documents, cross-reference policy terms, check for fraud indicators, estimate the payout, and route to the appropriate adjuster with a recommendation.

The architecture team -- smart, well-resourced, experienced with distributed systems -- designed an orchestrator-worker pattern. A central planning agent would receive the claim, decompose it into subtasks, delegate to specialist workers, collect results, and synthesize a recommendation. Clean separation of concerns. Each worker independently testable. The architecture diagram looked beautiful.

Six months in, they had 11 microservices, 4 specialist models, a task queue, a state management layer, and an orchestration engine. The document extraction worker was 94% accurate. The policy lookup worker was 96% accurate. The fraud detection worker was 91% accurate. The payout estimator was 93% accurate. End-to-end accuracy -- all four workers getting it right on the same claim -- was 76%.

The team they benchmarked against -- a mid-size insurtech startup -- had built a prompt chain. Four steps in sequence, each with a quality gate, the output of each step feeding directly into the next. End-to-end accuracy: 89%. Four steps instead of 11 services. Eighteen weeks instead of six months.

The insurance company didn't have a technology problem. They had a pattern selection problem.

Five Patterns, Mapped to Failure Modes

Components are the atoms of agentic systems. Architecture patterns are how you arrange those atoms into molecules -- and the arrangement determines whether you get water or hydrogen peroxide. Same elements, very different outcomes.

Anthropic's "Building Effective Agents" codified five patterns that production teams reach for repeatedly. They come with an explicit hierarchy: use the simplest pattern that solves the problem.

Pattern 1: Prompt Chaining. A fixed sequence of model calls where the output of one step becomes the input to the next. Each step has a single, well-defined job. Between steps, a quality gate checks whether the output is good enough to proceed. The analogy: an assembly line.

Pattern 2: Routing. The system classifies the input first, then directs it to the right specialist handler. The analogy: a hospital triage desk. The nurse doesn't treat you -- the nurse assesses your symptoms and sends you to the right department.

Pattern 3: Parallelization. Multiple model calls execute simultaneously on different aspects of the same input, and results are aggregated. The analogy: a panel of judges scoring a gymnastics routine simultaneously.

Pattern 4: Orchestrator-Worker. A planning agent receives the task, decomposes it into subtasks dynamically, delegates to specialist workers, and synthesizes the final output. The key word is "dynamically." The analogy: a general contractor building a house.

Pattern 5: Evaluator-Optimizer. One agent generates output. A second agent evaluates it against quality criteria. If the output doesn't meet the threshold, the generator revises. The analogy: a writer and an editor.

Think of it like cooking methods. Boiling, grilling, baking, stir-frying, and braising all use heat to transform food -- but each method matches a different ingredient and desired outcome. You don't braise a steak because braising is the most "advanced" technique. You grill it because grilling matches the cut.

The economics of each pattern. Prompt chaining: linear cost. A 4-step chain costs ~4x a single call. Predictable, budgetable. Routing: one classification call plus one specialist call. A router that sends 60% of queries to a lightweight handler saves 60% of what the heavy handler would have cost. Parallelization: cost equals the sum of all branches, but wall-clock time equals the slowest branch.

Orchestrator-worker: planning overhead. A task decomposed into 4 subtasks costs at minimum 6 model calls. Cost is variable and hard to predict. Evaluator-optimizer: multiplicative. Each iteration is generation plus evaluation. Three iterations means 6 calls. Cost variance is the highest of any pattern.

Picking the Pattern Before You Pick the Framework

The "framework-first" bias. Enterprise architecture teams evaluate frameworks before problems. They select LangChain or CrewAI, then build with whatever pattern the framework makes easy. The framework becomes the architect, and the team becomes the implementer. The PM who doesn't intervene at framework selection time loses control of the architecture pattern -- and by extension, loses control of the cost model and reliability profile.

Mixed patterns in a single product. Production systems almost never use one pattern exclusively. A customer service platform might route incoming requests (Pattern 2) to specialist chains (Pattern 1) where the complaint-handling chain includes an evaluator-optimizer loop (Pattern 5). The PM's job isn't choosing ONE pattern -- it's choosing the right pattern for each stage of the workflow.

The "let's add an orchestrator" escalation. When a chain starts failing on edge cases, the instinct is to replace it with an orchestrator. This is almost always the wrong move. Two specialized chains with a router outperforms one general orchestrator on cost, reliability, and debuggability -- for the vast majority of production workloads.

Migrating Between Patterns Without a Rewrite

Consider a social media company processing 50 million posts per day. Each post needs classification (safe, borderline, violating), and violating posts need detailed analysis. The naive approach: an orchestrator agent per post. 50 million planning calls per day. At $0.003 per call, that's $150,000/day in orchestrator costs alone -- before any analysis happens. Over $200 million annually.

The right approach: routing plus specialized chains. A fast classifier (Haiku-class model) sorts every post into three buckets. 82% safe -- no further processing. 12% borderline goes to Chain A (3-step contextual review). 6% likely violating goes to Chain B (escalation with parallel policy check).

The routing layer is the key insight. By classifying first, the system skips deep analysis on 82% of traffic. Each chain at 93-95% per step with only 3 steps holds above 80% end-to-end. An orchestrator with 6 decision points: 0.93^6 = 64%.

The team tested adding an eval loop to Chain B: generate a violation report, have a second model grade it, refine if needed. Cost doubled from $36K/day to $72K/day. But accuracy improved from 82% to 89% -- catching 210,000 additional violations daily that would otherwise need human review. The evaluator-optimizer paid for itself on Chain B. They did NOT add it to Chain A -- borderline content has inherently ambiguous signals, and evaluators disagreed with each other.

Remember This

1. Five patterns, one hierarchy: prompt chaining, routing, parallelization, orchestrator-worker, evaluator-optimizer. Start at the top. Move down only when the simpler pattern demonstrably fails.

2. The pattern determines the economics. Chaining is linear cost. Routing reduces cost. Parallelization trades latency for throughput. Orchestrator-worker adds planning overhead. Evaluator-optimizer is multiplicative. Select the pattern your budget can sustain at scale.

3. Your framework's default pattern will become your product's default pattern unless the PM intervenes. Choose the pattern first, then the framework that supports it -- not the reverse.