Lesson16 min

The Augmented LLM & Workflows vs Agents

The building block (LLM + tools + retrieval + memory), the workflow-agent spectrum, and the start-simple rule: only add autonomy when the task demands it.

The atom: the augmented LLM

Every pattern in this module is built from one repeating unit: the augmented LLM — a language model enhanced with three capabilities:

  • Retrieval: it can pull in relevant information (search results, documents, database rows) instead of relying only on what's in its prompt.
  • Tools: it can call functions — run a search, execute code, hit an API — and read the results.
  • Memory: it can persist information across steps — notes, files, saved state.

The important nuance: the model actively drives these augmentations. It generates its own search queries, chooses which tool to call, decides what's worth remembering. It isn't a pipeline stage receiving inputs; it's a decision-maker with resources. Anthropic's guidance is to tailor these augmentations to your use case and give each a clear, well-documented interface — MCP (Model Context Protocol, the open standard for connecting models to external systems) being one standard way.

Hold this picture: one node with three satellite connections. Every diagram in the rest of this module is this atom, wired into different shapes.

Workflows vs agents: who decides the path?

Anthropic's taxonomy draws one line through all agentic systems:

  • Workflows orchestrate LLMs and tools through predefined code paths. You wrote the flowchart; the model fills in the boxes. Prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — the patterns animated in the coming lessons — are all workflows.
  • Agents dynamically direct their own processes and tool usage. The model decides what to do next, based on what the environment tells it. No human wrote the flowchart, because nobody could — the path depends on what each step reveals.

It's a spectrum, not a binary: a workflow whose orchestrator decides how many workers to spawn has a little agency; an agent with hard checkpoints has a little structure. But "who decides the path — my code or the model?" is the question that locates any system on the map.

The start-simple rule

The most quoted advice in the field: find the simplest solution possible, and only increase complexity when it demonstrably improves outcomes.

Concretely, the ladder looks like this:

  1. A single augmented LLM call, with good retrieval and examples.
  2. A workflow — if the task has structure a fixed path can exploit.
  3. An agent — only if the task is genuinely open-ended.

Many problems that get pitched as "we need an agent" are solved at rung 1. A customer-service system shipped as routing plus a few specialized prompts — instead of a free-roaming agent — was cheaper, debuggable, and its classification step could be tested in isolation. Every rung you climb costs latency, money, and debuggability; the task has to pay for the climb. Success isn't building the most sophisticated system — it's building the right system for your needs.

The costs are measurable. In Anthropic's production data, a single agent uses roughly 4x the tokens of a chat interaction, and multi-agent systems around 15x. And token usage alone explains about 80% of performance variance on research evals — capability is bought with tokens. Autonomy is never free; the only question is whether it buys something the task needs.

When an agent is the right call

Agents suit open-ended problems where you can't predict the number of steps and can't hardcode a path. Which files a bug fix touches depends on the bug; which searches a research question needs depends on what early searches reveal. An agent is, in Anthropic's words, "just LLMs using tools based on environmental feedback in a loop" — sophisticated behavior, simple implementation.

The load-bearing phrase is environmental feedback. At every step, the agent needs ground truth from the environment — a test result, a command's output, a page's content — to correct course. An agent without feedback is compounding guesses; an agent with feedback is running a controlled loop. This is why agents pair with sandboxes, checkpoints, and stopping conditions (task complete, or a maximum iteration count): trust in model decision-making is bounded by the guardrails around it.

Three principles for whatever you build

Anthropic's agent guide distills its advice to three principles:

  1. Maintain simplicity in your design. Complexity must earn its place.
  2. Prioritize transparency — explicitly show planning steps. A system whose reasoning is visible can be debugged and trusted; a black box can be neither.
  3. Craft the agent-computer interface (ACI) — the tools your agent uses deserve the same design care as a human user interface: thorough documentation, clear parameters, and real testing.

The third gets underrated. During Anthropic's SWE-bench work, the team spent more time optimizing tools than the overall prompt. One example: requiring absolute filepaths in tool arguments — instead of letting the model use relative paths that broke when the working directory changed — eliminated an entire class of errors. This is mistake-proofing (poka-yoke): design the tool so the error can't be expressed, rather than hoping the model avoids it.

Reading the pattern map

The next six lessons animate each pattern. Here's the selection logic to carry with you:

Task shapePattern
Fixed, known subtasks in sequencePrompt chaining
Distinct input categories handled differentlyRouting
Independent subtasks, or need for diverse takesParallelization (sectioning / voting)
Subtasks unknowable until the input arrivesOrchestrator-workers
Clear criteria + iteration measurably helpsEvaluator-optimizer
Open-ended, unpredictable step countAutonomous agent

These are composable building blocks, not rigid prescriptions — real systems combine them (route first, then fan out; agent loop with an evaluator inside). The discipline is measuring whether each added layer pays for itself, and deleting it when it doesn't.