- RPA mimics a person clicking and typing. It works where there's no other way into a system, and it breaks when the screen changes.
- A direct connection between systems is sturdier and usually the better choice when one exists.
- AI reads and interprets: emails, documents, free text. It handles variety that rules can't.
- Most real processes need a mix: AI to read, a connection to move data, a person to decide.
- RPA is still right for older software with no other way in, short-lived needs and some desktop tasks.
Monday morning, the bot is down
The bot ran fine for eight months. Every night it logged into the old order system, copied new orders and typed them into the ERP. Then over the weekend the order system got an update. A button moved. A field got a new label.
Monday morning, nothing came through. The bot didn't crash loudly. It just couldn't find what it was looking for. By the time someone noticed, there were two days of orders to key by hand.
Anyone who has run RPA for long has a version of this story. It isn't a reason to never use it. It's a reason to understand what kind of tool it is.
Three different tools
"Automation" covers three quite different approaches. It helps to name them.
- RPA, or robotic process automation. Software that operates other software through its screens. It clicks buttons, types into fields and reads what's displayed, the way a person would. Microsoft calls this desktop flows. Tools like UiPath and Automation Anywhere are built around it.
- Direct connections. Systems talking to each other through the official routes their makers provide. No screens involved. One system sends an order, the other receives it as data.
- AI reading and judgment. Models that read unstructured input like emails, PDFs and notes, and decide what it means. "This email is a change to an existing order, and here are the new quantities."
They answer different questions. RPA answers "how do I get into this system?" Connections answer "how do I move data reliably?" AI answers "what does this messy input mean?"
Why screen bots break
An RPA bot finds things on screen using markers. A button's label, its position, the structure of the page around it. UiPath calls these selectors. Microsoft calls them UI elements. When those markers change, the bot loses its way.
Markers change more often than you'd think:
- A software update moves or renames a field.
- A pop-up appears that wasn't there before.
- The screen loads slower than usual, and the bot clicks too early.
- Someone changes the display resolution on the machine the bot runs on.
- A password expires.
Good RPA developers build in waits, checks and fallbacks. That helps. It doesn't change the basic fact: the bot depends on a screen designed for people, and that screen can change without warning.
A direct connection doesn't have this problem in the same way. Software makers generally keep their official connection routes stable and announce changes ahead of time. When they do change something, you usually hear about it first.
Where AI fits
Classic RPA follows rules. It's precise when the input is precise. Give it a customer email in a slightly different format and it doesn't know what to do.
AI fills that gap. It reads the email, works out it's an order, pulls out the items and quantities, and flags anything it isn't sure about. Our guide to intelligent document processing covers how that reading works.
AI is not a replacement for connections or for people. It interprets. Something still has to move the result into your systems, and someone still has to approve anything with real consequences. Our guide to AI agents covers where software can act on its own and where it shouldn't.
Where AI is changing RPA
RPA tools are adding AI of their own. Some use it to find buttons and fields on screen more flexibly, so a moved button doesn't break the bot. Newer AI models can also operate a computer directly, looking at the screen and deciding where to click.
These help with brittleness. They don't remove it. A model that decides where to click can also click the wrong thing, and it's slower than a connection. For work that runs thousands of times a day, a direct connection is still the sturdier choice.
Treat AI-driven screen automation like any new tool. Try it on a low-risk task, measure how often it gets things wrong and keep a person checking anything that matters.
When RPA is still the right call
RPA gets criticized a lot. It still has a real place.
- Old software with no other way in. A legacy system with no official connection, no export and no vendor who'll add one. A bot may be the only option short of replacing the system.
- A short-term bridge. You're migrating off a system in six months. A bot that moves data until then is cheaper than building a proper connection to something you're about to retire.
- Desktop tasks on one machine. Pulling a report from a Windows application every morning, where a person watches it run.
- Government or partner portals. Some outside websites only offer a screen. Check their terms of use before automating it.
Microsoft's own documentation frames it the same way: desktop automation is for applications that lack a connector and offer no other route in.
If you do use RPA, treat each bot like a fragile piece of equipment. Know who owns it. Alert someone the moment it fails. Keep a manual fallback that people know how to run.
How to choose
Walk through these questions in order for each process.
- Does every system involved offer an official connection? If yes, use it. It's sturdier and easier to monitor.
- Is the input structured or messy? Structured data moves with rules. Emails, PDFs and free text need AI to read them.
- Is there a system with no way in except its screen? That step may need RPA. Keep the bot's job as small as possible.
- Where does a person need to decide? Put review there, whichever tools do the rest.
- How long will this process exist? A temporary need can tolerate a fragile tool. A core process for the next five years deserves a sturdier one.
Most answers end up as a mix. AI reads the incoming email. A connection updates the ERP. A small bot handles the one old system that can't be reached any other way. A person approves the exceptions.
What the mix looks like in practice
Take a manufacturer that receives purchase orders from customers by email. The orders need to land in the ERP. Production planning lives in an older scheduling tool that only runs on a Windows desktop.
AI reads each email and attachment, works out which customer and which parts, and flags anything odd. A direct connection creates the sales order in the ERP, which offers an official route in. The older scheduling tool has no such route, so a small desktop bot copies the new order into it each hour. When the bot fails, a named person gets an alert and the order still sits safely in the ERP.
Notice how little the bot does. It handles one step, on one system, with a clear fallback. That's how RPA should be used when it's needed: as a narrow bridge, not the backbone.
If you keep bots, run them well
- Give each bot a named owner and a written description of what it does.
- Run it under its own account with only the access it needs.
- Send failures to a person straight away, not to a log nobody reads.
- Ask your software vendors to warn you before updates, and test the bot after each one.
- Keep a plan to replace the bot when the system it works around gets an official connection or gets retired.
What most guides miss
Ask the vendor first. Teams sometimes build a bot for a system that does offer an official connection. They just didn't know. A short email to your vendor or account rep can save a fragile build.
The bot's account is a security question. An RPA bot logs in as a user. That login needs the right permissions, a safe place for its password and someone responsible for it. Treat it like a staff account, not a script.
Count maintenance, not just the build. A bot that's quick to build but needs fixing every few weeks may cost more over a year than a connection that took longer up front. Track how often each bot breaks.
Don't automate a bad process. A bot that copies data between two systems may be hiding the real problem, which is that the data lives in two places. Sometimes the right fix is removing a step, not automating it.
How we do it
We start with a free intro call and map the process with your team, system by system. We use official connections wherever they exist, AI where input is messy, and screen automation only where nothing else reaches. We stay on after launch to keep it running as your systems change. See our process automation work, or start with an intro call.
