▲ Claude Academy
Sign in

Vault / wiki/201/agentic-patterns.md

updated 2026-05-28

Agentic Patterns

The shapes of LLM systems with tools, loops, and delegation. These come straight from Anthropic's "Building Effective Agents" guidance (raw notes) and are explicitly tested on the cert.

Workflow vs agent — the architectural distinction

From the source:

Workflows: "LLMs and tools are orchestrated through predefined code paths." Agents: "LLMs dynamically direct their own processes and tool usage."

Workflows are predictable, cheap, easy to debug. Agents are flexible but harder to reason about.

"Agentic systems often trade latency and cost for better task performance."

Use the simplest pattern that works. Don't reach for an agent when a workflow will do.

The five canonical patterns

1. Prompt chaining

Sequential LLM calls with programmatic gates between steps.

flowchart LR
    In([Input]) --> L1[LLM Call 1]
    L1 --> G1{Gate}
    G1 -- pass --> L2[LLM Call 2]
    G1 -- fail --> R[Retry / Escalate]
    L2 --> G2{Gate}
    G2 -- pass --> L3[LLM Call 3]
    L3 --> Out([Output])

Use when: steps are known and decomposable. Example: generate marketing copy → translate → format. Gate examples: schema validation, length check, tone classifier.

2. Routing

Classify input, dispatch to a specialized handler.

flowchart LR
    In([Input]) --> C[Classifier<br/>Haiku, cheap]
    C -- billing --> B[Billing handler<br/>Sonnet + billing tools]
    C -- support --> S[Support handler<br/>Sonnet + KB]
    C -- refund --> R[Refund handler<br/>Sonnet + confirm gate]
    C -- escalate --> H[Human]

Use when: there are multiple specialized handlers and a cheap classifier can separate them. Why it works: each downstream handler can have a tighter prompt, smaller tool set, cheaper model.

3. Parallelization

Run independent calls concurrently; merge results. Two flavors:

Sectioning

flowchart LR
    In([Input]) --> Split[Split into N independent chunks]
    Split --> W1[Worker 1]
    Split --> W2[Worker 2]
    Split --> W3[Worker N]
    W1 --> Agg[Aggregate]
    W2 --> Agg
    W3 --> Agg
    Agg --> Out([Output])

Voting

flowchart LR
    In([Input]) --> R1[Run 1]
    In --> R2[Run 2]
    In --> R3[Run N]
    R1 --> V{Vote / consensus}
    R2 --> V
    R3 --> V
    V --> Out([Output])

Use sectioning when: subtasks are independent (review 10 files at once). Use voting when: reliability matters and you can afford redundancy (content moderation: catch false negatives with multiple raters).

4. Orchestrator–workers

A central LLM dynamically plans and delegates. Plans are not predetermined.

flowchart TB
    User([User goal]) --> O[Orchestrator<br/>Opus / Sonnet]
    O -- plan --> O
    O -- "delegate task A" --> W1[Worker:<br/>search]
    O -- "delegate task B" --> W2[Worker:<br/>analyze]
    O -- "delegate task C" --> W3[Worker:<br/>write]
    W1 -- result --> O
    W2 -- result --> O
    W3 -- result --> O
    O -- integrated answer --> Out([Output])

From the source: "subtasks aren't pre-defined, but determined by the orchestrator based on the specific input."

Use when: the plan must be dynamic and the task decomposes naturally. Dominant pattern for non-trivial agents.

5. Evaluator–optimizer

One LLM generates; another evaluates; the generator revises.

flowchart LR
    In([Input]) --> G[Generator]
    G --> Out1[Draft]
    Out1 --> E[Evaluator]
    E -- "needs work + feedback" --> G
    E -- "good enough" --> Final([Output])

Use when: there are clear evaluation criteria (factual accuracy, style match, code correctness) and quality > speed.

Autonomous agents (when patterns blur)

Beyond workflows, agents handle open-ended problems where step counts can't be predicted. They:

  • Plan and operate independently.
  • May return to the human for more info.
  • Require ground truth from the environment at each step to assess progress.

If you can't predict the steps and you can't write deterministic gates, you're in agent territory. This is where Claude Code, Computer Use, and complex MCP-driven agents live.

Common building blocks

  • Reflection — have the model critique its own output before delivering.
  • Tool use — extend with deterministic external capabilities.
  • Self-correction loop — on validation failure, return error to the model; cap retries.
  • Provenance threading — propagate source IDs through every step.
  • Confirmation gate — before destructive actions, ask a human.
  • Iteration cap — bound any agent loop.

Three core principles (from the source)

  1. Simplicity in design.
  2. Transparency — surface planning steps.
  3. Tool documentation and testing — invest in the agent-computer interface (ACI). The SWE-bench team "spent more time optimizing our tools than the overall prompt."

Picking the pattern (decision flow)

flowchart TD
    Q1{Can you<br/>predetermine the steps?} -- yes --> Q2{Sequential or<br/>independent?}
    Q1 -- no --> Q3{Need dynamic<br/>decomposition?}
    Q2 -- sequential --> Chain[Prompt chaining]
    Q2 -- independent --> Par[Parallelization]
    Q2 -- "multiple specialized handlers" --> Route[Routing]
    Q3 -- yes --> Orch[Orchestrator-workers]
    Q3 -- "quality > speed" --> Eval[Evaluator-optimizer]

Anti-patterns

  • "Mega-agent" with 20 tools and a 5000-token system prompt — dilution kills it.
  • Skipping the gates between chain steps — silent corruption propagates.
  • Re-invoking an agent loop when the user just needs a single tool call — overhead, latency, cost.
  • Subagents with vague briefs — they wander.
  • Agents without environment feedback — they hallucinate progress.

CCA-F angle

Domain 1 is the largest at 27%. Expect questions matching scenarios to patterns:

  • "Support agent that decides whether to refund, escalate, or answer FAQ" → Routing + tools.
  • "Generate research report from 30 sources" → Orchestrator + subagents.
  • "Bulk classify 100K transactions" → Parallelization (sectioning) + Batch API + Haiku.
  • "Code review that re-reviews until clean" → Evaluator-optimizer.
  • "Translate then format" → Prompt chaining with a validation gate.

See also