The Cursor Moment for Automation
RPA didn't fail because the technology was bad. It failed because the wrong person was in control. Cursor figured this out for software development. The same move is coming for process automation.
A $200K RPA program "often runs $1–2M when you add it all up, at which point you're spending more on the automation than the manual process cost in the first place."
That's not from a critic. That's from a practitioner blog documenting what they built.
Sixty to seventy percent of enterprise RPA programs are underperforming against their original business case. Thirty to fifty percent are abandoned entirely — not restructured, not migrated. Shut down. UiPath's market cap has fallen 85% from its peak. Automation Anywhere, last valued at $6.8 billion in 2019, cannot command a public-market IPO and raised venture debt to avoid setting a lower valuation. Blue Prism was taken private after its stock collapsed. The acquirer had "no intention of major investment" after buying it.
The money is gone. The results aren't there.
Most people say the tools were bad. The selectors broke too easily. The vendors oversold. The GSIs overcharged.
All true. Not the real problem.
The real problem is that the wrong person was in control.
Enterprise RPA was built around a factory model. A practitioner — someone who does the actual work — identifies a process and files a request. That request goes to a business analyst who translates it into requirements. Those requirements go to a developer who builds the automation. The developer's work goes through CoE governance, gets deployed, and gets handed to a maintenance team. When it breaks — and at 45% of enterprises, it breaks weekly — the maintenance team fixes it.
The person who knows the process is at the front of this chain. They provide the input. They have no control over what happens next.
This isn't a technology failure. It's a distribution failure. The expertise — the real knowledge of how the process works, which edge cases matter, what the output needs to look like — lives with the practitioner. The tool was built for developers. So every automation required translating practitioner knowledge into developer language, losing precision at every step, creating something the practitioner couldn't own, debug, or improve.
The result: for every $1 spent on RPA licensing, enterprises spent $3.41–$4.00 on consulting and maintenance. Licensing was 25% of total cost. Services were 75%. The person actually building the bots — the developer — captured roughly 7–11 cents of every $100 the enterprise spent.
McKinsey documented one case where the value captured by an RPA program shrank from the promised 80% to 50%, to 30%, and finally to less than 10% once development got underway. Their exact words: "The effort quickly lost traction."
That's not a vendor problem. That's what happens when knowledge and control are separated by five handoff steps and an 18-month queue.
Cursor didn't succeed because it had better AI than GitHub Copilot.
It succeeded because it changed who was in control.
Before Cursor: developer writes code → asks AI for help → gets a suggestion → decides what to do → implements. The developer is in control of the loop, but the loop is slow and leaky.
Cursor's move: collapse the loop. Developer thinks → Cursor executes → developer sees result → iterates in seconds. The AI isn't an assistant you consult separately. It's a capability the developer wields directly, in real time, in the same environment where the work happens. The expertise stays with the person who has it. The tool amplifies it.
The developer is the user. That was the thesis. Not "AI replaces developers." Not "AI assists developers from the side." The developer, with the right tool in hand, does more — and the loop closes fast enough that nothing gets lost in translation.
Cursor didn't win by having smarter AI. It won by putting the AI closer to the person who knew what to build.
This is the same move for process automation.
The practitioner knows the workflow. They've been doing it for three years. They know which vendor changes their reference number format mid-month. They know which portal runs slow the last Friday before close. They know the output needs to look a specific way because a specific person will check it.
No developer knows this. No requirements document captures it. The knowledge lives with the person doing the work — and until now, there was no tool that let that person act on it directly.
Guerrilla Process Automation: the practitioner records what they actually do. The tool observes the steps, structures the automation, and runs it. IT approves the infrastructure once. The CoE supports without having to build every last-mile process from scratch. The loop closes in hours, not months.
The practitioner is the user. Same thesis as Cursor. Different domain.
RPA didn't fail because the technology was wrong. It failed because the model put the expertise and the tool in different hands — and every handoff lost something. By the time the bot ran, it was a pale copy of what the practitioner actually knew.
Cursor proved you can fix distribution by putting the right tool in the right hands.
The Cursor moment for automation is here.
The question is who captures it.
Written by
Pranav Neeli
12 years enterprise RPA — developer to architect to manager. Worked at Accenture, EY, Fossil, Alcon, HP. Now building Guerrilla Bots to fix the last mile.