The API won't come if you wait for it
Many important desktop systems (accounting, inventory management, older ERPs) have no API and, officially, won't get one anytime soon on the desktop side — integrations stay limited to the file export/import that other tools on the market already rely on.
That does not mean automation is impossible — it means it has to be built differently: by reading the native data format directly, or by controlled operation of the existing interface. Software automation without an API means, concretely, AI agents that operate exactly the interface you would have open yourself — not an API integration which, for many desktop accounting programs, simply does not exist.
The preferred path, when possible
When the data is accessible on disk or on the network (local databases, native files), direct reading is faster, more robust, and safer than operating the interface — it doesn't depend on what the screen looks like, and it can't "click the wrong button."
The strict rule we apply: direct reading, yes; direct writing, never. Any change goes through the source system’s official import mechanism, not through direct manipulation of data files. Unlike classic RPA, which follows a fixed script of clicks, a computer-use agent recognizes what has changed on screen — a window that moved, a renamed menu — and adapts, instead of failing at the first difference. For highly sensitive systems, where even direct data reading is not enough, we explain separately self-hosted AI, with your data on your own infrastructure, as an alternative to operating on top of an existing program.
Direct data reads vs. interface automation
Two paths for a system with no API. We combine them almost always.
| Direct data reads | Computer-use (on the interface) | |
|---|---|---|
| How it works | Reads the native format: database, DBF, PDF. | It sees the screen and interacts like a human: clicking, typing. |
| Speed | Fast, with no app to open. | Slower, depends on the interface's speed. |
| Robustness | It doesn't depend on what the screen looks like. | Sensitive to interface or version changes. |
| When it's used | The data is accessible on disk or on the network, read-only. | The interface is the only way in: data entry, validations inside the app. |
| Risk | Low, read-only by design. | Larger: an isolated environment plus step-by-step validation. |
In practice, most projects combine both: direct reads for analysis, computer-use only for the steps that genuinely require interface interaction.
When the interface is the only way
Sometimes there's no other option than for the agent to interact with the application exactly the way a human would — clicking, typing, reading off the screen — for steps that can't be done by reading/writing files (in-app validations, application-specific forms).
Here the safety rules are stricter: an isolated environment, steps checked one by one, and never irreversible actions (submission, final validation) without explicit human confirmation. A computer-use agent is, in practice, an AI agent that uses the computer exactly the way a person would — moving the mouse, reading the screen, pressing keys — wherever there is no other way in. For computer-use tasks, where the agent decides on its own a long sequence of on-screen actions, we explain separately when the most advanced AI model available is actually worth it, compared with the rest of your regular workload.
What we learned testing on real data
Real interfaces have surprises: menus locked because of hidden settings, error codes with no explanation, dialog boxes that render incorrectly. A good computer-use agent knows how to diagnose these blockers, not just repeat the same failed action.
A concrete example: diagnosing why a menu in an accounting application appears greyed out (a configuration setting hidden from the standard interface) — solved by reading the configuration files directly, not by trial and error on screen. We've tested AI agents using the computer on real interfaces, with locked menus and misrendered dialog boxes, not just in clean test environments.
Diagnosis first, automation after
Every project of this kind starts by checking what's technically possible, not by assuming the interface can be automated directly. AI desktop application automation always starts with a technical diagnostic — we check what can be read directly from the data before proposing to operate the interface.
- 01We check whether there's a direct read path (preferred) or whether interface interaction is needed
- 02We build the connector/agent, with explicit rules on what it can do alone and what needs confirmation
- 03We test on real data and scenarios, including edge cases (errors, blockages, unexpected interfaces)
- 04We hand over documentation on exactly what the system automates and what stays manual
A fixed price, after a short discovery call.
- system diagnosis
- read-only connector
- handover + documentation
- interface mapping
- agent + safety rules
- team training
- continuous monitoring
- monthly adjustments
- monthly report
Every project has a different context, workflows and infrastructure, so the price is set after a short, paid discovery and does not change along the way.
Frequently asked questions
What is a computer-use agent?
It's an AI agent that interacts with an application exactly the way a human would — it sees the screen, clicks, types — for systems that offer no other way to integrate (no API, no automatic export). It's used as a last resort, when direct data reading isn't possible.
Automating software with no API — is it possible?
Yes, in two ways: reading the native data format directly (more robust, preferred when possible), or controlled operation of the existing interface (computer-use, when there's no other way). Many major desktop systems in Romania work this way.
Is it safe to let an AI agent operate a desktop application?
With clear rules, yes: an isolated environment, checked steps, and no irreversible actions (sending, final confirmation, deletion) without explicit human confirmation. Without these limits, the risk is real — which is why we always design with "what it can do on its own" kept strictly separate from "what needs a human."
Why not just wait for an API to show up?
For some major desktop systems, the vendor has officially confirmed that APIs remain planned only for the cloud/web versions, not the desktop ones, with no clear timeline. You'd be waiting indefinitely for an API that may never arrive for the version you use today.
Can it write automatically back into the source system (e.g. accounting)?
Our firm recommendation is no — writing directly into a system's data files can corrupt its integrity. Every change goes through the official import/export mechanism the system exposes, even if that means an extra step.
How much does automating a system with no API cost?
It depends on whether you just need reading (simpler, cheaper) or full interface operation (more complex).
What CAEN code covers this type of automation for a company in Romania?
Custom software automation and integration, including computer-use agents, falls under the same CAEN code 6201 as custom software development.
Let's see what can be automated in your business.
A free 30-minute session: we'll tell you what can be automated, how long it takes and what it costs, with a fixed price after discovery.