Business process automation: from scripts to AI agents

The word "automation" in a proposal usually points to one technology and one price. In reality it is a ladder with five rungs, from a script a junior writes in an afternoon to an AI agent that reads unstructured text and decides what happens next. Each rung solves a different problem and fails in a different way. Choosing the wrong rung is the most expensive mistake in the whole effort, and it is made before a single line of code is written.

What follows is not a ranking by how modern each option is. A script is not "behind" and an agent is not "ahead" — they are tools for different jobs. The goal is to recognise which rung fits a given process, and to avoid paying for an agent where a webhook would do.

The ladder of automation

Five rungs, from the most rigid to the most flexible. Rigidity is not a flaw — the more rigid the tool, the more predictable and cheaper it is to keep running.

A hardcoded script is the cheapest and fastest option. It is good for exactly one task with a fixed input: rename files, move a report every night, send a reminder. It fails silently — when the input format shifts, the script keeps running and simply produces the wrong result while nobody is watching.

Integrations and webhooks move data between systems the moment something happens: a new order triggers an invoice, a payment triggers a shipment. They are good when both systems expose a stable API. They break when one side changes its contract without warning — the chain stops, usually at the point that is noticed last.

A rule engine, the heart of classic BPM tools, encodes decisions as a set of if-then branches. It is excellent while the rules are few and stable. The trouble starts when there are two hundred of them, they overlap, and one person leaving means nobody knows why rule 143 exists at all.

RPA — robotic process automation — clicks through the user interface in a human's place. Its one real advantage is that it needs no API: it operates on the screen of a legacy system that offers no other way in. That is also its core weakness, which deserves more.

An LLM agent is the only tool that tolerates unstructured, variable input — a customer email, a complaint, a specification. Conventional software does not help there. But the agent carries a flaw the other rungs do not: it answers just as convincingly when it is wrong as when it is right, so the error is not obvious.

RPA automates the screen, not the process

RPA is sold as "automation without integration", and that sounds like an advantage until you understand what it actually means. The robot does not understand the process — it memorises a sequence of clicks: open this screen, click the third field, type the value, press the button at the bottom right. All fine until the screen moves.

And the screen always moves. The vendor ships a new version, adds a field, changes the layout — and the robot that "worked for a year" starts writing data into the wrong cell. It reported no error, because from its point of view nothing broke: it clicked where it was told. RPA automates the shallowest layer of a process, the one that changes most often, which makes it the most fragile form of automation there is.

This does not mean RPA has no place. It has one precisely where there is no alternative: a legacy system with no API, no prospect of getting one, and work that still has to be connected somehow. There RPA is a bridge, not a destination — a stopgap until a real interface is built underneath.

Automate the decision, not the clicks

Here is the single most important rule in the field, and it separates automation that lasts from automation that falls apart in three months.

Automate the decision, not the clicks. Clicks are how a person carries out a decision today; tomorrow they will be different. The decision is what does not go out of date.

When you record twenty clicks of a salesperson processing an order, you have recorded today's interface, not the work. The work is: "check whether the customer has an outstanding debt; if not, approve the order; if so, route it to finance." That is a decision, and it does not change when the screen changes. Automate the decision and an interface change does not touch you. Automate the clicks and every change knocks you over.

This is also why API integration nearly always beats RPA over the long run: an API is a contract about a decision and a piece of data, while a screen is only its current shape. When we introduce a tool like KickOff CRM, we do not transcribe clicks from the old system — we first list which decisions are actually made and by what criteria.

Watch what people actually do first

Before you automate anything, you have to know what really happens — not what the procedure says, but what people do in practice. The two almost never match.

Process mining is the discipline that establishes this measurably: instead of asking people how they work and getting a polished version, you read the traces systems already leave — timestamps in the ERP, logs in the CRM, email history — and reconstruct the real flow. Something unexpected almost always surfaces: steps done twice, approvals nobody reviews, three different paths for the same job depending on who runs it.

This is the most commonly skipped step, because it is not impressive. Buying a tool is far easier than admitting the process has no defined flow. But automation is an amplifier: it takes what exists and runs it harder. If what exists is chaos, you get faster chaos.

What you measure

Automation without measurement is faith, not engineering. Three numbers say almost everything, and all three are captured before anything changes.

• Cycle time (cycle time) — from the moment work enters the process to the moment it leaves finished. It includes all the waiting between steps, which is usually the largest part.
• Touch time (touch time) — how many minutes someone actually spends working on the job. The gap between cycle time and touch time is pure waiting, and that is where the biggest saving hides.
• Rework rate (rework rate) — how many jobs come back for correction. If automation speeds the process up but pushes the rework rate up too, you have sped up nothing — you are just making mistakes faster, and they cost more to fix later.

The biggest trap is measuring only touch time, because that is the part a tool most easily reduces. But if a job sits in a queue for hours between two steps, cutting the work itself by a fifth changes almost nothing for the customer who is waiting. Cycle time is the number the customer feels.

A sequence that produces results, whichever rung you finally choose:

1. Map the real flow. From system traces, not the procedure. Find where work stalls and where it comes back.
2. Fix the process. Remove duplicate steps, unify the paths, define who makes which decision.
3. Measure the baseline. Cycle time, touch time and rework rate before any automation.
4. Pick the lowest rung that solves the job. If a webhook is enough, do not build an agent.
5. Measure again and compare. If cycle time did not move, the automation failed, however good the demo looked.

Where a human stays in the loop

No rung removes the human entirely, and that is not a transitional state but a permanent part of good design. The question is not whether a human stays, but where.

A human stays in three places: where the cost of an error is high and irreversible, where the input falls outside the range the tool has seen — the exception nobody predicted — and where the decision carries responsibility someone has to sign for. Well-built automation does not hide those points; it makes them visible, so the human receives exactly the cases that need them, not all of them.

When an AI agent like NG Sara handles inquiries, or when customer communication runs through Mailbook, the aim is not for the human to disappear from the process but to see only what needs their judgement. Everything else — frequent, unambiguous, verifiable — runs on its own. If you are not sure which rung fits your process, start with a conversation about the process itself, not the tool; that is usually where we begin too.