What is an AI workflow?

An AI workflow is a sequence of steps you define, where some of those steps call a language model. The path is fixed; the intelligence sits inside individual stages. That makes it the middle term between rigid automation, which can’t handle judgement, and an agent, which decides its own path — and it’s the option most teams skip past on their way to building something harder than they needed.

The three-way distinction

Worth being precise, because these get used interchangeably and they behave very differently.

Traditional automation. You define the steps; every step is deterministic code. A form submission creates a CRM record. Same input, same output, every time, for a fraction of a cent.

AI workflow. You define the steps; some steps call a model. A support email arrives, a model classifies its urgency, deterministic code routes it based on that classification. The path is yours — the judgement inside one step is the model’s.

AI agent. You define the goal and the available tools; the agent decides the steps. “Handle inbound support” might involve three actions or eleven, in an order chosen at runtime.

The axis is who chooses the path. That single question separates the three, and it’s the one to ask about any product claiming to be agentic.

What a workflow looks like

Concretely — an incoming support email:

1. Fetch the message. (code)
2. Classify: urgency, topic, sentiment. (model)
3. Look up the customer’s plan and history. (code)
4. If enterprise and urgent, page on-call. (code)
5. Draft a suggested reply from the docs. (model + retrieval)
6. Post to the queue with the draft attached. (code)

Steps 2 and 5 are things no rule could do well. Everything else is ordinary logic that would be strictly worse if a model decided it. That mix is the whole idea.

Why this is often the right answer

Three properties an agent can’t match, and they’re the properties production systems care about.

Predictability. The same input follows the same path. You can reason about what will happen, which matters enormously for anything audited or regulated.

Debuggability. When step 4 misbehaves, you look at step 4. With an agent, a wrong outcome could originate anywhere in a path that varied per run, which is why agents need tracing infrastructure that workflows largely don’t.

Cost control. A known number of model calls per run, so cost per execution is a number rather than a distribution. Agent runs on the same task can vary by an order of magnitude.

Testability. Fixed inputs, fixed path, assertable outputs — ordinary integration testing. Testing an agent is a different discipline because you’re asserting over a space of valid paths rather than one.

Where workflows run out

The limit is real and arrives predictably: every branch has to be enumerated by someone.

That’s fine at three branches. At thirty it’s a maintenance burden, and at three hundred you’ve built a rules engine that will never be complete — because the world keeps producing cases nobody wrote a branch for. Workflows also can’t handle genuinely open-ended requests. “Sort out the Henderson account” has no fixed step sequence; whatever it needs depends on what’s actually wrong.

The signal to graduate is concrete: you keep adding conditions, or the honest answer to “what are the steps?” is “it depends.”

Workflows inside agents

The distinction blurs in practice, usefully.

A well-built agent often calls workflows as tools. The agent decides that an invoice needs processing; a deterministic workflow processes it identically every time. You get agent flexibility at the decision layer and workflow reliability at the execution layer.

This is a good pattern and worth reaching for deliberately: let the agent decide what to do, and let a workflow do it. The bulk actions in our own system work this way — the agent proposes the set, a human approves, and deterministic code executes it, so the risky part is never a model’s improvisation.

How to choose

Automation when nothing requires judgement. It’s faster, cheaper and more reliable than anything with a model in it.

A workflow when the path is known but one or two steps need judgement. This is more situations than people assume, and it’s the option to try before building an agent.

An agent when the path genuinely varies, the input is open-ended, or your branch count keeps climbing.

Try them in that order. The most common architectural error in this space isn’t picking wrong — it’s skipping the middle option entirely and taking on an agent’s debugging and cost profile for a problem a fixed path would have solved.

See also: agents vs workflow automation in depth and what an AI agent is.