Brittle was a feature

The migration is nearly universal now: off brittle, rule-based RPA and onto AI automation that learns and self-heals. The pitch is fair and the pain it answers is real. Old-style automation broke constantly — a vendor moved a button, a form added a field, an upstream system changed a date format, and the bot fell over. Teams ended up spending half their automation budget not automating anything new but repairing what had broken last week. Learning automation doesn’t fail that way. It adapts to the changed form, infers the new field, keeps going. For the teams drowning in bot maintenance, that is a genuine release, and we’d rarely tell a client to stay on the old rails.

But in the migrations we’ve watched up close, the trouble that shows up later is rarely the automation that stopped working. It’s the automation that kept working when it should have stopped. That failure mode is new, it is quiet, and most teams move onto learning pipelines without budgeting for it.

Brittle failed loud

The underrated virtue of the old brittle bot was that when it broke, it broke in your face. It stopped. It threw an error. The queue backed up, the dashboard went red, someone got paged at an inconvenient hour. That brittleness was a tax, and it was also a smoke alarm. You always knew the true state of the automation, because the moment reality diverged from its rules, it told you — loudly, immediately, and impossible to ignore. The rigidity everyone hated was the same property that kept the system honest.

Self-healing fails quiet

Now look at what “self-healing” actually does on an ordinary day. The pipeline meets the changed form, the unexpected input, the edge case the pilot never saw — and instead of stopping, it adapts and carries on. Most of the time that is exactly what you wanted. But “kept going” and “did the right thing” are not the same, and the system has just removed the signal that used to separate them. A pipeline that heals around a genuine problem doesn’t page anyone. It produces plausible output, on schedule, that is quietly wrong — and you tend to learn about it downstream, weeks later, in a number nobody thinks to trace back to the automation that produced it. The brittle bot’s best feature was that it stopped. The self-healing pipeline’s central risk is that it won’t.

The system you approved isn’t the one running

There’s a second quiet shift, and it compounds the first. You validated the model in the pilot, signed off, and moved on. It has been learning ever since. The pipeline in production this quarter is not the one you approved; it is a descendant of it, reshaped by whatever data has flowed through since. That descendant might be better. It might have drifted. Without continuous measurement you cannot tell which, and “we tested it at launch” answers a question about a system that no longer exists. Rule-based automation had the homely virtue of staying exactly what you tested. Learning automation gives that up on purpose — which is the entire point, and also the part nobody re-budgets for.

So you instrument the opposite thing

The practical consequence is that the monitoring you carried over from the RPA era is now aimed at the wrong target. With brittle bots you watched uptime: is it running? With learning automation, uptime is nearly useless, because the bot is always running — that’s the problem, not the reassurance. What you have to watch is the outcome, not the execution: not “did it complete,” but “were the completions right,” sampled continuously and checked against something true, because the system underneath is moving. In practice that means a baseline you re-measure rather than set once, alarms on shifts in the output distribution, and a held-out stream of cases a human actually audits on a schedule. The maintenance budget doesn’t vanish when you leave RPA. It moves — from repairing the bots that broke to auditing the bots that didn’t.

Keep a way to make it stop

One inheritance from the brittle era is worth keeping deliberately: the ability to halt. A self-healing system is designed, at its core, never to stop — which is precisely why you need a way to stop it from the outside, on purpose, when your audit says it has drifted. Do not rely on the pipeline to notice it has gone wrong and pause itself. Noticing was always the human’s job. Learning automation didn’t remove that job; it made it harder, less obvious, and more important, while quietly presenting itself as the thing that finally took the job away.

What you bought versus what you still have to do

The move off RPA is the right one. Brittleness was a real tax, and learning automation pays it down. Just be clear-eyed about what brittleness was also doing, unpaid and unnoticed: it was telling you, every time, the moment the world changed. Replace it and that job becomes yours — and it is the harder kind of job, watching for the failure that never announces itself. A pipeline that never breaks is not the same thing as a pipeline that is always right. The first is what the migration gives you. The second is what you still have to verify, now without the alarm that used to do it for free.