What RPA left unfinished

If you got burned by RPA, by an AI pilot or by both, it is easy to reach a harsh conclusion about yourself: you moved too early, you picked the wrong tool, you should have waited. Let go of that idea. Each of those bets was reasonable at the moment you made it. What happened is a pattern, and it is still running.

Automation has come in three waves. Each one solved the problem the previous one left behind and brought a new one. The technology improved. The organizational work around it barely moved.

Your last two attempts did not stall for lack of conviction. They stalled because you bought each wave as if it were the destination, when each one solved a technical problem and left an operational bottleneck behind. Once you see the pattern, you stop paying twice for the same lesson.

First wave, RPA: it ended the repetition and broke on the unexpected

RPA solved a real problem. People were spending hours on the same clicks, copying the same fields from one system to another, and RPA recorded those clicks. On clean, orderly, stable tasks, it worked. But it followed fixed rules step by step, so it broke as soon as a screen changed, a field moved or a document arrived in a format it didn't know.

It automated the easy part and left the hard part where it was: that messy majority of the work where the real complexity lives. According to Forrester and Gartner, between 30% and 50% of large companies' RPA automations go inactive before they turn 18 months old. That is the ceiling of what fixed rules can do, and hitting it was not a lack of nerve.

Second wave, public agents: the rigidity was gone, and so was control

Then the frontier models arrived, and overnight software could read messy documents, reason through ambiguity and adapt when a format changed. That was exactly the wall RPA had hit. Many pointed public agents at their operations, and the first demos were electric.

Almost nobody looked at what it took to turn a demo into a reliable operation. The new problem showed up after going live. A public model, on its own, has no one controlling it, its accuracy falls short on the transactions that matter, and it lives in the cloud, so your operation's data leaves the company. With Chile's new data protection law, Ley 21.719, around the corner, that is no longer a detail.

The failures of that wave repeat so often they already have a list: unchecked authority, flawed decision data, unpredictable outputs and no auditable record. The second wave removed the rigidity and brought the risk back in. It could handle the mess, but a model on its own was never an operation.

Third wave, agent platforms: control is possible, at a high price

The answer to uncontrolled agents was to hand companies a platform: orchestration pieces, guardrails and governance to build a real system. On paper, that closes the gap the second wave opened. In practice it opens another one. These platforms are complex, expensive to run and hard to grow, and they demand AI engineers most companies don't have and can't hire in time.

The platform becomes one more thing to staff, maintain and update, and the project stalls where the others stalled: before production.

There is something that surprises anyone living through it for the first time: building the automation is usually one of the smaller parts of the project.

The effort goes into understanding how experienced people really decide and into writing down what the company knows and never wrote. It goes into getting a sponsor in management, preparing infrastructure and access, testing hundreds of real cases, refining exceptions and supporting users until they adopt it. None of that shows up in a demo or an optimistic schedule, and it is what decides whether the project delivers what it promised.

The three waves, and the missing one, side by side:

• RPA. Ended the manual clicking. Breaks on exceptions, changes and messy data.

• Public agents. Read the mess. End up uncontrolled, with doubtful accuracy and your data outside.

• Platforms built in-house. Make control possible. Are expensive and need engineers you don't have.

• A role with someone who answers for it. Someone takes charge of the whole result, so you are not handed a new gap.

The pattern of the three waves, and how to stop paying for it

Each wave moved the bottleneck instead of removing it. RPA moved it from clicks to exceptions; agents, from exceptions to control; platforms, from control to engineering. What never changed is that the gap the tool left behind ended up in your hands. That gap was never one more layer of technology. It was getting the work to function.

The lesson is not to stop betting on automation. It is to stop buying layers and start buying results. A layer gives you a new capability and a new problem, and leaves you the job of turning it into an operation that works.

Buying a result means the exceptions, the controls, the engineering and the daily operation are the responsibility of someone who answers for the result and not for the tool. On our site we call it SaaS in reverse: you don't buy the tool, you buy the work done, and the software comes inside.

Why it keeps happening, and why it isn't your fault

Because each wave was sold as the answer when it was only one piece, and the clock kept running. The demos became more impressive and the timelines more ambitious, while the unglamorous work of getting things running stayed just as hard and almost nobody talked about it.

Meanwhile, staying in evaluation gets more expensive every quarter. The question is no longer whether to automate. The question is who reaches a working operation first: you, or the competitor who stopped buying tools and started learning to use them. Every quarter you spend arguing over the last disappointment, they use to build up experience that is hard to catch up with later.

What we have been saying

In this series we said AI cannot learn what your best person knows and never wrote down, that a pilot that goes well proves something very different from an operation in production, and that value shows up when you put a role to work, not a loose capability. This column adds the next step: every wave removed a technical barrier, and none of them removed the work of turning AI into an operation.

So give yourself the credit the pattern gives you. You weren't wrong to automate the clicks, or to test the models, or to look at a platform. You were early, each time, to something real. The step now is to stop buying the next layer and add a role with a manager and a record, with a team behind it that answers for the result.

Sources

• Forrester and Gartner, 2024-2025: between 30% and 50% of enterprise RPA automations go inactive within 18 months.