Agentic Workflows

Agentic workflows are the patterns that compose language models with tools, control flow, and other models. The term covers a spectrum from "an LLM call in a script" through to "a fully autonomous agent in a loop." One decision generates that whole spectrum: does the code path decide the sequence of LLM calls, or does the model decide it? Anthropic's Building Effective Agents post (December 2024) names the two ends of that decision.

The distinction is not a moral one. Workflows are often the right answer. They are easier to debug, cheaper to run, and more predictable in production. Anthropic recommends starting with the simplest workflow that fits the task and only reaching for an agent when the task's branching structure cannot be enumerated up front.

Simon Willison's working definition captures the agent end tightly: "An LLM agent runs tools in a loop to achieve a goal." The loop is the differentiator. A workflow has a finite number of LLM calls baked into its code path. An agent decides how many calls to make.

The five workflow patterns and their shapes

Anthropic's post names five workflow patterns. Each composes LLMs and tools in a different shape, and each keeps the call sequence on the author's side of the line.

flowchart LR
    subgraph chaining[Prompt chaining]
        direction LR
        c1[LLM] --> c2[LLM] --> c3[LLM]
    end
    subgraph routing[Routing]
        direction LR
        r0[Classifier] --> rA[Handler A]
        r0 --> rB[Handler B]
        r0 --> rC[Handler C]
    end
    subgraph parallel[Parallelization]
        direction LR
        p0[Split] --> pA[LLM]
        p0 --> pB[LLM]
        p0 --> pC[LLM]
        pA --> pAgg[Aggregate]
        pB --> pAgg
        pC --> pAgg
    end
    subgraph orch[Orchestrator-workers]
        direction LR
        o0[Orchestrator] --> oA[Worker]
        o0 --> oB[Worker]
        oA --> oS[Synthesize]
        oB --> oS
    end
    subgraph eval[Evaluator-optimizer]
        direction LR
        e1[Generate] --> e2[Evaluate]
        e2 -->|revise| e1
        e2 -->|approve| e3[Done]
    end

Prompt chaining

Prompt chaining decomposes a task into a fixed sequence of LLM calls. Each call's output feeds the next. It fits a task with natural stages (outline, then draft, then polish, or extract, then validate, then format).

The pattern is mechanically simple. The engineering work sits in the prompts and the validation between stages. A failed stage either retries, falls back, or surfaces the error to the user. The chain itself does not branch.

Routing

Routing sends the input through a classifier LLM call that decides which downstream handler receives it. It fits inputs that deserve different treatment by kind. In a customer support example, a "refund request" goes to a refund-specialized prompt with refund-specific tools, while a "technical question" goes to a documentation-grounded prompt.

Routing concentrates the variability in one decision point. Each downstream branch stays simple on its own. The trade-off is that a misrouted request fails silently. The routed branch handles the input confidently even when the routing was wrong.

Parallelization

Parallelization runs independent sub-tasks concurrently. Two variants matter.

• Sectioning breaks a task into independent pieces, runs each piece against its own LLM call, and combines the results. It fits work where each piece needs its own focused context (review three diffs in parallel, or summarize three documents in parallel).
• Voting runs the same task several times with different prompts or models, then aggregates. It fits a high-stakes single decision where one call's confidence is not enough.

Parallelization reduces latency and sometimes improves quality. It increases cost linearly with the parallel factor.

Orchestrator-workers

Orchestrator-workers uses a central LLM that breaks a task into sub-tasks at runtime and delegates each one to a worker LLM. The orchestrator decides the decomposition. The workers execute their assigned slice. The orchestrator synthesizes the results.

This pattern looks like a workflow from the outside (a fixed orchestrator, then workers, then synthesis) and has agent character on the inside. The orchestrator's decomposition is not predetermined. It fits work whose structure varies across instances (different code-search queries require different file inspection plans).

Evaluator-optimizer

Evaluator-optimizer pairs one LLM that generates an output with a second LLM that evaluates it against criteria and returns feedback. The first LLM revises. The loop continues until the evaluator approves or a maximum-iteration count fires.

It fits work where the evaluation criteria are clearer than the generation strategy. Translation quality, code-style conformance, and refusal-policy compliance all fit this shape. The evaluator's prompt matters as much as the generator's. A weak evaluator approves weak output.

The patterns at a glance

The five patterns share the fixed-path property and differ on what shape the calls take and what each one buys.

The agent loop

When the five workflow patterns are not enough, the next step is an agent. The shape is a loop:

1. The model receives a goal and a set of tools.
2. The model reasons about the goal and emits a tool call.
3. The harness executes the tool and returns the result.
4. The model reads the result and either emits the next tool call or signals completion.
5. The loop continues until the model signals completion, an iteration cap fires, or the harness intervenes.

The agent's autonomy lives in step 2. The model decides what to do next based on what it has seen, not on a code path the author wrote. See Tool Calling for the message-shape mechanic underneath the loop.

The harness owns everything else. Iteration limits, retry policy, cost caps, safety boundaries, observability, and the tool implementations themselves all sit on the harness side of the line. A poorly-bounded harness around a capable model is a common and underestimated production failure mode for agentic systems. See Agentic Systems.

Choosing between an agent and a workflow

Anthropic's heuristic is conservative: prefer a workflow when the task's structure is known up front, and prefer an agent when the structure is task-specific and cannot be enumerated. Four axes carry that choice.

• Branching count. Three or four well-understood branches point to a routing workflow. Many branches that depend on intermediate results point to an agent.
• Tool count. A handful of tools the author selects per stage point to a workflow. A larger toolbox where the model chooses based on the situation points to an agent.
• Failure cost. High-stakes single-shot tasks (legal contracts, financial transactions) benefit from the predictability of a workflow. Exploratory tasks (debugging, research, code refactoring) benefit from the flexibility of an agent.
• Latency tolerance. Workflows finish in a known number of calls. Agents finish in an unknown number. A 30-second budget points to a workflow.

The patterns also compose. A real production system often uses prompt chaining at the outer layer, routing to specialized agents in the middle, and orchestrator-worker decomposition inside each agent. The patterns are a vocabulary, not a menu of mutually-exclusive options.

Related

• Agentic Systems is the production deployment view of workflows and agents.
• Context Engineering is the broader practice these patterns sit inside.
• Tool Calling is the message-shape underneath the agent loop.
• Model Context Protocol is the protocol exposing tools to multi-host workflows.