Guide

When to use a Workflow

Published 14 September 2026

If you can draw the whole process as a flowchart and label every branch, you want a workflow, not an agent. The question is never how clever the system has to be. It is whether the shape of the work is known before the run starts.

The flowchart test

Actually draw it. Every box, every arrow, and the condition written on every arrow. If you reach the end and the diagram is complete, you have specified a workflow, and the rest is writing it down precisely enough to build. If you get partway through and find yourself drawing a box labelled "decide what to do next," you have an agent. That box is the model choosing at runtime, which is exactly what a workflow does not do.

Anthropic's engineering post Building Effective AI Agents, by Erik Schluntz and Barry Zhang, puts the distinction in one line: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths." Agents, in Anthropic's framing, are the systems where the model directs its own process and tool use, keeping control over how the task gets done. Predefined is the load-bearing word: in a workflow the path exists before the input arrives.

That post is often misread in two ways. Anthropic treats workflows and agents as two kinds of agentic system, a split inside one category. And its advice is a ladder, not a warning against agents: start with the simplest solution and add complexity only when it demonstrably improves outcomes. For many applications, Anthropic says, optimizing a single LLM call with retrieval and in-context examples is usually enough, which puts a workflow one rung up already.

The five patterns worth knowing by name

Anthropic names five workflow patterns: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer. Naming your build correctly is most of specifying it.

Prompt chaining. The task is decomposed into a sequence of steps, each LLM call processing the output of the previous one. Use it when the order is fixed and every step needs the last one's result.

Routing. An input is classified and directed to a specialized followup task. Use it when different kinds of input deserve genuinely different handling.

Parallelization. Several LLM calls run at once and their outputs are aggregated programmatically. Anthropic names two variations, sectioning and voting.

Orchestrator-workers. A central LLM breaks the task down, delegates the pieces to worker LLMs, and synthesizes what comes back.

Evaluator-optimizer. One call generates a response while another provides evaluation and feedback, in a loop.

Two of those deserve a flag. Anthropic's own description of orchestrator-workers has the central model breaking tasks down dynamically, which makes it the boundary case: filed as a workflow, but with the delegation decided at runtime. Evaluator-optimizer has the same problem from the other end, since a loop with no iteration ceiling does not reliably terminate. If your build is one of those two, your flowchart is not complete, and it is better to say so now than in production.

The complexity lives in the graph, not the prompt

Harrison Chase's LangChain post Not Another Workflow Builder, published October 7, 2025, makes the structural version of the same point, and his axis is workflows against agents rather than chains against agents. A workflow is complicated in its graph: branching logic, parallel edges, many different paths, all represented in some DSL. An agent's complication lives somewhere else, abstracted into natural language inside the prompt, which is why an agent's overall structure stays simple, just a prompt plus tools, even when the prompt itself is long.

That gives you a second test: look at where your complexity wants to live. If you keep trying to write the branching into prose inside a prompt and hoping the model will follow it, you have picked the wrong build type. Branches belong in a graph, where each can be read, tested and changed on its own.

Chase maps complexity to solution:

Complexity Solution
Low A no-code agent
Medium A no-code workflow
High A workflow written in code, where you want a lot of branching, parallelism and modularity

He names LangGraph for that last case, and warns that past a certain complexity a visual builder leaves you a mess of nodes and edges to manage in the UI.

He states the trade plainly, and most people have it backwards: workflows buy predictability at the expense of autonomy, agents buy autonomy at the expense of predictability, and neither one alone guarantees reliably good outcomes. Predictability is not the goal, it is what you spend autonomy to get.

The approval gate forces the third test

Ask one question. Does a person have to approve something, at a specific point, before the run continues?

If the answer is yes and you can say where the gate sits, build a workflow. An agent can be made to pause for approval, but you are then describing a checkpoint in prose and trusting the loop to respect it. In a workflow the gate is a node. Everything upstream of it is done, everything downstream is blocked, and the approval is a recorded state transition.

The gate is also what makes the run long, and that forces the third test: resumability. A human approval can take a day, so the run has to survive the wait, with state written down explicitly and a resume path that does not re-run the expensive stages. That test usually settles the matter, because once you are writing a state schema you are writing a workflow.

One warning about the word "workflow"

The term is used in two incompatible ways. IBM Think's page on agentic workflows, by Anna Gutowska and Cole Stryker, defines an agentic workflow as an AI-driven process where autonomous AI agents make decisions, take actions and coordinate tasks with minimal human intervention, and its contrast case is a rule-based support bot on static decision trees. Read against Anthropic's vocabulary, IBM's agentic workflow is much closer to what Anthropic calls an agent. Before you agree with someone that you are building a workflow, confirm which of the two they mean.

Where this fits if you use Bespoke Prompting

Bespoke Prompting's Workflow build type refuses the vague version of all three tests. Its STAGE_MAP has to be numbered and named, with an input, an output and a success predicate for every stage, and its ROUTING_LOGIC has to be the complete IF/THEN decision tree between stages, including where the human-in-the-loop gate sits: that is the flowchart, drawn. STATE_SCHEMA is a required core section too, so the state the run resumes from is written down, not assumed. WORKFLOW_IDENTITY has to state a measurable completion predicate, something on the order of complete when published_url is set and brand_check_passed is true, never "a workflow assistant." If you cannot fill those in, the flowchart was never finished, and that is the useful signal.

Sources

Suggested internal links