In almost every organisation over the past few years, I have had the same conversation. It starts enthusiastically: "We want to do something with AI." A moment later, the sentence falls that betrays another problem: "RPA or dumb automation, we've been there, done that."

The question I ask then is: "Which processes exactly have been automated, and what is still being done manually?" It often turns out that a number of robots were once built, that there was a proof of concept that worked fine technically, and that it then ground to a halt.
Not because the technology failed, but because there was no clear automation strategy in place. Now, AI is being introduced to bridge that same gap, using essentially the same approach that failed the first time. But technology alone is never enough. People need to be involved and supported throughout the process, and someone needs to take clear ownership of the solution.

Why the process matters

The fact that people are sometimes sceptical about RPA doesn't just come out of thin air.
Too many bots have been built on processes that should have been cleaned up first. The business case was often weak, maintenance was largely overlooked, and the true operational burden only became tangible when the first application update broke half of the workflows. Anyone who has experienced that, associates RPA with not being robust enough. AI, on the other hand, feels new, more appealing and easier to sell in a management presentation than "we are going to scrape screens".

Yet one thing remains the same: every intelligent system eventually has to do something somewhere. A model that classifies an invoice perfectly has absolutely no value as long as that invoice does not end up in the source system. And in most organisations I speak to, that is exactly where the bottleneck lies. Legacy applications without a usable API, an ERP where the supplier won't guarantee integration, a portal of a chain partner that is only accessible via the browser. In that context, RPA is not an outdated technology, but the layer that ensures a decision is actually executed.

What helps in: RPA is predictable. Deterministic behaviour is a good property in an audit context, not a limitation. If an auditor asks why a booking was made, you don't want to explain a model, you want to show a rule.

That doesn't mean you should put robots on everything. If there is a decent API, use the API. If the process is so unstable that it changes every two months, solve that first.

Where does AI belong in the organisation?

AI deserves its place in a different part of the organisation. Namely, where there is variation and where rules have historically always broken down: unstructured documents, email traffic, free text fields, exceptions that no one can fully describe in advance. In practice, we see that the gain is rarely in fully automating a process, but in reducing the portion that a human still has to touch. Going from 100 per cent manual to 20 per cent exception handling is a greater result than most business cases dare to promise.

The flip side is that AI is not deterministic but probabilistic. You get a percentage, not a certainty. That requires choices that are often made too late: at what confidence level do you let the system proceed independently, where do you insert a human, and how do you measure whether the model in production is still doing what it did in testing. Organisations that don't think about that beforehand find out after three months that no one owns the outcomes.

Agentic AI is built on top of that, not instead of. An agent is, at its core, a coordinator: it determines which steps are needed, in what order, and calls upon underlying functions to do so. That only works if those functions are there and, above all, reliable. An agent without good tooling is an excellent handyman without tools. Precisely the RPA flows, the APIs and the integrations you have built in recent years are now becoming the instruments with which such an agent can accomplish something. Anyone who has skipped that layer will find it out soon enough.

Briefly summarised: RPA executes, AI interprets and assesses, Agentic AI orchestrates. Three roles, one landscape.

Scalability starts with the right technology for the issue

Here lies the part that is rarely mentioned in proposals and turns out to be the most decisive in projects: explaining. For us as consultants and implementation experts, the difference between these three roles is obvious. For a process owner, a controller or a team leader, it is not. They hear three terms that are used interchangeably in the market and draw a logical conclusion: the newest must be the best.

A good implementation partner doesn't just build, but ensures that the organisation itself can assess when which technology fits. That is not a kick-off presentation and not a one-off workshop. It is, however: the same story, in the same words, repeated in steering groups, intakes and demos until everyone shares the same mindset. It is the difference between a client who can defend a choice and a client who has to explain every quarter why there is no AI in production yet.

The conclusion in my view is simple, even if the execution is not. Stop asking: do we do RPA or AI? That is the wrong question. Ask per process: which part is rule-based, which part requires interpretation, and which part requires orchestration over multiple steps? Then you don't build a collection of loose solutions, but a layered architecture in which each technology does what it is good at, and in which the next development just fits in instead of you having to start over.

Ultimately, that is what scalability means. Not more robots or more models, but less rebuilding.

For questions about this article, you can contact Jeroen via: info@mvrdw.nl