AI agents vs automation: which one do you actually need?

The 30-second decision

If you take only one thing from this article: don't reach for an agent first. Agents are more expensive to build, harder to evaluate, and slower at runtime. Use them where they earn their keep — and use boring automation everywhere else.

What "automation" actually means

In this article we mean: deterministic code that runs in response to events. Power Automate flows. n8n workflows. Cloud Functions triggered by webhooks. Stored procedures. CRON jobs. The work is mechanical — same trigger, same steps, same output.

Automation is great when:

• The trigger is well-defined (new lead, new row, scheduled time).
• The steps are predictable (lookup, transform, write).
• The output is structured (DB write, API call, email from template).
• Errors are recoverable (retry, dead-letter, alert).

It is bad when:

• Inputs are unstructured (free-form emails, PDFs of varied layout).
• Steps require judgment (which team should this ticket go to? which template should this email use?).
• "Edge cases" actually mean "we don't know all the rules yet."

What "AI agent" means

A system that turns a goal into a sequence of tool calls. The reasoning model (Claude / GPT / Gemini) does the planning; tools do the actions; the system loops until done or escalates to a human.

For the full definition, see our What is an AI agent post.

Agents are great when:

• Inputs are unstructured. Vision LLMs extract from PDFs. Realtime models handle voice. Conversational agents work with free-form text.
• Each instance needs judgment. "Is this customer a fit?" "Does this PO match this invoice?" "Should this be routed to AE or to support?"
• Failure modes are subtle. The agent surfaces uncertainty in ways a deterministic system can't.

They are bad when:

• The work is deterministic. You're paying for an LLM to do what a switch statement would.
• Volume is too low. The build cost won't amortise.
• Stakes are high enough that you needed a deterministic system anyway (e.g. money movement without approval gates).

The decision tree

A four-question decision tree we use in discovery:

1. Is the input structured? Forms, database rows, webhook payloads with stable schemas → automation. Free-form documents, voice, email bodies → agent (or hybrid).
2. Are the rules clear? Yes → automation. No or "depends" → agent or human.
3. Does each instance need a decision a junior couldn't make from a written runbook? Yes → agent. No → automation.
4. What's the cost of getting it wrong? Low → either; tune review accordingly. High → human in the loop regardless of which you pick.

Most workflows we touch in discovery end up hybrid: automation does 80% of the work (trigger, route, write), an agent does the 20% that needs judgment (classify, extract, decide).

The most expensive mistakes

Reaching for an agent when automation would do

Common in 2025–2026. Teams hear "AI" and want it. They wrap a generic LLM around a workflow that was deterministic to begin with. Result: slower, more expensive, less reliable, harder to debug. The agent is doing what if/else would have done for free.

Fix: ask the discovery question. If a junior could follow a written rulebook, build the rulebook in code.

Reaching for automation when the workflow has judgment

The other direction. A team tries to encode "classify this email by intent" as a regex tree, or "extract the relevant fields from this contract" as field-by-field rules. They end up with 400 conditional branches that nobody understands and that breaks on every new variant.

Fix: where judgment is needed, lean on the LLM. The rest of the workflow stays deterministic.

Treating AI like a magic step

"And then we'll ask the AI to..." is not a design. Every LLM-touched step needs: a typed schema for input/output, a defined success/failure behavior, an eval set, retry/fallback logic, cost guardrails. Without these the step works in the demo and fails silently in production.

Fix: design AI steps like any other engineering component — interface, tests, observability, fallback.

Building agent infrastructure when one workflow exists

Some teams adopt LangGraph, evals frameworks, full observability stacks, vector stores, all of it — for one workflow that ships per week. Operational overhead crushes the build.

Fix: start with the simplest thing that works. Add agent infrastructure when you have agents to run on it.

Hybrid patterns that work

A few common hybrid shapes:

Automation + agent classifier

A workflow runs on every new event. The first step is an agent call: "classify this event into one of these intents." Branches afterwards are deterministic.

Use for: support ticket routing, lead categorization, email triage.

Agent + automation toolkit

An agent receives a goal and has a set of typed tools — each tool is a small automation. The agent decides which tools to call and in what order.

Use for: complex workflows where the path depends on the inputs (e.g. invoice processing with conditional PO matching, supplier verification, payment scheduling).

Automation + agent on exceptions

A deterministic automation handles 80% of cases. When something falls outside the rules, it routes to an agent for judgment.

Use for: high-volume workflows where most cases are easy and rare exceptions are expensive.

Agent + human-in-the-loop

The agent handles 90% of cases autonomously. 10% with low confidence go to a human review queue. The reviewer's decisions become training/eval data for tomorrow's agent.

Use for: document processing, content moderation, sales qualification.

Cost comparison

Real numbers from real builds, for a workflow processing ~500 items per week:

The hybrid pattern usually wins on cost and reliability. It's also the hardest to sell because "we'll mostly use automation with one agent step" doesn't sound impressive in a pitch deck.

Our default: hybrid

When we walk into a discovery, our default position is hybrid. We assume:

• The trigger and routing will be deterministic automation.
• The "happy path" of structured-input → structured-output is deterministic automation.
• One or two specific steps that require judgment will be LLM-backed agent steps.
• The post-decision write to systems of record is deterministic automation.

This usually surprises clients who expected we'd want to build everything with AI. The honest answer is the opposite — AI earns its keep on the judgment steps. Everything else is well-served by code that runs predictably for €0.01 per invocation.

The bottom line

Don't ask "do we need AI?" Ask "where in this workflow does the human apply judgment?" Build automation around that judgment step, and build an agent for the step itself.

If you have a workflow you'd like a fast take on, our AI Agents service and Workflow Automation service pages cover the build process. Or drop us a note describing what you're trying to automate — we'll come back with the shape we'd recommend, within a business day.