The software that runs most small firms has no API. A practice management system from 2009. A county portal that was last redesigned when Internet Explorer was still the default. A vendor product whose company was acquired twice and whose support address bounces. Somebody in the office opens it every morning and moves numbers out of it by hand, and every proposal that firm has ever received for automation started with "first we integrate with your system", which is where the proposal ended.
So the answer matters. Yes, an agent can drive software with no API, because it can do what your clerk does: look at the screen, act on it, and check what happened.
Observe, act, verify
The loop has three parts and the third one is where the working systems separate from the demos.
Observe is a frame of the desktop and a question about it. Where is the field labelled "Matter number"? Is the save button enabled? Did a modal appear that was not there a second ago? This is a screen reading problem, and it is the part that got dramatically better in the last two years.
Act is a click, a keystroke, a paste. It goes to the desktop the same way a mouse does, through the remote framebuffer, so the application underneath cannot tell the difference and does not need a plugin, an agent installed on the machine, or a vendor's permission.
Verify is looking again to confirm the thing you intended actually happened. The field now reads what you typed. The record has a number. The list has one more row than it did. This step is boring, it roughly doubles the number of actions in a workflow, and skipping it is the single reason most screen automation gets thrown out within a month. An agent that clicks and moves on is a machine for producing wrong records quickly.
What the loop measures at
The control plane underneath this work is DeskVNC, which we build ourselves and which is in active development. Measured on a 1920x1080 Windows desktop over a local network, the observe and act cycle runs at 19 milliseconds. Expressed as a rate that is 52 agent actions a second, and typing goes into the remote desktop at 447 characters a second.
Read the condition, because it is doing as much work as the number. Local network. A specific resolution. That is a machine in the same building, which is the case this is built for, and it is not a claim about driving a desktop over a hotel connection.
The other thing to understand about 19 milliseconds is that it is not the speed of the work. The loop is almost never the slow part. The slow part is the application: a Windows form that takes 900 milliseconds to redraw after a dropdown, a portal that takes four seconds to submit, a report that takes a minute to generate. What the fast loop buys you is that the agent is never the bottleneck and never the reason a step timed out. When a task takes eleven minutes instead of six, it is because the software took eleven minutes.
For volume, the reference we use is a run of 818 multi page web forms filled and checked through the browser, across 391 organisations, on 19 August 2026. Each form was different, and each one was built for a person rather than a program. That is the evidence that this holds up on real websites, which is a different claim from a benchmark.
The lease, and why takeover has to be a lock
Two things cannot both be driving one desktop. If a person reaches for the mouse while an agent is halfway through a form, the result is not a collision anybody notices at the time. It is a record with one field from the person and one field from the agent, saved successfully, wrong, and discovered in six weeks.
So control is a lease. One holder at a time. A person clicks once and takes it, and from that instant the agent cannot send a single event to that desktop until control is handed back. Not "the agent yields when it sees a human", not "the agent pauses politely". It is locked out, by the thing sitting between it and the screen, and there is no code path where it wins the race.
This is the difference between a demonstration and something you would let near a matter file. A polite convention fails exactly when it matters most, which is the moment somebody grabbed the mouse because something looked wrong. Every action either side takes is logged, so when a record does come out strange, the question "who typed this" has an answer instead of a theory.
The other half of the lock is that the human never gets stranded. Taking control cannot leave a desktop the person cannot use, and handing it back cannot leave the agent halfway through a form it no longer understands. That constraint shaped more of the design than the automation did.
What makes a task a bad candidate
We turn down more of these than we take. The pattern is consistent enough to write down.
- The screen does not confirm the result. If the only way to know the submission worked is to log into a different system tomorrow, verify has nowhere to look, and you have automated the fast half of a two step job.
- The layout is not stable. Not "it changes twice a year", which is fine and is what the monitoring is for. Some portals reorder fields per session or render a different form depending on which office you are in. Every one of those variants is separate work.
- The action cannot be undone and nothing checks it. Filing something with a court, moving money, sending a message to a client. These can be automated up to the last click and then stop, with a person pressing the button. That check step is priced in rather than sold later as an upgrade.
- It happens four times a month. A task that takes ten minutes a week is eight hours a year. Nothing we build pays that back, and we will say so on the first call.
- It needs a judgement nobody can write down. If the answer to "how do you decide which category this goes in" is "you just know after a while", the job is to write that rule down first, and that is a different piece of work.
The tasks that do work are dull and repetitive and somebody hates doing them. One person, one screen, several hundred times a month, same shape each time. If you want a view on one of yours before you commit to anything, the free AI review is thirty minutes on one task and ends in a written page you keep.
What it costs, roughly
These are our October 2026 prices. Paid discovery of one task is $1,500 and it comes off the build in full. One task in a web portal starts from $3,500. One task in a desktop program or a remote desktop starts from $7,500. Both are fixed prices, verified on your own data before the balance is due. Each task after that in the same environment is $2,500 to $5,000, because the hard part was the first one. The care plan starts from $400 a month and it is optional.
Set that against the clerk. A back office employee doing this work costs an employer roughly $58,000 to $69,000 a year in the mid Atlantic once payroll taxes and benefits are counted. That comparison is what makes the arithmetic obvious for a job that runs every day, and what makes it obviously wrong for a job that runs on the last Friday of the month.
The answer
An agent can use software that has no API, and it does it by working through the screen, which is the same interface your staff use and the only one that is guaranteed to exist. The loop is fast enough that the application is always the slow part. The lease means a person can take the desk back in one click and the agent cannot argue. The tasks it suits are high volume, visually confirmable and dull.
If your task is any of the bad candidates above, no amount of engineering fixes that, and you should hear it from us before you have paid for anything.