On about half the intro calls we take these days, the prospect asks for an AI agent. Then we ask them to walk us through the process, and the process turns out to be: when a form arrives, check three fields, look up the customer in the CRM, and send a templated email. That is not a job for an agent. It is not even a job for a model.
Over the past two years, roughly a third of the "AI projects" we have been asked to quote ended with us recommending no AI at all. A large share of the rest ended with us recommending something smaller than what was requested, and the most common downgrade is agent to workflow. This article is the reasoning we walk through on those calls, written down.
The two things people mean by "automation"
The confusion is understandable, because vendors use the same word for two different machines.
A deterministic workflow is a program. Given the same input, it produces the same output, every time. You build it with an orchestrator like n8n or Make, or with plain code: trigger, lookup, condition, action. If the invoice total exceeds a threshold, route it to a second approver. There is no probability involved, and when something goes wrong you can point at the exact step that failed. This is what our workflow automation service builds, and for most back-office processes it is the whole answer.
An AI agent is a probabilistic system. You give a model a goal, a set of tools, and some freedom to decide which steps to take in which order. Two identical inputs can legitimately produce different plans. That freedom is the selling point and the entire problem, because everything downstream of it, evaluation, review queues, cost per run, failure modes, gets harder.
Our working heuristic, from the workflows we have built: about 80% of any business process is boring deterministic steps, and about 20% is judgment. The boring 80% should be code. The judgment 20% is where a model might belong, and even then, "a model step inside a workflow with a human review queue" covers most of it. A fully autonomous agent, planning and acting across many steps without a checkpoint, covers a thin slice of real demand.
What each one costs to run
Build cost gets all the attention in sales conversations. Running cost is where the two options actually diverge, and almost nobody prices it in.
A deterministic workflow costs almost nothing to operate. It runs on a server you already pay for, or on n8n or Make's hosted tiers. The marginal cost of processing item number ten thousand is effectively zero. Behavior changes only when someone edits the flow, which means the thing you tested in March is the thing running in October.
An agent meter runs continuously. Every run burns tokens, and agent-style loops burn more of them than a single model call, because each step is another model invocation, often with tool results and the running transcript added back into the context. If the agent retrieves from your documents, every run also pays for a search round-trip and a longer prompt, and you are now maintaining a second system, a vector index that someone has to keep fresh. None of these numbers are scary on their own. As a planning assumption for a single workflow at mid-size company volume, tokens and infrastructure land at a few hundred dollars a month.
The expensive part is maintenance, and it is priced in engineer-hours, not tokens. Someone has to maintain the evaluation setup: a test set of real inputs with known-good outputs, re-run every time a prompt changes or the provider ships a model upgrade, because model upgrades change behavior without asking you. Someone has to staff the review queue for low-confidence output. Someone has to investigate when accuracy drifts, and accuracy drifts. In our AI automation engagements we hand clients the evaluation setup and a runbook precisely so this maintenance is a routine, not a rescue mission. But it is a line item, and it exists for as long as the agent runs.
The honest comparison: a workflow's running cost is a small flat number. An agent's running cost is a small flat number plus a variable number plus ongoing human attention. That attention is the part missing from most vendor quotes.
The agent we talked a client out of
A distribution company came to us last year wanting an "AI agent for supplier communication." The pitch they had heard: an agent that reads supplier emails, negotiates delivery dates, chases late shipments, and escalates problems, end to end.
We spent a discovery week mapping what their coordinators actually did. Roughly nine in ten supplier emails fell into four buckets: order confirmations to be filed, delivery-date changes within an accepted window, shipment notifications to be matched against purchase orders, and invoices. Every one of those buckets had a rule. Confirmations get filed. A date change inside the window updates the ERP; outside the window, a human decides. Shipments get matched; mismatches get flagged. Invoices go to the existing accounting flow.
The remaining emails, the genuinely odd ones, were maybe a few a week. A supplier writing in a mix of German and English to explain that a machine broke and the whole Q3 schedule was fiction. No agent handles that well either, as it happens. A senior coordinator handles it by picking up the phone.
What we built instead: a deterministic flow that parses and files the four rule-based buckets, plus one model step that reads each incoming email and assigns the bucket, because supplier emails arrive in every format and phrasing imaginable, which is exactly the kind of input variance a model is good at. Anything the model scores as low-confidence, or that fits no bucket, lands in a review queue a coordinator clears with morning coffee. The client got the outcome from the original pitch, minus the autonomy they did not need and the maintenance bill that came with it.
Where agents genuinely win
We build agent-style systems too, and some problems honestly need them. The common thread is input variance that rules cannot capture.
Free-text classification at volume is the cleanest case: reading inbound inquiries that arrive in any language or level of coherence, and deciding what they are and who should see them. Unseen document layouts are another: extracting line items from a PDF from a supplier you have never dealt with, where a template-based parser breaks on first contact. First-draft generation over unstructured source material, the narrative section of a report, a reply to a non-standard complaint, is a third. And there is a real, narrower category of multi-step work where the plan genuinely depends on what the first steps find: research-style tasks and reconciliation across systems with messy data, where each finding changes what to do next. That is where the LangChain-class frameworks, tool use, and checkpointed autonomy earn their keep, always with a review queue behind them and a test set in front of them.
The trade-off we put in writing: even in these cases, we scope the agent to a step, not a job description. "Read and classify every inbound email" is a good agent step. "Handle customer service" is how budgets die.
Four questions that settle it
When a client asks "agent or workflow," these are the questions we run through, in this order:
- Input variance: does the input arrive in unpredictable formats, phrasings, or languages? If inputs are structured or come from a fixed set of systems, a workflow wins outright. Variance is the only thing a model is strictly better at.
- Error tolerance: what happens when the system is wrong? If a mistake is annoying and reversible, a probabilistic step is acceptable. If a mistake is a wrong payment, a wrong medical detail, or anything a regulator reads, you need deterministic behavior and an audit trail, full stop.
- Volume: how often does this run? Our working heuristic from the workflows we have built: an agent's per-run cost and drift risk are tolerable at hundreds of items a week and painful at hundreds of thousands, where a workflow's near-zero marginal cost dominates the math. Model choice in the end depends on token volume, latency, error cost, and your evaluation results, not on a universal threshold.
- Auditability: will anyone need to explain, months later, exactly why the system did what it did? A workflow answers with a log and an if-statement. An agent answers with a transcript of reasoning that may or may not reflect why it actually acted.
Four answers pointing at rules means you want workflow automation and should not pay agent prices. Strong variance plus tolerable errors means a workflow with model steps inside, which is the shape of most of our AI delivery work. Our default requires all four answers to point toward autonomy, high variance, forgiving errors, moderate volume, no audit burden, before we recommend a fully autonomous agent, and we can count those projects on one hand.
Once you know which machine you are buying, the next question is sequencing: which workflow first, what to measure, and how an eight-week rollout actually runs. That is the subject of our AI implementation playbook for SMBs, which pairs with this piece.
If you have a process in mind and genuinely cannot tell which side of the line it falls on, that is a normal state of affairs and a good discovery-week question. Send it to us and we will tell you which one we would build, including when the answer is neither.
Frequently asked questions
How do we know if our process needs an AI agent or plain automation?
Write the process down step by step. If every step can be expressed as a rule ("if the invoice exceeds €10,000, route to finance"), you need workflow automation, not an agent. If some steps require reading free text, handling layouts you have never seen, or making judgment calls that resist rules, those steps justify a model. In our discovery sessions, most processes turn out to be rules with one or two judgment steps, which is a workflow with a model inside, not an autonomous agent.
What does an AI agent cost to run each month?
As a planning assumption for a single workflow at SMB volume, API tokens and the surrounding infrastructure usually land at a few hundred dollars a month. The larger cost is maintenance: someone has to keep the evaluation test set current, review low-confidence output, tune prompts when accuracy drifts, and re-validate behavior every time the model provider ships an upgrade. A deterministic workflow has none of that; its marginal cost per run is close to zero and its behavior does not change until you change the code.
Can we start with a workflow and add an agent later?
Yes, and that is the sequence we recommend. Ship the deterministic version first, measure error rate and hours saved, and let real usage show you where judgment is actually needed. If a step turns out to need open-ended reasoning over unpredictable input, you can grow that step into agent territory with the evaluation setup already in place. Starting with the agent means paying for autonomy before you know whether you need it.
Are AI agents reliable enough for customer-facing work?
Sometimes, with constraints. Customer-facing means no human reviews the output before it ships, so you need a strong evaluation setup, narrow scoping of what the agent may do, and fallback rules for anything it gets wrong. Our advice from delivery work: earn trust on internal workflows first, where a person checks the output, and move customer-facing only when the measured error rate justifies it.