A team comes to us with a process they want to make intelligent. Nine times out of ten, when we map it, it turns out to be a rules problem with one genuinely ambiguous step in the middle.
That distinction is worth more than it sounds, because the two things cost very different amounts to build, take different amounts of time, and fail in completely different ways.
The test
Walk the process step by step and ask one question at each step: could a competent new hire follow a written rule to do this, or do they have to decide?
If every step has a rule, you have an automation problem.
If one or more steps require reading something ambiguous, weighing options, or interpreting intent, you have an AI step — embedded inside what is still, mostly, an automation problem.
That is the whole test, and it resolves the majority of these conversations in about twenty minutes.
What each is actually good at
Workflow automation executes a fixed sequence. Same input, same output, every time. It is cheap to run, fast to build, fully predictable, and it fails loudly — when a step breaks, it breaks in a way you can see and fix.
Its limit is that it cannot handle a case its author did not anticipate. Automation does not improvise. Feed it something outside the rules and it either stops or does something wrong with complete confidence.
AI agents make decisions. They read free text, classify ambiguous input, weigh options, and choose. They handle the long tail of cases nobody could have enumerated in advance — which is precisely what automation cannot do.
Their limit is that they are probabilistic. They are wrong sometimes, they cost real money per decision, and you cannot know they are working without measuring them. An agent needs an evaluation set, a confidence threshold, human approval on anything consequential, and monitoring. That is not overhead you can skip; it is the price of admission.
Where teams get it wrong
Reaching for an agent when a rule would do. Someone wants an AI agent to route support tickets. You look at the routing logic and it is: if the subject contains “invoice”, send to billing. That is an if-statement. Wrapping it in a language model makes it slower, more expensive, and — remarkably — less reliable, because now it can get an unambiguous case wrong.
This happens constantly, and it happens because “AI” is what got the project funded.
Reaching for automation when there is genuine judgement. The opposite error, and it is subtler. Someone builds a rules engine to classify incoming documents, and it works for the twelve document types they knew about. Then reality arrives with the thirteenth, and the fourteenth, and a scanned fax. The rules grow to two hundred conditions that nobody fully understands, and the system is now more fragile than the manual process it replaced.
When you find yourself writing the fiftieth rule to handle an exception, that is the signal. The problem was never rules-shaped.
The shape that actually works
Almost every production system we build ends up the same shape: automation everywhere, with AI at the one or two steps that need judgement.
An invoice-processing flow is a good example. The document arrives — automation. It is stored, logged, and queued — automation. Its contents are read, its fields extracted, and its type classified — this step needs AI, because invoices from four hundred suppliers do not share a layout. The extracted values are validated against the purchase order — automation. If confidence is high and the values match, it is approved — automation. If confidence is low or the values disagree, it goes to a human — automation, with the human as the escape hatch.
One AI step. Eight deterministic ones. And the AI step is the only part that needs an evaluation set, a threshold, and monitoring.
Get this shape right and the system is cheap to run, predictable where it can be, and intelligent exactly where it has to be. Get it wrong — put the model in charge of the whole flow — and you have built something expensive, slow, and impossible to reason about.
The uncomfortable version
If a process can be fully automated with rules, then automating it is the answer, and there is no AI project. That is often not what the board was told, and it is often not what someone wanted to hear.
But it is a much better outcome. Rules-based automation ships in weeks, costs almost nothing to run, works identically every time, and nobody has to evaluate it. Choosing that over an agent is not a failure to innovate. It is engineering.
The place for AI is the step where a person currently has to think — and in most businesses, there are one or two of those inside a process with a dozen steps. Find them, put the model there, put a human behind it, and automate everything else.
That is the substance of both workflow automation and AI engineering as we practise them — and the first call is usually about working out which of the two you actually need.
Tell us about the process and we will map it with you.