AI Agent vs Workflow Which to Use: Decide in Three Questions

Most people asking ai agent vs workflow which to use have already decided they want the agent, and they are hoping someone will agree with them. I get it. “Agent” sounds like hiring someone. “Workflow” sounds like a flowchart taped to a break-room fridge. But I run a whole fleet of agents, and the parts of this operation I trust most are the boring ones: fixed steps, fixed order, the same result on Tuesday as on Saturday. The agents get the jobs nobody can draw ahead of time. Everything else is a workflow, and when I forgot that, things broke.

Here is the test I use, three tasks I would sort with it, and the places where each approach fails.

AI agent vs workflow which to use: the three questions

The definitions take two sentences. A workflow runs steps you chose in advance, in an order you chose in advance. An agent gets a goal and some tools, then picks its own next step in a loop: look, decide, act, look again. If you want the longer version, I wrote it up in AI agent vs AI workflow, explained. For deciding, three questions do the work:

1. Can you write the steps down before the task runs? Not “roughly.” Actually write them. If you can draw it as boxes and arrows, and a new employee could follow the drawing, it is a workflow. If the honest answer is “it depends on what we find,” you might need an agent.
2. Does the input arrive in a shape you can predict? A form with fixed fields is predictable. A free-text email from a stranger is not. Messy input does not mean you need an agent. It means one step needs a language model to turn the mess into something structured.
3. What does a wrong answer cost, and who catches it? A miscategorized email that sits in the wrong inbox for an hour costs little. A wrong price sent to a customer costs a lot. The more a mistake costs, the more fixed the path should be, and the more clearly you need to mark where a person checks the work before it goes out.

Most tasks get “yes, mostly, cheap” on those three, and that answer means a workflow. Some get “yes, no, cheap,” which means a workflow with one model step inside. A few get “no, no, expensive.” That is agent territory, and it is also where you need the most guardrails.

The question is never “is AI smart enough to do this?” It is “do I need AI to decide what happens next, or just to read something messy?” Those are different jobs, and only the first one needs an agent.

Task one: inquiry routing

A contact form gets a message. Somebody wants a quote, somebody is complaining, somebody is selling SEO services for the fourth time this week. The message has to reach the right person, and the sender should get an acknowledgment.

Question one: yes, the steps are fixed. Receive, classify, route, acknowledge, log. Question two: no. The message body is free text, and people describe the same need fifty different ways. Question three: cheap, mostly. A wrong route costs a delay, as long as nothing falls on the floor.

So this is a workflow with one model step. The model reads the message and returns one label from a closed list. It does not decide to email anyone, look anything up, or write a reply on its own. The workflow handles all of that based on the label. I walked through the whole path a message takes in where a website inquiry goes after you hit send. The short version is that most inquiries die in a shared inbox, and an agent would not fix that. Routing does.

The classification step looks like this. Its most important feature is the fallback:

import anthropic

client = anthropic.Anthropic()
LABELS = {"quote_request", "support", "billing", "spam", "other"}

def classify(message: str) -> str:
    resp = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=10,
        system=(
            "Classify the customer message. Reply with exactly one word from: "
            "quote_request, support, billing, spam, other."
        ),
        messages=[{"role": "user", "content": message}],
    )
    label = resp.content[0].text.strip().lower()
    # The model does not get to invent a category.
    # Anything off-list goes to the human queue, never to /dev/null.
    return label if label in LABELS else "other"

That last line is the review boundary. Whatever the model returns, the workflow only acts on labels it already knows about. If the model gets confused, the message lands in “other,” and a person reads it. Nothing gets lost and nothing goes out wrong. A small, cheap model is plenty here, because sorting into five buckets is not a reasoning problem.

Task two: quote follow-up

A quote went out. The customer hasn’t answered. You want a nudge after three days, another after seven, and then you stop. If they reply at any point, the sequence ends.

Question one: completely yes. Question two: yes. The trigger is “quote sent,” the stop condition is “reply received,” and both are events your system already records. Question three: medium. A follow-up sent to someone who already said yes looks careless, and one sent to someone who said “please stop” is worse.

This is a pure workflow. No model needed, not even for drafting, because the follow-up is a template with the customer’s name and the quote number in it. People want an agent here because “the AI could personalize each follow-up.” It could. It could also personalize one into promising a discount you never offered. The thing that loses deals in follow-up is not wording. It is timing and memory: nobody remembered to send the nudge. A workflow with a timer remembers every time. I go deeper on the timing side in automating lead follow-up.

Where this one fails is the stop condition. If the “reply received” check reads the wrong inbox, or a webhook drops, the sequence keeps going after the customer has answered. That kind of failure is silent. The workflow reports success because, from where it sits, it did its job. I have a whole piece on silent failures because that pattern cost me more than any loud crash. The fix is boring: before each send, check the stop condition again, right then, instead of trusting the state from three days earlier.

Task three: report assembly

Every Monday someone pulls numbers from three places (the CRM, the invoicing tool, a spreadsheet), pastes them into a document, writes a paragraph about what changed, and sends it to the owner.

Question one: mostly yes. The sources are fixed and so is the layout. Question two: yes for the numbers, which come from APIs in fixed shapes, and no for the paragraph, which is judgment. Question three: this is the interesting one. A wrong number in a report someone uses to make decisions is expensive, and it is quiet. Nobody double-checks a report that looks normal.

So this is a workflow that fetches and calculates everything deterministically, plus one model step that writes the summary paragraph from numbers the workflow already computed. The model never fetches and never does arithmetic. It gets a small table of verified figures and is told to describe what changed, using only those figures.

That split is the whole lesson. The tempting version is an agent with access to all three tools: “go build the weekly report.” It will build one. It might pull last month’s invoices because the date filter was ambiguous, add a column twice, and then write a confident paragraph about the made-up growth. Every step looks reasonable and the result is wrong, and the report gives you nothing to tell you so. When you keep the numbers in code and the words in the model, each kind of error stays where you can see it.

Where an agent actually earns its keep

I do run agents, so this is not a sermon against them. The fleet that writes and publishes across this operation has real agents in it: they look at what happened, decide what to do, and act. They earn it because their tasks fail question one. Nobody could write the steps for “read the replies on this post and respond to the ones worth responding to” ahead of time. The next move really does depend on what the agent just read.

Good agent tasks share three traits:

1. The path branches on information you do not have yet. Research, investigation, troubleshooting, anything where finding X changes whether you look for Y.
2. There is a clear finish line. The agent can tell when it is done, so it does not loop forever burning tokens.
3. The dangerous actions sit behind a gate. The agent can read freely, but sending, paying, deleting and publishing pass through fixed checks it cannot talk its way past.

That third trait is where agent projects live or die. An agent without guardrails and kill switches is a workflow you cannot read. Even inside my own fleet, the riskiest steps are not agentic. They are fixed rules the agents have to pass through. In practice, the best agent is usually an agent wrapped in a workflow.

Why the workflow wins most of the time

The deterministic option wins on three things owners actually care about once the novelty fades.

It costs the same every run. A workflow with one Haiku classification step costs about the same per message forever. An agent’s cost depends on how many loops it decides to take, and that number moves when the input gets weird, which is exactly when you are not watching.

It fails in a place you can name. When a workflow breaks, you know which step broke. The n8n incident where a webhook setting made Stripe retry and charge one customer repeatedly was painful, but I could find it, because it happened at one fixed step. When an agent goes wrong, you first have to reconstruct what it decided to do, and only then why.

It can be handed over. A flowchart can be explained to the next person, audited, and changed one box at a time. An agent’s behavior lives partly in a prompt and partly in whatever the model felt like that day.

None of that makes agents bad. It makes them a specialist tool. So when someone asks me ai agent vs workflow which to use, my answer is to start with the workflow. Add a model step where the input is messy. Promote a step to an agent only once you can point at the exact branch that a fixed path cannot handle. Most tasks never reach that point, and the ones that do are easier to build because the boring parts around them already work. If you want to see how much a project like that usually includes, I broke it down in what a small automation project includes.

If you want to see how I draw these lines in practice, the fleet files are the actual prompt and config files this operation runs on, including the rules that keep my agents inside their lanes. They sit behind an email gate.

And if you would rather not draw the line yourself, describe the task and we will build whichever one it turns out to be. It will probably be the workflow.