Agent or Workflow? Ask Before You Build

Everyone's racing to build an AI agent. Half of them should be building something simpler, and cheaper. Before you wire up an LLM that decides its own next step, ask one question: does this task ever actually change? If the answer is no, you don't need an agent — you need a workflow with an AI step inside it.

The one question that decides everything

The line between a workflow and an agent comes down to how the steps get chosen. In a workflow, the steps are fixed in advance: step one, step two, step three, every time, in the same order. The output structure is predetermined. A script — or a simple automation tool — can run the whole thing without any model deciding what happens next.

An agent is different. It's an LLM that dynamically decides which tools or steps to use, in what order, based on what it encounters along the way. That flexibility is exactly what makes agents useful for messy, open-ended problems — and exactly what makes them the wrong tool for anything predictable.

So ask: is this process deterministic, or nondeterministic? That single question tells you which one to build.

A concrete example

Take a common sales-ops task: a new lead comes in, you research it, you draft an outreach email, you send it. Same four steps, every single time, regardless of which lead shows up. That's not agent territory — that's a workflow with an AI step inside it (the research and drafting can absolutely use an LLM call; the orchestration around it doesn't need to).

Compare that to a customer support inbox, where every incoming message is different: some need a refund lookup, some need escalation, some need a completely different tool chain depending on what the customer actually said. That's the kind of unpredictable, branching problem an agent is built for.

How to decide, step by step

1. Write down the steps your task actually takes, from trigger to output. If you can write them down in order and they don't change based on the input, you have a workflow.
2. Check whether the number of steps is fixed. A workflow might have a conditional branch or two (if X then Y), but an agent can add, skip, or reorder steps entirely based on what it finds mid-task.
3. If it's predictable, wire a workflow — a linear pipeline, with an LLM call for the part that genuinely requires judgment (drafting text, classifying an item), and deterministic code for everything else.
4. If it's unpredictable, build an agent — give it a system prompt, a set of tools, and let it decide for itself which ones to call and when.
5. Re-check periodically. A task that looks unpredictable at first (e.g. "handle support tickets") often decomposes into a handful of predictable sub-workflows behind an agent that only makes the initial routing decision.

Why the "cheaper" option usually wins

Workflows beat agents on four fronts when the task is genuinely fixed: reliability, cost, debuggability, and scale.

• Reliability — a workflow does the same thing every time; there's no risk of the model deciding to skip a step or call a tool in a strange order.
• Cost — every agent decision is an LLM call (sometimes several, for planning and tool selection). A workflow only spends tokens where you've explicitly put an AI step.
• Debugging — when a workflow breaks, you know exactly which step failed, because the steps are fixed and logged in order. An agent's failure can be anywhere in an open-ended decision chain.
• Scale — a workflow's cost and latency are predictable and linear. An agent's aren't, because the number of steps (and LLM calls) it takes can vary run to run.

None of this means agents are bad — it means they're the right tool for a specific kind of problem: messy, branching, judgment-heavy work like open-ended research or triaging support tickets with real decision points.

Pitfalls

• Don't build an agent because it feels more impressive. An agent that reimplements a four-step, always-the-same-order process is strictly worse than a workflow on cost, latency, and reliability — with none of the upside.
• Don't force a genuinely branching problem into a rigid workflow either. If you find yourself writing a wall of nested if/else conditions to cover every case, that's often a sign the task actually needs a model making the branching decision — i.e., an agent.
• Revisit the classification as the task evolves. A workflow that starts simple can accumulate edge cases until it's quietly become "an agent's job" in disguise.

Resources

• Anthropic — Building Effective Agents (workflows vs. agents)
• LangChain — Agent concepts and when to use them