Agent or workflow: when you need autonomy and when you don't

What's the actual difference between an agent and a workflow?

Let's get the definitions straight, because the word 'agent' has been stretched so far it means almost nothing now. A workflow is a sequence of steps you've decided in advance. Step one happens, then step two, then a branch based on a condition you wrote, then step three. The path is fixed. A model might do the work inside a step (extract this field, summarise this email, classify this ticket), but the model doesn't get to choose what happens next. You chose that when you built it.

An agent is different in one specific way: it decides its own next step. You give it a goal and a set of tools, and at each turn it looks at the situation, picks a tool, sees the result, and decides what to do after that. Nobody wrote the path. The model is reasoning its way through, loop after loop, until it thinks it's done. That loop, that freedom to choose the next action based on the last result, is the whole definition. Everything else is marketing.

Here's the trap. Both can call an LLM. Both can touch your CRM, send an email, query a database. From the outside they look identical. The difference is who's holding the steering wheel: your code, or the model. And that single distinction drives everything that matters: cost, reliability, how badly it fails, and how hard it is to debug at 2am when a customer is on the phone.

• Workflow: you define the path, the model fills in steps. Deterministic control flow.
• Agent: you define the goal and tools, the model defines the path. Dynamic control flow.
• Both can use AI inside them, so 'it uses AI' tells you nothing about which one you have.
• The real question is never 'is this AI?' It's 'who decides the next step, me or the model?'

Why do most 'agent' projects turn out to be workflows?

The pattern we see across nearly every discovery call is the same. A company describes something they want automated, they call it an agent because that's the word in the air, and when we map the actual process on a whiteboard it's a flowchart. A clean one. New invoice arrives, extract the fields, check them against the PO, if they match post it, if they don't route it to a human. That's not autonomy. That's an if-statement with a language model doing the reading.

The reason this happens is that 'agent' has become shorthand for 'AI that does useful work.' But useful work is mostly predictable. Onboarding a customer, processing a refund, enriching a lead, triaging support tickets, generating a weekly report. These have known steps, known branches, and known failure modes. You already know what should happen. You're not asking the system to figure out the process, you're asking it to run the process you've already figured out.

And that's good news, honestly. The flowchart version is cheaper to run, easier to test, and it fails in ways you can predict. When someone tells us they need an agent, our first move is to try to draw their problem as a flowchart. If we can, the conversation's basically over, because a workflow will beat an agent on every metric that pays the bills.

• If the steps are knowable in advance, it's a workflow even if every step uses AI.
• 'Agent' has drifted into meaning 'AI that's helpful,' which hides the real design choice.
• Predictable, repeatable business processes are workflow territory, full stop.
• Try drawing the flowchart first. If you can finish it, you've found your answer.

When do you actually need an agent?

Agents earn their keep when you genuinely cannot draw the flowchart, because the path depends on things you can only discover by doing. Think open-ended research where each finding changes what you search next. Think debugging a system where you don't know which thread to pull until you've read the last log. Think a task where the number of steps, and the order of them, is different every single time and depends on intermediate results no human could have scripted.

The honest test is this: would a smart human doing this job need to make a fresh judgment at each step, with no fixed playbook, reacting to what they just learned? If yes, that's an agent. If a competent new hire could follow a written checklist and get it right every time, that's a workflow, and dressing it up as an agent just adds cost and unpredictability for no benefit.

Even then, the best designs we ship keep the agent on a short leash. The autonomous part is usually one contained piece of a larger workflow, not the whole system. A deterministic pipeline handles the predictable 90%, and hands off to an agent only for the genuinely open-ended slice in the middle, then takes control back. You get judgment where you need it and reliability everywhere else.

• Use an agent when the path can't be known ahead of time and emerges from intermediate results.
• Use an agent when each step needs fresh judgment, not a checklist a new hire could follow.
• Open-ended research, multi-step investigation, and tasks with variable shape are real agent cases.
• Even in agent cases, isolate the autonomy to the smallest possible slice of the system.

What does autonomy actually cost you?

Autonomy isn't free, and the bill comes in three currencies: money, latency, and predictability. A workflow with three model calls costs you three model calls. An agent working the same problem might loop fifteen times, re-reading context on every turn, racking up tokens you didn't plan for. We've watched agent token bills run five to ten times what the equivalent workflow would cost, because the model keeps thinking out loud when a hard-coded branch would have just moved on.

Latency stacks the same way. Every agent loop is another round trip to the model, another few seconds. A workflow returns in the time it takes to run its steps. An agent returns whenever it decides it's finished, which might be quick or might be a minute of it talking itself in circles. For anything a user is waiting on, that variability is brutal.

Then there's the cost that doesn't show up on an invoice: you can't fully predict what an agent will do. Give it the freedom to choose its next action and it will, occasionally, choose something you never imagined. That's the same flexibility that makes it valuable, so you can't engineer it away without turning it back into a workflow. You're trading control for adaptability, and you should only make that trade when you're actually buying adaptability you need.

• Token cost: agents loop and re-read context, often 5x to 10x the cost of an equivalent workflow.
• Latency: every loop is another model round trip, so response times become variable and slow.
• Predictability: freedom to choose the next step means occasionally choosing something you didn't expect.
• You're paying for adaptability, so only pay when the problem genuinely demands it.

How do reliability and reversibility change the decision?

The more dangerous the actions a system can take, the more you should lean toward a workflow, and the harder you should think before handing the keys to an agent. There's a simple framing we use on every build: how reversible is the worst thing this system could do? Drafting an email a human approves is fully reversible. Sending it is less so. Issuing a refund, deleting records, changing a customer's plan, moving money, those are actions you can't quietly undo.

Workflows give you natural checkpoints. You decide exactly where a human approves, where the system pauses, where an action is gated behind a confirmation, because you wrote every branch. An agent, by design, strings actions together on its own, which means a small early misjudgment can compound into a sequence you'd never have approved if you'd seen it step by step.

So the rule we hold to: the lower the reversibility, the more deterministic the control flow should be. Let agents roam freely over read-only and easily-undone actions like searching, reading, drafting, and proposing. Put a hard workflow gate, or a human, in front of anything that spends money, deletes data, or touches a customer in a way you can't take back. Autonomy and irreversibility are a bad couple. Keep them apart.

• Ask of every system: how reversible is the worst action it can take?
• Reversible actions (search, read, draft) are safe for autonomy.
• Irreversible actions (payments, deletions, sends) belong behind a deterministic gate or a human.
• Workflows let you place approval checkpoints exactly where you want them; agents don't, by design.

What's the practical path from workflow to agent?

Don't start with the agent. Almost nobody should. Start with the simplest thing that could possibly work, which is usually a single model call inside a fixed pipeline, and only add complexity when the simple version actually breaks. This sounds obvious, but the gravity in this field pulls hard toward over-engineering, and we've cleaned up plenty of expensive agent builds that a fifty-line workflow would have outperformed.

The graduation path goes one stage at a time. Begin with a deterministic workflow. Instrument it so you can see precisely which steps fail and why. When you find a step where the branching has gotten so complex that you're writing endless conditions to handle every case, that specific step is your candidate for autonomy, not the whole system. Replace just that step with a small, tightly-scoped agent, give it only the tools it needs, and leave everything around it deterministic.

This keeps your blast radius tiny. If the agent misbehaves, it misbehaves inside one well-understood box with a workflow on both sides catching it. You get the adaptability exactly where the problem demanded it, and you keep the reliability, the lower cost, and the debuggability everywhere else. That's the whole game: spend autonomy like it's expensive, because it is.

• Start with the simplest thing that works, usually one model call in a fixed pipeline.
• Instrument the workflow so you can see which step fails and why.
• Graduate only the step where deterministic branching has become unmanageable, not the whole system.
• Keep the agent tightly scoped with minimal tools and workflow guardrails on either side.

A quick decision checklist before you build anything

Before you commit to either approach, run the problem through a few honest questions. The answers usually point you straight at the right architecture, and they'll save you from building an agent because it sounded impressive in a meeting. The goal isn't to avoid agents, it's to use them only where they pay for themselves.

Most teams who go through this exercise end up shipping a workflow with one small agentic component, or no agent at all. That's not a failure of ambition. That's what a well-engineered system looks like: deterministic where it can be, autonomous only where it must be, and cheap and reliable as a result.

• Can you draw the complete flowchart? If yes, build a workflow.
• Does each step need fresh judgment a checklist couldn't capture? If yes, consider an agent for that step.
• What's the worst irreversible action involved, and is it gated behind a human or a deterministic check?
• Can you afford the variable cost and latency of a reasoning loop for this use case?
• Could you ship the workflow version this week and graduate later? Usually yes, so start there.