Volume IX · Designing the Tools

Workflows, Agents, and When to Use Which

Parts One and Two of this series studied the machine and the reasoning loop running on it — the silicon, the serving stack, chain-of-thought, ReAct, memory, multi-agent coordination, and the benchmarks that measured how well any of it actually worked. Part Three starts here, and it studies something different: the scaffold engineers build around that reasoning loop to make it reliable and safe. The first question that scaffold has to answer is the most basic one — when should you even build an "agent" at all, rather than something simpler that just looks like one from the outside?

The distinction the whole field now uses

Anthropic's engineering write-up "Building Effective Agents" (anthropic.com/engineering/building-effective-agents) draws the line this lecture is built around. A workflow is defined as "systems where LLMs and tools are orchestrated through predefined code paths." An agent is defined as "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The difference is not sophistication — a workflow can call an LLM many times, use tools, and branch on their outputs, and still be a workflow, because a human decided the shape of that branching ahead of time. What makes something an agent is that the model itself is choosing the next step, not just filling in a step someone else already chose for it.

The post's central operating principle is stated directly, and is worth holding onto for the rest of this volume: "add multi-step agentic systems only when simpler solutions fall short." Three design principles support that restraint: simplicity — don't reach for more machinery than the task demands; transparency — explicitly show the agent's planning steps rather than hiding them inside an opaque loop; and a well-tested, well-documented agent-computer interface (ACI) — treating the interface between the model and its tools as a first-class design surface, not an afterthought. That third principle is the one Lecture 20 is built entirely around.

Five workflow patterns, five fit conditions

"Building Effective Agents" names five workflow patterns, and gives each one a stated condition under which it is the right choice — not a ranking, a fit test.

Prompt chaining fits a task that decomposes cleanly into a fixed sequence of subtasks — step two genuinely depends on step one's output, and the steps don't change. It trades latency (several calls instead of one) for accuracy (each call has a narrower job). Routing fits when inputs fall into distinct categories that are each better handled by a separate, specialized path — but only when the classification step itself can be made accurate; a router that misclassifies sends the task down the wrong path entirely. Parallelization — sectioning or voting — fits when subtasks can run independently for speed, or when you specifically want several independent perspectives on the same input rather than one pass. Orchestrator-workers fits complex tasks whose subtasks cannot be predicted in advance: a central LLM decomposes the task and delegates to workers dynamically, at runtime — this is the pattern behind Lecture 16's multi-agent research system. Evaluator-optimizer fits when clear evaluation criteria already exist and iterative refinement measurably improves the result — one model produces a candidate, another (or the same model in a second pass) evaluates it against the criteria, and the loop repeats until the evaluation is satisfied.

The agent-computer interface, made concrete

The third design principle — a well-tested, well-documented ACI — is not abstract advice in the original post; it comes with a worked example. A team's tool required a relative filepath, and the model kept getting confused about what the current directory actually was, producing a class of errors traceable to that one design choice. Switching the tool to require absolute filepaths instead eliminated that entire error class — not by making the model smarter, but by removing an ambiguity the tool's interface had been quietly asking the model to resolve on every call.

The post generalizes that example into concrete guidance: give the model "enough tokens to think before it writes itself into a corner" — don't force a premature commitment. Keep tool input and output formats close to what the model has already seen occurring naturally in text, rather than inventing a bespoke format it has to learn on the fly. Eliminate unnecessary string-escaping and formatting overhead that exists only to satisfy a serialization format, not the task. Invest in the ACI with the same seriousness normally reserved for human-computer interface (HCI) design. And use "poka-yoke" — mistake-proofing — design: change the tool itself so that the mistake the model keeps making becomes structurally impossible, the way the absolute-filepath fix did.

Put together, this lecture's throughline is a corrective to how "agent" gets used informally. Most production systems that call themselves agents are, by Anthropic's own definition, workflows — a fixed chain, a router, a fan-out, or a refinement loop, dressed in agent language because an LLM sits inside each step. The actual discipline is not "build the most autonomous thing you can." It is choosing the simplest pattern of the five above that fits the task, and reaching for genuine dynamic self-direction only when the subtasks truly cannot be enumerated ahead of time.