Key takeaways
- If the process can be written as rules, use rules — they are cheaper, faster and deterministic.
- Agents earn their cost where inputs are unstructured or the next step requires judgement.
- The hard engineering in agents is permissions, error handling and approval gates, not the model.
- Start agents read-only and grant write access one workflow at a time.
- Run in parallel with the manual process before cutting over — the disagreement rate is the real test.
The distinction that decides the project
Traditional automation follows rules you wrote. When a form is submitted, create a record; when the value exceeds a threshold, route for approval. It is deterministic, cheap to run, easy to test and it does exactly the same thing every time.
An AI agent decides what to do. Given a goal and a set of tools, it reads the situation, chooses the next step, calls the appropriate system and evaluates the result. That flexibility is genuinely useful and it is also the source of every difficulty — non-determinism means the same input can produce different paths, which changes how you test, monitor and secure it.
The practical rule: if you can write the rules, write the rules. Reach for an agent when writing the rules is the part that is impossible.
Where rules are the right answer
Structured inputs and predictable branching. Lead routing by territory, invoice approval by value threshold, stock alerts, scheduled reports, notification sequences — all of these have a finite decision tree that someone can draw on a whiteboard.
Anything where a wrong answer is expensive and an audit trail must be exact. Rules are auditable in a way that a model's reasoning is not, and in regulated processes that matters more than flexibility.
High-frequency, low-value operations. Running a language model on every one of fifty thousand daily events is an expensive way to do what a conditional statement does for free.
Where agents genuinely earn their cost
Unstructured input. Emails, PDFs, scanned documents, free-text notes and supplier invoices that arrive in forty different layouts are exactly what rules handle badly and models handle well.
Judgement calls with fuzzy boundaries. Deciding whether a support ticket is urgent, whether an order exception needs a refund or a replacement, whether a CV matches a role — these have no clean rule, and the traditional solution is a person reading each one.
Multi-step work across several systems where the path varies. Turning a request for quotation into a quotation might mean checking stock, applying customer-specific pricing, confirming lead times and generating a document — and which of those steps are needed differs each time.
Long-tail exceptions. Most processes are ninety percent rules and ten percent "it depends", and that ten percent consumes most of the human time. Automating the rules and letting an agent handle the tail is usually the highest-return split.
What makes agent projects fail
Almost never the model. The failures come from the engineering around it: an agent with broader permissions than the task requires, no gate on irreversible actions, no handling for a tool returning an error, and no log of what it actually did.
The approach that works is conservative and unglamorous. Scope tool permissions to the minimum the workflow needs. Put a human approval gate on anything that cannot be undone — payments, external messages, deletions. Test against real historical cases where you already know the correct outcome. Log every action with its inputs.
Then run it in parallel with the existing manual process and compare outputs. The disagreement rate tells you whether it is ready far better than any demo does, and it usually reveals that the process itself was less consistent than anyone believed.
How to choose a first workflow
Pick something high-frequency enough to matter, structured enough to evaluate, and low-stakes enough that an error is embarrassing rather than expensive. Support ticket triage, document extraction and lead enrichment are common good first candidates.
Avoid starting with the process that is most painful. It is usually painful because it is complex and full of exceptions, which makes it the hardest thing to automate and the worst place to learn.
Frequently asked questions
- What is the actual difference between an AI agent and a chatbot?
- A chatbot answers and stops. An agent completes a task — it reads your systems, chooses the next step, calls the right API and reports back. The difficulty is not the conversation, it is the permissions, error handling and approval gates that let it act safely.
- How do you stop an agent doing something destructive?
- Scoped tool permissions, a human approval gate on anything irreversible, sandboxed testing against historical cases, and a full audit log. Agents should start read-mostly and earn write access one workflow at a time.
- Is agentic AI more expensive to run than normal automation?
- Yes, meaningfully. Every decision step costs model inference, whereas a rule costs effectively nothing. That is precisely why the recommendation is to automate the rule-shaped part conventionally and use an agent only for the part that needs judgement.
- How do we know if it is working?
- Run it alongside the manual process and measure how often they disagree, then review the disagreements. That is a far better readiness test than a demo, and it frequently exposes inconsistency in the existing manual process too.
- Which workflow should we automate first?
- Something frequent, reasonably structured, and low-stakes — ticket triage, document extraction or lead enrichment. Do not start with your most painful process; it is painful because it is complex, which makes it the worst place to learn.
Work with us on this
We start every engagement with a written scope after a free discovery call.