Part 12 — Agents: LLMs that do things
Chapter 48 introduced tools in a page. This part is the real treatment: what an agent actually is, the loop at its heart, and why most "agent" projects fail.
Chapter 50 — What "agentic" actually means (and when you don't need it)
In one sentence
An agent is an LLM in a loop that decides its own next action, using tools, until a goal is reached — as opposed to a workflow, where you decide the steps in code.
The problem
A plain LLM can only produce text. It can't look anything up, do arithmetic reliably, or change anything in the world. To be useful for real tasks it needs hands (tools) and the ability to take several steps rather than answering in one shot.
The distinction that matters most
This is the single most important idea in this Part, and it's the one most projects get wrong.
WORKFLOW AGENT
You write the steps. The MODEL picks the steps.
The LLM fills in the blanks. You give it tools and a goal.
step 1: classify the ticket "Resolve this ticket."
step 2: if billing -> look up invoice -> model decides what to do,
step 3: draft a reply calls tools, looks at results,
step 4: check tone decides again, until done
step 5: send
+ predictable, testable, cheap + handles cases you didn't anticipate
+ you can debug it + far fewer lines of code
+ costs are known in advance - unpredictable path and cost
- only handles what you planned - hard to test and debug
- can loop, waste money, or go wrong
The rule of thumb from practitioners who build these for a living: use the simplest thing that works. A single prompt beats a chain; a chain beats a workflow; a workflow beats an agent. Only reach for an agent when the task genuinely requires decisions you cannot predict in advance.
Most tasks marketed as "agentic" are workflows with an LLM in one or two steps — and they're better for it, because they're cheaper, faster, and debuggable.
The building block: an "augmented" LLM
Everything in this Part is built from one thing: an LLM with three additions.
+---------------------------+
your request --> | LLM | --> answer or tool call
| |
| can also: |
| RETRIEVE (Ch 47, RAG) | <-- read your documents
| USE TOOLS (Ch 52) | <-- act on the world
| REMEMBER (Ch 53) | <-- carry state forward
+---------------------------+
That's it. An "agent" is this, called repeatedly in a loop.
The five workflow patterns (learn these before you build an agent)
Named and popularised in Anthropic's Building Effective Agents, these cover the vast majority of real systems:
1. PROMPT CHAINING -- do it in ordered steps
[outline] -> [check it] -> [write draft] -> [polish]
Use when: the task decomposes into fixed, sequential subtasks.
2. ROUTING -- classify, then send to a specialist
+-> billing prompt
[classify] ----+-> technical prompt
+-> escalate to human
Use when: inputs fall into distinct categories needing different handling.
3. PARALLELISATION -- run several at once, then combine
[task] --+--> reviewer A --+
+--> reviewer B --+--> [merge]
+--> reviewer C --+
Use when: subtasks are independent, or you want multiple opinions/votes.
4. ORCHESTRATOR-WORKERS -- a planner splits work dynamically
[orchestrator decides the subtasks] -> [worker] [worker] [worker] -> [combine]
Use when: you can't know the subtasks in advance (e.g. "fix this bug across
however many files it touches").
5. EVALUATOR-OPTIMISER -- generate, critique, improve
[generate] -> [evaluate against criteria] -> [revise] -> repeat until good
Use when: you have clear quality criteria and iteration measurably helps
(translation, code that must pass tests).
Patterns 1–3 are pure workflows — you write the control flow. Patterns 4–5 start to be agentic — the model decides how many steps.
How to choose
Can you write down the steps? -> WORKFLOW. Stop here.
Do the steps depend on what you find? -> orchestrator-workers
Is there a clear "good enough" test? -> evaluator-optimiser
Is the task open-ended, and can you afford
an unpredictable number of steps? -> AGENT
Are the actions irreversible or expensive? -> agent + HUMAN APPROVAL (Ch 60)
Practice (15 min, no code)
For each of these, decide: single prompt, workflow (which pattern?), or agent?
Write your answers and reasoning in notes.md.
- Summarise a document.
- Translate a document and check the translation preserves meaning.
- Answer a customer question from a help centre.
- Answer a customer question, look up their order, and issue a refund if policy allows.
- "Find why the nightly build broke and fix it."
- Extract fields from 10,000 invoices.
- Tag support tickets by category and urgency.
(Answers: Appendix F.)
Now, for the one you'd solve with an agent — write down what could go wrong. That list becomes Chapter 60.
Common confusions
- "Agents are just better chatbots." No. The defining feature is the loop with tools — the ability to take an action, observe the result, and decide again.
- "I need a framework to build an agent." You don't. The loop in Chapter 51 is about 30 lines. Frameworks (LangGraph, CrewAI, the Agents SDKs) add structure and observability, but start with the raw API so you can see the prompts and understand what's happening.
- "More autonomy is better." Autonomy is a cost, not a feature. It buys flexibility and costs predictability, testability, and safety.
Check yourself
- What is the difference between a workflow and an agent?
- What are the three "augmentations" that turn an LLM into an agent's core?
- Name three of the five workflow patterns and when you'd use each.
- Why should you prefer a workflow when you can?
Further reading
- Article (essential, read it today): "Building Effective Agents" — Anthropic Engineering. Short, practical, hype-free. It is the source of the patterns above.
- Article: "Writing effective tools for AI agents" — Anthropic Engineering. The companion piece, on tool design.
- Video: search "AI agents explained" from a reputable engineering channel; prefer ones that show the raw loop rather than a framework demo.