Are workflows and agents the same thing?

It is worth separating two words that get used loosely. Anthropic distinguishes workflows, where models and tools are wired together along predefined code paths, from agents, where the model dynamically directs its own process and decides how to use its tools.^[1] A workflow is a track laid down in advance. An agent lays its own track as it goes.

Anthropic’s essay names five recurring workflow patterns, each a different way of wiring fixed steps together: prompt chaining, where one call’s output feeds directly into the next; routing, which classifies a request and sends it down a matching path; parallelization, running several calls at once and combining the results; orchestrator-workers, where a lead call splits a task and hands the pieces to specialized calls; and evaluator-optimizer, where one call generates and another critiques, looping until the critique passes.^[1] All five keep the shape fixed — the model fills in content, never structure.

Take routing as a concrete case. A support system might classify an incoming ticket as billing, technical, or account-access, then hand it to a different prompt and tool-set tuned for that category, instead of asking one generalist prompt to handle all three adequately. The classification step still sits inside a fixed path — only which branch runs is decided at run time, and every branch was written in advance. That boundary is what keeps it a workflow rather than an agent: the model picks among branches someone already built, it does not invent a new one on the fly.

Most production systems are workflows, and that is usually the right call: fixed steps are cheaper to run, easier to test, and fail in ways you can predict ahead of time. Anthropic’s own advice is to reach for the simplest thing that works — a single well-prompted call before a workflow, a workflow before an agent — and add agent-style autonomy only once the task genuinely cannot be pinned to a fixed set of steps.^[1] You can read more on the workflows page.