A workflow is not an agent

The word that stopped describing anything

Spend an afternoon reading product pages and "agent" will mean a rules engine, a plugin-equipped chatbot, and a system that plans its own work. The word no longer separates anything. Anthropic offers a line worth keeping: a **workflow** orchestrates models and tools through predefined code paths; an **agent** is a system where the model dynamically directs its own process and tool use. Both are "agentic systems"; only the second hands the routing to the model.

That distinction is not pedantry. It is the moment you decide who chooses the next step, and almost everything that follows — how you test it, what it costs, how you recover when it goes wrong — depends on that answer.

Who chooses the next step

Picture two systems that both summarise a folder of documents.

The first runs a fixed sequence: list the files, extract the text, ask a model to summarise each, then assemble the results. The model works inside a step, but your code decides the order, and a branch you wrote handles a file the extractor cannot read.

The second gives a model tools — list, read, summarise — and a loop. The model decides which file to open next, when a summary is good enough, and when to stop. Its route is not written down in advance; it emerges at run time.

The first is a workflow. The second is an agent. OpenAI draws the boundary in the same place: agents use a model to manage workflow execution and make decisions, recognising when a workflow is complete. A workflow is the sequence of steps itself, whether or not a model helps with any one of them.

What you trade for flexibility

Agent frameworks are sold on capability, so name what you pay. Anthropic is direct that agentic systems trade latency and cost for better task performance, that autonomy raises cost, and that errors compound across turns. A fixed path is boring in a useful way: the same input takes the same route, so worst-case time and spend can be reasoned about, and a broken step points at itself. An agent's path is only known after it has run.

That trade is worth making when a task genuinely resists a fixed path. OpenAI lists the signs: decisions needing nuanced judgement, rule sets so tangled they are hard to maintain, and heavy reliance on unstructured input. For everything else, it says a deterministic solution may suffice. Anthropic's version is a principle: find the simplest solution possible, and add complexity only when it demonstrably improves the outcome.

Write the flowchart first

The test that settles most arguments is a piece of paper. Can you draw the boxes and arrows in advance? If you can, build that shape. If you cannot, name the one undrawable step, because that is the only part that needs a model choosing.

A short ladder, simplest to most open, is usually enough:

The first five are workflows — even the fifth, because the control flow stays in your code. Reaching for the sixth when the first would do is not sophistication; it is paying an agent's unpredictability for a task you already understood.

• **One call with better context.** Many "agent" jobs are a good prompt with the right material attached.
• **A prompt chain.** Fixed steps, each its own model call, with programmatic checks between them.
• **Routing.** Classify the input and send it down one of several fixed paths.
• **Parallel work.** Run independent subtasks at once, or several attempts, then combine.
• **Orchestrator plus workers.** A model chooses which subtasks to create, but each worker's job is bounded and code assembles the results.
• **An agent loop.** Reserved for when the steps cannot be predicted, and you are prepared to trust the model's decisions turn by turn.

A worked example: the weekly report

Suppose you want a weekly summary from a list of sources you already know. The files are fixed, their order does not matter, and the output format is fixed. That is a prompt chain: fetch each source, extract the relevant lines, summarise, assemble, write a draft. The only judgement the model needs is how to phrase a summary and how to flag a source it could not read — narrow calls, not routing decisions.

Now change one fact: the sources are "whatever is relevant this week", and the number of searches depends on what each one turns up. You can no longer draw the arrows. Now an agent loop is doing real work: searching, deciding what to read next, stopping when it has enough. The lesson is not that the first design is always right, but that the design should follow from the task, not from the label.

If you do need a loop, bound it

An unbounded agent is the failure everyone eventually meets. Anthropic describes an agent as a model using tools in a loop, gaining ground truth from the environment at each step and commonly carrying stopping conditions such as a maximum number of iterations. OpenAI is concrete about exit conditions: a final-output tool is invoked, the model returns without calling a tool, an error occurs, or the maximum number of turns is reached. Alongside the loop sit guardrails that check inputs, outputs and tool arguments, and a plan for handing control back to a person.

For a small, local agent, the checklist is short:

NIST's AI Risk Management Framework adds the surrounding habit: test before deployment and regularly in operation, document what a system can and cannot do, and use independent review where it improves testing. A loop that cannot report how it ended has not been tested; it has only been run.

• Name the ways the run can end, including "it did not finish".
• Cap the turns, the wall-clock time and the total actions.
• Check tool inputs and outputs rather than trusting the model's narration.
• Pause before irreversible or outward-facing actions.
• Make the stop and its reason visible in the result.

Where this stops helping

None of this argues that workflows are good and agents are bad. Some tasks are genuinely open-ended, and for those an agent is the honest design. A workflow is not automatically safe either: it still contains model calls that can be wrong, and "deterministic" describes the control flow, not the truth of the output. Hardcoding a fragile rule set when a model call would have been clearer is its own mistake.

The durable question is narrower than the vocabulary: which decisions are yours in code, and which are the model's at run time? Answer that and the label stops mattering.

What we would do next

Take the next automation you were about to call an agent. Draw its steps on one page and mark every point where the model must choose what happens next, as opposed to producing a value for a step you already chose. If the page is a flowchart with no model-owned forks, build it as that flowchart and keep the model inside its boxes. If you cannot draw the page at all, keep the loop as small as the task allows, give it the exit conditions above, and treat the first run as a test in a sandbox — not a launch.

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. Building effective agents — Anthropic Engineering. Draws the architectural line between workflows (predefined code paths) and agents (model-directed process and tool use), recommends starting with the simplest solution, and warns that autonomy raises cost and the risk of compounding errors.
2. A practical guide to building agents — OpenAI. Defines agents as systems that use a model to manage and complete workflow execution, lists the use cases where a deterministic solution may suffice, and describes a run as a loop with explicit exit conditions and guardrails.
3. AI Risk Management Framework Core (Measure) — National Institute of Standards and Technology. States that AI systems should be tested before deployment and regularly while in operation, that risk measurements include documenting functionality and trustworthiness, and that independent review can improve testing.

More from Server Attic

• 2026-08-14

  Give your AI agent a budget

  Permissions limit what an agent may touch. A separate budget for time, steps, data and queued work limits how much it can consume before it must stop.

• 2026-09-23

  Before your automation retries, make the action idempotent

  Retries turn a brief failure into a duplicate side effect unless the action can be repeated safely. A practical checklist for stable operation identifiers, precondition checks, outcome records and bounded retries, and an honest account of what it cannot promise.

• 2026-09-04

  A web page is not permission for your AI agent

  An agent can use a page, document or message as evidence without treating instructions inside it as authority. Design that boundary before connecting powerful tools.