When to build an AI agent vs. automate the workflow

A RevOps lead at a 40-person SaaS company sent us a Loom last month. Her team was three weeks into building an “AI agent” to triage support tickets. The agent was hallucinating product names, escalating refund requests to the wrong queue, and quietly costing about $180 a day in API calls. We watched the screen recording, then asked one question: can you write down every decision the agent is supposed to make? She could. On a single Post-it note. The team had built an agent for what was, in plain sight, a five-branch workflow.

This happens often enough that we now ask it before any AI engagement starts. The honest answer saves clients months. Most of what gets pitched as “agentic AI” is workflow automation with a language model bolted on. And most of what gets dismissed as “just a workflow” is actually a reasoning problem in disguise.

The short version: workflow automation wins when you can enumerate the path. AI agents win when you cannot. Everything else is detail.

The crisp distinction

Workflow automation tools, the n8n / Make / Zapier family, are deterministic. You define triggers, branches, and actions. Given the same input, you get the same output. They are fast to ship, cheap to maintain, and they fail loudly when something changes upstream. We have built hundreds of these across CRM hygiene, invoice routing, lead enrichment, and reporting.

AI agents, by contrast, are goal-directed. You give them an objective, a set of tools, and constraints. They decide which tool to call and in what order. Reasoning is the product. They shine when the input is ambiguous, the path varies per case, or the number of possible tool combinations exceeds what you would patiently draw on a whiteboard. We cover this on our autonomous agents page.

Both can use LLMs. Both can call APIs. The difference is who decides the next step: your flowchart, or the model.

Six criteria we use to choose

When a prospect describes a project, we run through these six criteria before quoting. Three or more “agent” answers and we look harder at agents. Otherwise, automation wins by default, because it is cheaper to run and easier to debug at 2 a.m.

1. Determinism of input. Are the inputs structured (form fields, webhook payloads, rows in a sheet) or unstructured (emails, PDFs, voice transcripts, screenshots)? Structured leans automation. Unstructured leans agent, or at minimum an LLM step inside a workflow.
2. Reasoning depth. Can a junior employee follow a written SOP and get the right answer 95% of the time? If yes, automation. If the task needs judgment, context-stitching across sources, or “it depends” reasoning, lean agent.
3. Tool count. How many systems does the task touch? One to four tools called in a known order is a workflow. Seven or more with variable order starts to argue for an agent that can pick.
4. Error tolerance. What happens when the system is wrong? Financial postings, legal filings, anything regulated: keep the path deterministic. Drafting an internal summary or a first-pass research memo: agents are fine.
5. Volume. At fewer than 50 runs per day, agent token costs are a rounding error. At 50,000 runs per day, a 30-cent agent invocation becomes a six-figure annual line item. High volume forces you to push reasoning out of the loop wherever you can.
6. Change frequency. If the rules shift every quarter (regulatory, pricing, product), workflows need constant edits. An agent given a current policy document can adapt without code changes. Slow-changing rules favor workflows.

The decision table

This is the cheat sheet we hand clients during scoping calls.

If you cannot describe a happy path on a napkin, you do not have a workflow problem. You have a reasoning problem. Stop fighting it with conditional logic and let the model decide.

What this looks like in practice

A fintech client came to us needing KYC document review. New customer uploads a passport, utility bill, and bank statement. The team needed to verify identity match, address consistency, and source-of-funds plausibility across three documents that arrived in twelve languages and roughly any layout you can imagine.

The first instinct was a workflow: OCR each doc, regex the fields, branch on results. We tried it. Accuracy plateaued at 71%. The path could not be enumerated; passport layouts alone vary by country and decade. We rebuilt as an agent with retrieval over the firm’s policy library, four tools (OCR, sanctions screen, address lookup, internal CRM write), and a confirm-before-write constraint. Accuracy climbed to 94% with the remaining 6% routed to humans by design. Full write-up on the fintech KYC project.

The mirror-image case: the same client’s accounts-payable team wanted an agent to “handle invoices.” We talked it through. The actual job: read an invoice PDF, match a PO, route for approval over $5,000, post to Xero. Four steps. Same every time. We shipped that as a Make scenario with an LLM extraction step in the middle. Two weeks of work, runs for under $40 a month, and the AP lead has not touched it since.

The hybrid pattern most teams should start with

The interesting reality is that most production systems are neither pure workflow nor pure agent. They are workflows with reasoning steps embedded where the path bends. We sketch them like this:

Trigger (deterministic)
   |
   v
[Extract / classify with LLM]   <-- reasoning, single-shot
   |
   v
Switch / branch (deterministic)
   |
   +--> Path A (deterministic)
   +--> Path B (deterministic)
   +--> Path C: Agent loop  <-- only here, only when needed
            |
            v
         Tool calls until goal met or budget hit
            |
            v
         Return to deterministic finalization

Putting agents inside workflows, rather than around them, gives you the best of both: predictable cost on 90% of the volume, reasoning where it actually pays. It also makes debugging tractable, because the workflow logs show you exactly which step entered the agent and what came back.

How to scope your next project

Before you write a single n8n node or pick a model, do three things. First, write the SOP a human would follow. If you cannot, the project is not ready, regardless of which tool you pick. Second, count the branches honestly. If your SOP has more than twenty leaf nodes, you are either over-specifying or you genuinely need an agent. Third, decide your per-run cost ceiling. Agents are easy to ship and easy to bankrupt you with at scale; that ceiling is the conversation that prevents the second outcome.

We also recommend timeboxing the prototype. Two weeks for a workflow. Four weeks for an agent. If you are not seeing the accuracy or coverage you need by then, the architecture is probably wrong and adding more prompt engineering will not save it.

Now what?

If you have a process you are not sure how to classify, the fastest path is to talk it through with someone who has built both. Our AI and automation team runs a 45-minute scoping call where we map your process, apply the criteria above, and tell you which side of the table you land on, even if the honest answer is “you do not need us for this.” That is the meeting worth having before you spend a quarter building the wrong thing.