Agentic Workflow

An agentic workflow is a system where an LLM and its tools run through a control path the developer defined in advance, which is a meaningfully different thing from an agent that decides its own path as it goes. Anthropic's widely referenced "Building Effective Agents" post (December 2024) drew exactly this line: a workflow orchestrates LLM calls and tools through predefined code paths — the developer decides what happens after each step — while an agent dynamically directs its own process, deciding at runtime what to do next and when it's done. Both use the same underlying model calls; what differs is who holds the control logic, the code or the model itself.

Prompt chaining breaks one complex task into a fixed sequence of simpler LLM calls, each one validated before the next runs. Rather than asking a model to write an entire document in one pass, a chain might generate an outline, then check the outline against a rubric, then generate the full draft from the approved outline, then generate a final polish pass — each step a separate, focused LLM call whose output is validated or gated before the next step receives it. The structure is deliberately linear and deterministic: the developer's code decides there will be exactly these four steps in exactly this order, which makes the chain easy to debug (any step's output can be inspected in isolation) in a way a single sprawling prompt asking for the whole document at once cannot be.

Routing sends a request down one of several specialized paths based on a classification step, rather than handling every request with the same prompt. A customer support system might first classify an incoming message as a billing question, a technical issue, or a general inquiry, then route it to a differently-prompted — or entirely different — model tuned specifically for that category, instead of asking one generalist prompt to handle every case equally well. This matters because a prompt optimized to be good at everything is frequently worse at any one thing than a prompt built specifically for it, and routing lets a system use several narrow, well-tuned paths while still presenting one unified entry point to the user.

The orchestrator-workers pattern uses one LLM call to plan and decompose a task, then dispatches the resulting subtasks to separate worker calls that run independently. An orchestrator reads the overall task, decides it actually consists of several distinct pieces — research three different sub-topics, say — and spins up a separate LLM call for each piece, running them in parallel rather than sequentially; a final synthesis step then combines the workers' outputs into one coherent result. Frameworks like LangGraph (LangChain) formalize this as an explicit graph of nodes and edges, and Microsoft's AutoGen and CrewAI formalize similar patterns as multiple named agent roles conversing with each other — in all three cases, the decomposition into sub-tasks and the fan-out to parallel workers is still code-defined structure, even though each individual worker's reasoning within its own sub-task is model-driven.

Evaluator-optimizer loops add a second LLM call whose only job is to critique the first call's output and decide whether another pass is needed. One model generates a candidate response; a second call — sometimes the same model with a different prompt, sometimes a separate model — scores that response against specific criteria and either approves it or sends it back with feedback for another generation attempt, repeating up to some fixed maximum number of iterations. This is structurally similar to an agent's self-correction loop, but the control flow is still code-defined: the maximum iteration count, the acceptance threshold, and what happens if the loop never converges are all decided in advance by the developer, not discovered by the model deciding for itself when to stop.

The workflow-versus-agent choice is really a question of how much uncertainty the task has about its own shape. A task whose steps are known in advance — always generate an outline, then a draft, then a review — is a strong candidate for a workflow, because the predictable structure gives the developer a concrete, debuggable control path and a tighter bound on cost and failure modes than an open-ended loop would. A task whose steps genuinely can't be known until the model starts investigating — "find out why this production incident happened," where the number and nature of needed tool calls depends entirely on what the first few calls reveal — is a better fit for an agent's self-directed loop, because forcing that kind of task into a fixed predefined sequence would mean guessing a structure the task doesn't actually have.

Read agentic workflows as the half of the agent-design space where predictability was worth more than flexibility: every pattern — chaining, routing, orchestrator-workers, evaluator-optimizer — trades some of an agent's open-ended autonomy for a control path a developer can reason about, test, and bound in advance, which is exactly the tradeoff that makes workflows the more common choice in production systems even as fully autonomous agents get most of the research attention.