workflowAgent Architecture4 min read
Building Effective Agents
Anthropic's playbook for picking the right agent architecture before you write a line of code. Five named patterns, one decision tree, zero framework lock-in.
A methodology for choosing between workflows and agents — and between five workflow patterns (chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) — based on the actual shape of your problem instead of whichever framework was trending last quarter.
The Problem
Most AI features ship as one of two failure modes. Either they're a single mega-prompt held together with hope, or they're a six-agent fanout that took two weeks to wire and still loses tasks. Both happen because teams pick a framework before they pick a pattern. The framework gets the credit when it works; the engineers get the bug reports when it doesn't.
Anthropic's "Building Effective Agents" — originally published Dec 2024, expanded in 2026 with production case studies from Coinbase, Intercom, and Thomson Reuters — inverts that order. Start without a framework. Classify your problem against five named patterns. Only escalate to autonomy when the problem actually requires it.
Workflows vs Agents — The First Decision
A workflow is a system where LLMs and tools are orchestrated through predefined code paths. An agent is a system where the LLM dynamically directs its own process and tool usage. Workflows are predictable, debuggable, and cheap. Agents are flexible, expensive, and harder to reason about.
The rule: start with a workflow. Escalate to an agent only when the steps can't be predicted in advance.
The Five Workflow Patterns
- Prompt chaining— Sequential steps where each call's output is the next call's input. Trades latency for accuracy by making each call an easier task. Use when the work decomposes cleanly. Example: outline → draft → critique → revise.
- Routing— A classifier sends each request to one of several specialized handlers. Use when input types are heterogeneous and one prompt can't serve them all. Example: support tickets routed to billing, technical, or refund pipelines.
- Parallelization— Two variants: sectioning splits a task into independent subtasks that run concurrently, voting runs the same task multiple times for consensus. Use for latency wins or for confidence on high-stakes outputs.
- Orchestrator-workers— A central LLM breaks the task into subtasks dynamically and dispatches them to worker LLMs. The difference from parallelization: subtasks aren't pre-defined. Use for code reviews across a sprawling diff, research across many sources, anything where the shape of the work is discovered as you go.
- Evaluator-optimizer— One model produces, another critiques, the loop runs until quality is met. Use when you have clear acceptance criteria and a single shot won't reliably hit them.
The Agent Loop
When the steps genuinely can't be planned, fall back to the agent loop: the model picks a tool, runs it, reads the result, picks the next tool, until it decides it's done. This is what Claude Code, Cursor agent mode, and Antigravity all are under the hood. The cost of autonomy is real — more tokens, longer runs, harder failure modes — so reach for it only when no workflow fits.
How to Pick
Write the task as one sentence ("Generate a release-notes draft from a list of merged PRs"), then walk the tree:
- Can you list the steps in advance? → Workflow, not an agent.
- Are the steps the same every time? → Prompt chaining.
- Do different inputs need different paths? → Routing.
- Can subtasks run independently? → Parallelization (sectioning or voting).
- Are subtasks dynamic and discovered at runtime? → Orchestrator-workers.
- Is quality variable per run and you have an evaluator? → Evaluator-optimizer.
- None of the above? → Agent loop.
Why This Matters for Senior Teams
- Framework-agnostic.The patterns are vocabulary, not vendor lock-in. Implement them in 200 lines of TypeScript against the Claude API, in LangGraph, in Mastra, or in raw orchestration code. The choice of pattern is portable; the choice of framework is not.
- Architecture review becomes possible."Is this an orchestrator-workers or a routing problem?" is a productive design conversation. "Should we use LangGraph or CrewAI?" usually isn't.
- Pairs with evals.Each pattern has known failure modes. Evaluator-optimizer needs a reliable evaluator. Routing needs a reliable classifier. Knowing the pattern tells you what to test first.
- Production case studies, not toy demos.The 2026 update covers Coinbase, Intercom, and Thomson Reuters running these patterns at scale — real systems, real volumes, real trade-offs.
Where It Fits in the Stack
Anthropic's patterns are the architecture layer. Combine with:
- Spec-Driven Developmentto write the spec, pick the pattern, then implement against both.
- Worktree tooling(Superset, Vibe Kanban) to run parallelization and orchestrator-workers patterns locally without context collisions.
- Eval skills and review skills(
sentry-code-review,webapp-testing,ai-tools) — the pattern only matters if you can verify it works.
When Not to Use It
If your "AI feature" is a single-shot summarization, classification, or extraction, you don't need any of this. Send the prompt, get the answer, ship. The patterns earn their complexity on multi-step features where the wrong architecture compounds — slow, expensive, unreliable, hard to fix. For one-call problems, just make the one call.