AI Agent or Automation? A Practical Decision Framework
Not every workflow needs an AI agent. Here is a clear framework for choosing between deterministic automation and agentic AI.
"Should this be an AI agent?" has become one of the most common questions we hear when scoping new builds. The honest answer is usually no. Most workflow problems are solved better, faster and more cheaply by deterministic automation. Agents earn their place only in a specific, narrower set of cases.
Start with the nature of the decision
The single most useful question is this: does the task require judgement under ambiguity, or does it follow a fixed set of rules? If the steps and outcomes can be fully specified in advance, you want automation. If the task requires interpreting unstructured input and choosing between genuinely different paths, an agent is worth considering.
Automation: predictable, auditable, cheap to run
Automation executes a defined sequence: trigger, condition, action. It is deterministic, meaning the same input always produces the same output. That makes it easy to test, easy to audit and cheap to operate at scale, since it does not call a language model on every execution.
Agents: flexible, but harder to control
An AI agent reasons over unstructured information, decides which tools to call, and can handle cases nobody explicitly programmed for. That flexibility is valuable when inputs vary widely, free-text customer emails, inconsistent supplier documents, ad-hoc research tasks, but it comes with less predictability and a higher cost per execution.
The decision framework
We use four questions to route a workflow towards automation or an agent.
1. Is the input structured or free-form?
Structured input (a form field, a status change, a fixed file format) points to automation. Free-form input (an email, a scanned document, a phone transcript) points towards an agent, or at minimum an AI extraction step feeding into automation.
2. How many distinct paths does the task actually have?
If you can draw the decision tree on one page, automation covers it. If the number of realistic paths is effectively unbounded, an agent's ability to reason case-by-case becomes worth the cost.
3. What is the cost of an error?
High-stakes actions, issuing refunds, sending contracts, modifying financial records, should sit behind deterministic checks and human approval gates, even if an agent is involved upstream in gathering information.
4. How often does the task run?
High-volume, low-variance tasks favour automation on cost grounds alone, since every agent call carries a marginal cost that automation does not.
- Structured input, few paths, low error cost, high volume: automation
- Free-form input, many paths, moderate error cost: agent with guardrails
- Free-form input, high error cost: agent for drafting, human for approval
- Structured input but high error cost: automation with mandatory sign-off step
The hybrid pattern we build most often
In practice, most effective systems are hybrids: an agent handles interpretation and drafting, while deterministic automation handles execution, logging and approval routing. This keeps the unpredictable part of the system small and contained, while the parts that touch money, records or customer commitments stay fully auditable.
An example pattern
A supplier invoice arrives as an unstructured PDF. An agent extracts line items and flags discrepancies against the purchase order. Deterministic automation then routes the result: auto-approve if within tolerance, escalate to a human if not. Neither piece alone solves the problem well; together they do.
Common mistakes to avoid
The most expensive mistake is defaulting to an agent because it is the more exciting option. Agents introduce variability, latency and cost that automation does not, so using one where automation would do simply adds risk without adding value. The opposite mistake, forcing genuinely ambiguous, unstructured work through rigid automation, produces brittle systems full of exceptions and manual overrides.
Where to start
Map your workflow's actual paths and inputs before choosing a technology. The right architecture is usually obvious once the decision tree is on paper, and getting it right up front avoids rebuilding the workflow twice.