laranevans.com
Topics / Agentic Development / Agentic Workflows

Agentic Workflows

pillar/systems topic/agents topic/llms evolving reviewed 2026-05-20

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." Anthropic's Building Effective Agents post (December 2024) draws a useful distinction inside that spectrum:

  • Workflows are systems where LLMs and tools follow predefined code paths.
  • Agents are systems where LLMs dynamically direct their own processes and tool use.

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 of the spectrum 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 workflow patterns

Anthropic's post names five workflow patterns. Each composes LLMs and tools in a different shape.

Prompt chaining

A task decomposed into a fixed sequence of LLM calls. Each call's output feeds the next. Useful when the task has natural stages (outline → draft → polish, or extract → validate → format).

The pattern is mechanically simple. The engineering work is 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

A classifier LLM call decides which downstream handler the input goes to. Used when different kinds of input deserve different treatment. A customer support example: a "refund request" gets routed to a refund-specialized prompt with refund-specific tools, while a "technical question" gets routed to a documentation-grounded prompt.

Routing concentrates the variability in one decision point. Each downstream branch is itself simple. The trade-off is that misrouted requests fail silently. The routed branch handles the input confidently even when the routing was wrong.

Parallelization

Independent sub-tasks run concurrently. Two variants matter:

  • Sectioning. Break a task into independent pieces. Run each piece against its own LLM call. Combine the results. Useful when each piece needs its own focused context (review three diffs in parallel, or summarize three documents in parallel).
  • Voting. Run the same task several times with different prompts or models, then aggregate. Useful for high-stakes single decisions 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

A central LLM dynamically breaks down a task into sub-tasks 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 → workers → synthesis shape) but it has agent character on the inside: the orchestrator's decomposition is not predetermined. Use when the task has variable structure across instances (different code-search queries require different file inspection plans).

Evaluator-optimizer

One LLM generates an output. Another LLM evaluates it against criteria and returns feedback. The first LLM revises. The loop continues until the evaluator approves or a maximum-iteration count fires.

Useful when 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 agent loop

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

  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.

When to reach for an agent vs. a workflow

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

A few decision points worth carrying:

  • Branching count. Three or four well-understood branches: routing workflow. Many branches that depend on intermediate results: agent.
  • Tool count. A handful of tools the workflow author selects per stage: workflow. A larger toolbox where the model chooses based on the situation: 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. If a 30-second budget matters, a workflow is the safer choice.

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.