AI agent or traditional automation: which do you need?

The question nearly always arrives in the same form: we want to put an AI agent on this. Sometimes that's the right answer. More often, a fixed rule makes the process faster, cheaper and easier to explain. The difference isn't in the process itself, but in the steps it is made of.

What is the actual difference?

Traditional automation follows rules you have written down. If this, then that. It does exactly what it says, the same way every time, and afterwards you can point to why something happened.

An AI agent is given a goal and a set of tools and decides for itself which steps to take. It can handle input that differs every time, such as an email or a document. The trade-off is that it doesn't do the same thing every time.

That last point is the heart of it. You trade predictability for the ability to handle variation. That trade has to pay off.

It helps to make it concrete. A script that reads in files every night does exactly what it says. An agent that sorts incoming emails has to understand what they say before it can do anything.

When is a fixed rule enough?

When the input has a fixed format and the decision can be captured in rules. Reading in a file, copying fields across, posting an invoice from a known supplier, sending a notification on a status change.

If in doubt, try writing the rule down. If you can do it in ten lines of text, you don't need a language model. If you can't, because you keep having to add exceptions, you're in the territory where AI adds something.

When do you need language understanding?

When the input is free text, or when the format is different every time. An email in which a customer asks three things at once. A supplier's delivery note whose layout has changed. A CV with no fixed structure.

Also when the task calls for judgement within clear limits: where does this question belong, what is the core of this complaint, which of these three categories fits. Examples of such tasks are listed under AI employees.

Note the word limits. A model is good at choosing from a list you have defined, and bad at noticing that a category is missing. That list remains your job.

And what is RPA?

RPA (robotic process automation) has software mimic the actions a person takes on screen: clicking, copying, pasting. It's useful when a system has no API and there's genuinely no way around it.

It's also fragile. If a button or a screen changes, it stops working. Use it as a temporary fix, not a foundation. If there is an API, always choose that; what's involved is covered on our integrations page.

Step 1: split the task into decisions and actions

Write the process out as a series of steps. Next to each step, note whether it's a decision or an action. Actions are almost always traditional automation. Decisions are where you have to choose.

You'll usually find that a twelve-step process has two decision points. Only those two are candidates for AI. The rest is programming work you shouldn't leave to a model.

This exercise is also the best conversation you can have with the people who do the work. They know exactly which steps make them think and which they do on autopilot.

Step 2: measure how often it deviates

Take a hundred real cases from the past month and count how many fit the standard pattern. Above ninety per cent, you build rules for the ninety and leave the rest to a person.

Around sixty per cent, variation is the problem and language understanding pays for itself. That is also your baseline for later. Without it, you can't show afterwards whether it delivered anything.

Step 3: choose per step, not per process

Most solutions that work are a mix. A model reads the email and works out what is being asked, fixed rules pull the answer from the system, and a person looks at the cases that were set aside.

That way, the part that must be exactly right stays exact, and you use AI only where the variation is. How to connect such an agent to your systems is covered in connecting an AI agent to your existing systems.

What should you watch for with an agent?

• Limits: record what it may do, up to what amount, and what always goes past a person.
• Audit trail: every step traceable, so you can explain an outcome afterwards.
• Fallback route: what happens when it isn't sure, and who gets the case then?
• Cost per action: a model charges per run, so a spike in volume is also a spike in cost.

When do you deliberately choose not to use AI?

When the outcome must be one hundred per cent right without a check afterwards, when you need to justify the decision legally rule by rule, or when the volume is too small to earn anything back. Those situations are covered in when AI isn't a good idea.

If you're unsure about the trade-off in euros, use the model in calculating the business case and the indicative prices in what an AI agent costs. What's involved in building one is covered under AI agent development.