Your Business Software Never Had an API. Now It Doesn't Need One.

Every business has one piece of software nobody is allowed to touch.

The software nobody automates

Maria runs a three-person auto parts counter in Columbus, Ohio. The counter has a card reader from last year and a website her nephew built. It also has an inventory system her father installed in 2006, a grey, boxy program that still opens to a DOS-style menu.

Every Friday, someone opens the supplier's price list, a PDF, and retypes the new numbers into that program by hand. One row at a time. Part number, new price, enter. Part number, new price, enter. Two hours, every week, for nineteen years.

Nobody has ever tried to automate it. Not because they did not think of it. Because the software will not let them.

Why "no API" used to mean "no automation"

An API is a documented door. It is the thing a piece of software's makers build on purpose so other programs can ask it questions and give it instructions. Zapier, Make, a custom script, a chatbot with tool access, all of them walk through that door.

Maria's inventory program has no door. It was written before anyone expected outside software to talk to it, and nobody has touched the code since. So for nineteen years, the only thing that could operate it was a person, sitting there, clicking and typing.

That is the quiet rule that has capped small-business automation for years: no API, no automation. It is also the rule that just stopped being true.

The catch with the first wave of computer-use agents

In 2024 and 2025, a first generation of "computer-use" agents arrived. Anthropic and OpenAI both shipped models that could look at a screenshot and decide where to click, the same way a person would.

They worked. They also had a catch nobody advertised loudly: they took over the machine. The agent moved your actual mouse and typed on your actual keyboard, which meant you could not use the computer while it worked. You needed a spare laptop, or a virtual machine, or you sat there and watched your cursor jump around on its own.

For a three-person counter with one computer at the till, that catch was the whole problem. Nobody was going to hand over the only till computer for two hours so an AI could retype prices.

What changed: an agent that shares the keyboard

In April 2026, OpenAI's Codex shipped a version of computer use that could run in the background. A small team at a startup called Cua, some of whom had built similar tools at Microsoft years earlier, saw it and spent one weekend building their own version. Six days after the Codex announcement, they released it as open source, under the name Cua Driver.

The trick is where it looks. Instead of taking over the mouse, Cua Driver talks directly to the operating system's own accessibility layer, the internal map of buttons, fields, and menus that screen readers use for blind and low-vision users. On Windows it is called UI Automation, on Linux it is AT-SPI, on macOS it is AX. Because the agent reads and acts through that layer, it can click a button inside a window sitting behind everything else on your screen, and your mouse never moves. You can be answering an email in the foreground while an agent works two windows back.

When a piece of software does not expose enough of that map, an old program like Maria's, or a canvas-style app, the driver falls back to a real pixel click. It briefly brings the window forward for a few milliseconds to land the click, then hands focus straight back to whatever you were doing. The whole thing runs as one small program plus a built-in MCP server, on macOS, Windows, and Linux, and any AI agent that speaks that protocol, Claude Code, Cursor, or a custom one, can drive it.

Who is already trusting it with real work

Cua Driver is MIT-licensed and has passed 20,000 stars on GitHub, with commits landing most days. It is not a weekend toy that stayed a weekend toy. It already sits underneath the computer-use layer of several other AI agent products people already use: Clicky adopted it first, then Hermes, Qwen Code, H Company, and Factory's Droid. Several of those teams have sent fixes back upstream.

That matters more than the star count. It means the hard, boring part, getting an agent to reliably click the right thing in a background window on three different operating systems, is being tested by other companies' production traffic, not just by Cua's own team.

Isn't this just another RPA bot?

Robotic process automation tools such as UiPath have automated old desktop software for two decades by recording a person's clicks and replaying them. That approach breaks the moment a button moves half an inch.

Cua Driver is a different animal in two ways. First, a language model decides what to click by reading the current screen and reasoning about the goal, not by replaying a fixed recording, so a shifted button does not necessarily break it. Second, it runs in the background, which means a human and any number of agents can share one machine without fighting over the same cursor. Old RPA tools never solved that second problem, because they were built assuming the robot owned the screen.

Approach	Owns the mouse?	Breaks when a button moves?	Needs an API?
Classic RPA (recorded macro)	Yes	Usually	No
First-wave computer-use agent (2024-2025)	Yes	Rarely	No
Cua Driver (background, accessibility-layer)	No	Rarely	No

How this actually plays out in a small business

Here is the shape of it, step by step, using Maria's Friday price update as the example.

1. Install the driver. One command, on the same computer that already runs the old software.
2. Connect it to an agent you already use. Claude Code, Cursor, or any client that speaks MCP can now see the driver as a tool.
3. Give it one narrow, well-defined task first. Not "manage my inventory." Something closer to: "open the price screen, find this part number, set the price to match this row in the supplier PDF."
4. Let it run while you keep working. Every session records a trajectory, screenshots and actions together, so you can check exactly what it clicked before you trust it with the next batch.
5. Grow the list slowly. Once one task is reliable, script the next one. The goal is a short list of specific, tested jobs, not a general-purpose replacement for the person at the counter.

Where it still falls over

Notma's rule is to show you the honest limit, not just the highlight reel. Cua's own benchmark is the clearest warning label available. Built with Snorkel AI on real circuit-design software, it tested agents on 25 unfamiliar electrical-engineering tasks. The best agent fully completed only 6 of them, and every one of those 6 was an edit to a schematic that already existed. Starting from a blank schematic dropped every model's success rate to zero.

The lesson for a small business is direct: do not ask the agent to improvise on a screen it has never seen and figure out the whole workflow itself. Script one specific, narrow task, test it against your specific software, and always give it something that already exists to edit rather than asking it to build a process from nothing. The gap between "can edit what's there" and "can invent the right thing from a blank page" is still wide, on circuit software and on your inventory screen alike.

What you have after this

This week: the one Friday task that used to eat two hours, running quietly in a window behind whatever you are actually doing.

This month: two or three more scripted tasks against that same old software, each one narrow, each one checked against its trajectory log before you trust it.

Six months: the phrase "that software has no API" stops being the reason something in the business cannot be automated. The software was never the real blocker. Access to it was.

Same three people at Maria's counter. Same old grey program nobody wanted to touch. A completely different amount of time spent touching it.