Agent or Workflow? The LLM Patterns That Survive Production in 2026

Most LLM systems that work in production are workflows with a model in a few steps, not open-ended agents. The five workflow patterns, when a real agent loop earns its cost, and how to tell which one a problem needs before building either.

Anthropic's "Building effective agents" drew a line we still use: in a workflow, code decides the path and the model fills in steps; in an agent, the model decides the path. Both are useful. Agents cost more, are harder to test and fail in more interesting ways, so the question for any new feature is whether the path really needs to be decided at run time.

Five workflow patterns

When an agent earns its cost

• The number of steps genuinely cannot be known in advance: debugging, open-ended research, operating a tool you cannot script.

• There is a reliable signal of success the agent can check for itself, such as tests passing, a query returning rows or a page rendering.

• A wrong intermediate step is cheap to undo, or every side effect goes through an approval.

• Someone will read traces. An agent nobody observes degrades without anyone noticing.

Signs you built an agent where a workflow would do

• The traces show the same sequence of tool calls almost every time. Write that sequence as code.

• Most of the prompt is instructions about the order of steps.

• Costs vary ten times between similar requests because the loop sometimes wanders.

• You cannot write an evaluation because "correct" depends on the path taken.

The common production shape is a workflow with one bounded agent step inside it: code handles intake, retrieval, permissions and output formatting, and a tool-using loop with a step limit handles the one part that needs judgment. On AWS that maps cleanly to a Step Functions or durable-function workflow with an AgentCore or Lambda step.