The 12 core ideas

Tap any concept to jump to its 5-card cluster.

• 1Workflows vs. AgentsWho decides what happens next?
• 2When to Use AgentsFind the simplest thing that works
• 3The Augmented LLMRetrieval + tools + memory
• 4Prompt ChainingAn assembly line with checks between steps
• 5RoutingClassify, then hand to a specialist
• 6ParallelizationSectioning for speed, voting for confidence
• 7Orchestrator-WorkersThe model decides the sub-tasks
• 8Evaluator-OptimizerA generator and a critic in a loop
• 9AgentsThe model runs its own loop
• 10Combining PatternsReal systems are trees
• 11Tool Engineering (ACI)Design tools like you design UIs
• 12Real ApplicationsCustomer support and coding agents

One axis: who decides the next step

“Agent” gets used for everything from a chatbot to an autonomous robot. Anthropic narrows it to one question: who decides what step happens next?

A workflow orchestrates LLMs and tools through code paths you wrote — you can read the source and predict every call. An agent is an LLM that dynamically directs its own process: you give it a goal and a toolbox, and it picks the tools, the order, and when to stop. Both are useful; most production systems combine them.

The vending machine and the personal shopper

BEFORE: A vending machine has a fixed flow: insert coin, press B4, the item drops. A personal shopper hears your goal — “a gift for my mom’s birthday” — and decides which stores, what to compare, when to call you, and when to stop.

PAIN: Most teams call both “AI agents” the moment Claude is involved, which hides the real choice. The machine is cheap, predictable and easy to debug but rigid; the shopper handles novelty for free but you can’t predict their cost, latency or path.

MAPPING: Workflows are vending machines: LLMs and tools wired by code paths you wrote. Agents are personal shoppers: LLMs that read the goal and pick their own next step, using tools in a loop.

Telling them apart

1. WorkflowYour code calls the LLM, applies rules, calls it again. The path is fixed at write time.
2. AgentThe model picks a tool, observes the result, picks the next one, and decides when it’s done. The path is decided at runtime.
3. What changesCost, debuggability, latency and reliability all shift as you move from workflow toward agent.
4. In practiceUsually both: a workflow calling an agent, or an agent using workflows as tools.

Is this a workflow or an agent?

ASK: can I write down every step
     and their order before running?

IF yes AND each run takes the same path:
  BUILD a workflow  # predictable, cheap

IF the steps depend on what the
   model discovers along the way:
  BUILD an agent  # flexible, costly

IF only one part is open-ended:
  workflow on top, agent for that part

Picking the wrong side of this line is the most common cause of failed AI projects: a 3-step workflow built as an agent costs ~10× more and runs ~5× slower.

Misconceptions

Start simple; escalate only when needed

The article’s most quoted — and most ignored — advice: find the simplest solution possible and only add complexity when needed. It adds that this “might mean not building agentic systems at all”, which is a notable thing for the company selling the model to print.

The reasoning is a trade: agentic systems exchange latency and cost for better performance on open-ended problems. Worth it for some workloads, a bad deal for others.

You don’t hire a general contractor to change a light bulb

BEFORE: A homeowner wants a bulb changed and calls a general contractor, who scopes the job, schedules a crew, and sends an invoice.

PAIN: The bulb gets changed — eventually, at many times the cost, with more to go wrong. The contractor is the right call for a kitchen remodel, not a bulb.

MAPPING: A full agent is the general contractor. For a single call, a fixed chain, or a classifier, the simpler pattern does the same job faster, cheaper and more predictably. Escalate only when the simpler one fails on your eval set.

The escalation ladder

1. One LLM callOptimise the prompt with examples and retrieval first.
2. A workflow patternChaining, routing, parallelization, orchestrator-workers or evaluator-optimizer — matched to the task’s shape.
3. A full agentOnly for open-ended tasks whose steps can’t be known in advance, in a sandbox.
4. Move up only on evidenceEscalate when the simpler pattern demonstrably fails on your evals.

Which pattern should I start with?

IF one call solves it      → just call
IF fixed sub-steps          → prompt chaining
IF distinct input types     → routing
IF independent sub-tasks    → parallelization
IF sub-tasks unknown ahead  → orchestrator-workers
IF clear quality criteria   → evaluator-optimizer
IF open-ended, steps unknown,
   sandboxed                → full agent

# the simplest pattern that works wins

Frameworks (the Claude Agent SDK, LangChain and others) make starting easy but can hide the prompts. Understand the pattern underneath either way.

Misconceptions

One building block under every pattern

Every pattern — chaining, routing, agents — is built from one repeating piece: an LLM augmented with retrieval, tools and memory. Think of it as a reasoning engine with three plug-in slots, not a chatbot.

The article points to the Model Context Protocol (MCP) as one good way to plug in third-party tools. The advice: tailor each slot to your use case, and give the model a clear, documented interface to all three.

The brilliant hire, day 1 versus day 30

BEFORE: On day one a brilliant new hire is smart and well-read, but doesn’t know your codebase, can’t open Jira, and has forgotten yesterday’s meeting.

PAIN: They give confident answers from general knowledge alone. That’s a bare LLM: no way to look things up, act on the world, or remember — the root of most failures the rest of the article prevents.

MAPPING: On day 30 the same person has the wiki (retrieval), can run scripts and update tickets (tools), and remembers the month’s decisions (memory). Same brain, plugged in, dramatically more useful.

The three slots

1. RetrievalPull the right context into the prompt at query time: vector search, SQL, documents. (M09, M10)
2. ToolsFunctions the model calls to act or fetch what it can’t produce itself. (M05–M07)
3. MemoryState across turns and sessions: history, scratchpads, notes. (M08, M11)
4. InterfaceEach slot needs a documented, easy-to-use surface the model can actually drive.

One augmented LLM call

ON user question:
  context = RETRIEVE relevant docs
  history = LOAD memory for this user
  ASK LLM(question, context, history,
          tools = [search, lookup, update])

  WHILE LLM requests a tool:
    RUN the tool, SEND the result back

  SAVE key facts to memory
  RETURN the answer

Every pattern that follows is a different way of arranging these augmented LLMs: how many, how connected, who decides.

Misconceptions

Split the task into steps, check between them

Prompt chaining decomposes a task into a sequence of LLM calls, each processing the previous one’s output. Optional programmatic gates between calls validate the intermediate result before the next call fires.

The article’s phrasing: trade a little latency for higher accuracy by making each LLM call easier. It fits when the task cuts cleanly into fixed sub-steps in a known order — outline then write, extract then summarize.

The copywriter juggling three jobs

BEFORE: You ask a copywriter to write a marketing email, translate it into French, and verify the translation — all in one breath.

PAIN: They do all three, but a fluent French speaker spots rough patches. Worse, when the French is wrong you can’t tell whether the English draft or the translation step caused it.

MAPPING: Chaining is the assembly line: write, stop, inspect; translate, stop, inspect; verify. Each call is focused, and a gate between steps can stop a bad run early.

Outline → draft → polish

1. Step 1: outlineOne call produces a short outline.
2. GateCode checks the outline (for example its length) and stops the run if it fails.
3. Step 2: draftA second call writes from the approved outline.
4. Step 3: polishA third call edits the draft. Each intermediate result can be inspected.

A three-step chain with a gate

outline = ASK LLM("Outline a post on " + topic)

IF outline has fewer than 3 points:
  STOP "outline too thin"  # gate

draft  = ASK LLM("Write the post from", outline)
polish = ASK LLM("Tighten this draft", draft)
RETURN polish

# 3 calls instead of 1, ~5s more latency;
# each step is easy and inspectable

Wrong tool when the order of steps depends on the input — that’s routing or orchestrator-workers.

Misconceptions

A cheap classifier picks the specialist

Routing classifies the input and sends it to a specialised follow-up: its own prompt, possibly its own model and tools. The classifier can be an LLM call (fuzzy categories) or a plain rule (obvious ones).

It fits when inputs fall into distinct categories a generalist prompt would underserve: support intents, document types, or query difficulty — easy ones to Haiku, hard ones to a larger model.

The payoff is twofold. Each specialist prompt stays short and sharply focused, so the model handles its narrow case well. And because the classifier is cheap, you pay for a stronger model only on the categories that genuinely need it, instead of on every request.

Triage instead of one generalist doctor

BEFORE: A general practitioner handles every complaint — broken leg, rash, chest pain — competent at all, excellent at none, always looking things up.

PAIN: One prompt that handles billing, bug reports, refunds and account deletion grows bloated, and the model’s attention is split across every case.

MAPPING: Routing is triage: a short, fast classifier dispatches each input to a focused specialist prompt. You can also pay for a stronger model only on the categories that need it.

A customer-support router

1. ClassifyA fast, cheap model (Haiku) labels the message: billing, technical or general.
2. DispatchEach label has its own specialist prompt, tone and constraints.
3. AnswerThe specialist (Sonnet) handles only its narrow case.
4. FallbackLow-confidence or unknown labels go to a fallback lane; misroutes are logged.

Classify, then dispatch

label = ASK small_model(
          "billing, technical or general?", msg)

IF label NOT IN [billing, technical, general]:
  label = general  # never trust a label blindly

prompt = SPECIALIST_PROMPT[label]
reply  = ASK larger_model(prompt, msg)
LOG (msg, label)  # tune on misroutes
RETURN reply

The cost trick: the cheap model runs on every message; the expensive one only on the work that needs it.

Misconceptions

Run LLM calls at the same time, then combine

Parallelization runs several LLM calls simultaneously and aggregates the results. Sectioning splits a task into independent sub-tasks for speed. Voting runs the same task several times and combines the answers for robustness.

Use it when speed or reliability justifies the cost: N calls cost N times one call.

The article’s examples: translate a long document by sending each chapter to its own call; check one input for toxicity, relevance and accuracy in parallel; or scan code for vulnerabilities several times and take the union of findings, because catching as many issues as possible matters more than the extra calls.

One tired proofreader versus a team

BEFORE: One proofreader reads a whole manuscript checking grammar, facts and tone at once.

PAIN: By page 80 they’re tired, mixing up passes, missing things — and for a safety check, one pass is a single point of failure.

MAPPING: Sectioning hands different chapters to different proofreaders so they finish together. Voting hands the same chapter to three and combines their findings, for coverage or consensus.

A voting-style safety check

1. Fan outThree checks run at once on one post: toxicity, off-topic, personal info.
2. Wait for allWall-clock time is roughly one call, about 3× faster than running them in turn.
3. CombineAny flag fails the post.
4. Fail closedIf a check can’t run, treat the post as flagged rather than silently approving it.

Three checks in parallel, fail closed

checks = [toxicity, off_topic, personal_info]

results = RUN IN PARALLEL:
  FOR check IN checks:
    TRY: ASK LLM(check.prompt, post)
    ON error: RETURN FLAGGED  # fail closed

IF ANY result is FLAGGED:
  REJECT post
ELSE:
  APPROVE post

Voting can combine results several ways: a majority vote, the union of every finding, or an LLM that synthesizes the answers. For a safety check, “any pass flags it” is the right rule.

Misconceptions

Decompose at runtime, then synthesize

Orchestrator-workers uses one LLM as a dispatcher: it reads the input, decides the sub-tasks, hands each to a worker LLM (in parallel where possible), and synthesizes one answer.

Unlike parallelization, the sub-tasks aren’t predefined — the orchestrator chooses them from the input. Unlike a full agent, the shape is still bounded: plan, work, synthesize, done.

In this course it appears as the supervisor-worker architecture in M14 and underlies the Agent SDK’s subagents. The certification exam favours it for four properties: one coordination point, context isolation, structured aggregation, and an auditable decision flow.

The senior editor with a vague brief

BEFORE: A senior editor gets a brief: “a comprehensive market briefing on emerging fintech in Southeast Asia.”

PAIN: They can’t predefine the chapters — three country deep-dives or seven? Routing fails because the categories aren’t known; chaining fails because the steps depend on what’s found.

MAPPING: The editor reads the brief, decides the chapters, gives each to a specialist writer, then weaves the results together. That’s the pattern: decomposition is part of the problem, done at runtime.

A multi-order status briefing

1. Plan“One update on everything we have open” becomes one task per order.
2. ValidateCode checks the plan: unknown order numbers are dropped and the fan-out is capped.
3. WorkOne small worker call per order, run together; each sees only its own order.
4. SynthesizeA final call merges the findings into one reply.

Plan, validate, work, synthesize

tasks = ASK smart_model("list sub-tasks", email)
tasks = KEEP tasks with known order ids
tasks = FIRST MAX_WORKERS of tasks  # cap fan-out

findings = RUN IN PARALLEL FOR t IN tasks:
  TRY: ASK fast_model(t, facts_for(t.order))
  ON error: "status unavailable"

reply = ASK smart_model(
          "merge using ONLY these findings",
          findings)

Context isolation: each worker sees only its own order, so prompts stay small and one order’s details can’t leak into another’s answer.

Misconceptions

Write, critique against criteria, revise

Evaluator-optimizer pairs two LLM roles in a loop. A generator produces a candidate; an evaluator — a separate prompt with a different focus — critiques it against explicit criteria; the generator revises. The loop ends when the evaluator approves or a round cap is hit.

The article’s test: use it when you can state clear evaluation criteria, and when iterating measurably improves the output — translation, code that must pass tests, documents that must meet a checklist.

It’s the wrong tool when “good” is fuzzy and subjective: the evaluator’s critiques become noise and the generator chases them without converging. The course’s related material is the critique loops in M17 and the eval-driven development in M18.

“Looks good” versus a marked-up draft

BEFORE: A novelist sends each chapter to a publisher and gets back a single “looks good” or “please revise”.

PAIN: Without specifics, every revision is a guess. Asking the same writer to “make it better” produces a different version with the same blind spots.

MAPPING: An evaluator with explicit criteria is an editor’s marked-up draft: specific problems, measured against a checklist. The generator fixes exactly those and resubmits.

An author and reviewer loop

1. GenerateThe generator writes a function (or draft).
2. EvaluateThe evaluator checks it against criteria: correctness, edge cases, naming.
3. ReviseThe generator revises using that specific critique.
4. StopWhen the evaluator approves, or after a maximum of three rounds.

Generate, grade, revise, cap

draft = ASK generator(task)

REPEAT up to 3 rounds:
  review = ASK evaluator(
             "find what is wrong, per CRITERIA",
             draft)
  IF review.approved: RETURN draft
  draft = ASK generator(task, draft,
                           review.issues)

RETURN draft, "not approved -- send to a human"

The cap matters: without it, a loop chasing fuzzy criteria burns calls without converging.

Misconceptions

Hand the whole loop to the model

A full agent is an LLM in a tool-calling loop: take the task, pick a tool, observe the result, decide the next step or stop. You provide the tools and the loop; the model decides the order and when it’s done.

It’s justified for open-ended problems whose steps can’t be known in advance — and when you can run in a sandbox with evals to catch regressions. Coding agents and computer-use agents are the article’s examples.

The bug you can’t script

BEFORE: Every workflow so far has a code-defined shape: how many calls, in what order, with what tools is decided when you write it.

PAIN: “Reproduce this bug, find the root cause, fix it, run the tests, open a PR.” You can’t pre-decide how many test runs or file edits — that depends on what the bug turns out to be.

MAPPING: An agent is the LLM running its own loop: goal plus toolbox, and it picks tools until the work is done. Path length, cost and latency are unbounded — the price of handling problems whose shape couldn’t be known.

The minimal agent loop

1. Send the goalGive the model the task and the tool definitions.
2. Run tool callsThe harness executes each tool the model requests and returns the result.
3. LoopRepeat until the model answers without calling a tool.
4. Always cap itA step limit, sandboxing, tool allowlists, human approval for irreversible actions.

A capped agent loop

messages = [goal]

REPEAT up to MAX_STEPS:
  reply = ASK model(messages, tools)
  IF reply has no tool call:
    RETURN reply  # the model decided it is done
  FOR each tool call IN reply:
    result = RUN tool # sandboxed, allowlisted
    APPEND result to messages

STOP "step limit reached"

The desktop example locks its calculator tool to numeric input — without that, a tool call becomes a remote-code-execution hole.

Misconceptions

Not one pattern — a composition

The article is explicit that these building blocks aren’t prescriptive: they’re patterns to shape and combine. Real production systems compose them rather than picking exactly one.

The useful picture is a tree: a workflow at the top, agents at the leaves where the open-ended work lives, and more workflows inside each agent. The patterns are a vocabulary for those levels, not a single choice for the whole system.

A restaurant kitchen isn’t one recipe

BEFORE: Asking whether a restaurant “uses recipes or improvises” misses how kitchens actually run.

PAIN: Treat it as one choice and you either script the chef’s specials into rigid recipes or let the line cooks improvise the house sauce every night.

MAPPING: Kitchens mix both: a fixed ticket flow (workflow) routes orders, a chef improvises the specials (agent), and the chef uses fixed recipes for the sauces (workflows as tools). Agent systems are built the same way.

Three compositions from the article

1. Router → chain or agentA top-level router sends routine requests to a cheap chain and rare open-ended ones to an agent. Most support stacks look like this.
2. Agent with workflow toolsOne of the agent’s tools is itself a prompt chain; the agent never sees that complexity.
3. Orchestrator with critic workersEach subagent runs a generator-critic loop on its draft before returning.
4. The shapeWorkflow on top, agents at the leaves, workflows inside the agents.

A typical support stack

label = ROUTE request  # workflow at the top

IF label IN [password_reset, order_status]:
  RUN a fixed chain  # cheap, predictable
ELSE:
  RUN an agent with tools:
    lookup_account
    summarize_history  # itself a chain
    issue_refund       # needs human approval
LOG which path handled it  # tune the router

The common mistake is framing it as “routing or agents?” when the honest answer is usually both, at different levels.

Misconceptions

Better tools beat better prompts

The Agent-Computer Interface (ACI) is everything the model sees of its tools: names, descriptions, parameter schemas, return formats, error messages. Anthropic coins it as the agent’s version of human-computer interaction.

The article reports that on its coding-agent work, tool design often took more effort than prompt development. The lesson: invest in the ACI as you would in a UI for people — it’s the highest-leverage fix most teams ignore.

The badly labelled control panel

BEFORE: A factory gives its operators a panel of unlabelled switches, some of which do slightly different things depending on the order you press them.

PAIN: Operators make mistakes, so management writes longer and longer instruction manuals. The mistakes continue — the problem was the panel, not the manual.

MAPPING: Tools are the agent’s control panel, and the system prompt is the manual. When an agent misbehaves, the fix is more often a clearer tool than a longer prompt.

The ACI checklist

1. Room to thinkDon’t cap output so tightly that the model skips its plan before a tool call.
2. Natural formatsJSON, markdown, plain English — not custom formats, escaping gymnastics or line counting.
3. Poka-yokeShape tools so mistakes are impossible: Anthropic’s agent kept breaking relative paths, so the tool was changed to require absolute ones.
4. Test and documentRun realistic inputs, read the tool calls, and document each tool like you would for a junior engineer.

Agent misbehaving: prompt or tool?

WHEN the agent misuses a tool:
  CHECK FIRST:
    is the tool name ambiguous?
    is a parameter confusingly named?
    is the return format unclear?
    does the error say what to do next?
  FIX the tool before the prompt

WHEN a mistake keeps recurring:
  REDESIGN so it can’t happen
  # e.g. absolute paths only

The same model on the same prompt performs dramatically better with a well-designed tool surface.

Misconceptions

Where agents actually earn their keep

The article grounds the patterns in two applications. Customer support fits because the interaction is conversational, success is measurable (was it resolved?), and pricing per resolution maps to value. Coding agents fit because solutions are verifiable by tests and the problem space is genuinely open-ended.

The common thread is a clear, automatic feedback signal: resolution outcomes for support, test results for code. Without one, you’re probably looking at a workflow problem.

A thermostat needs a thermometer

BEFORE: A heating system that adjusts itself sounds ideal: it tries something, checks, and tries again.

PAIN: Without a thermometer it has no idea whether its last change helped. It adjusts blindly, forever.

MAPPING: An agent iterating on a task is the self-adjusting heater, and the feedback signal is the thermometer. Tests and resolution outcomes are thermometers; “a person reads it and decides” is not.

What the two examples share

1. SupportRouting classifies intent; a narrow agent per lane has only that lane’s tools.
2. CodingTry a fix, run the tests, read the failures, refine — in a sandbox.
3. Human gateEven for coding agents, human review of the PR stays crucial; people decide what gets merged.
4. The testAn automatic success signal? Agent viable. None? Prefer a workflow.

Is this a good agent use case?

GOOD FIT when all hold:
  success can be checked automatically
    (tests pass, issue resolved)
  the path is genuinely open-ended
  it runs in a sandbox
  a human gates the irreversible step

POOR FIT when:
  only a person can judge "good"
  the steps are knowable up front
  mistakes are irreversible and unchecked

Free-form agents are usually overkill for support. Routing plus a narrow agent per lane is the typical shape.

Misconceptions

Test the core insight

5 questions on the module’s sharpest insights. Tap to reveal the answer.