Yes, AI agents can work with legacy systems that lack modern APIs, primarily through computer-use or screen automation techniques where the agent reads the application's interface via screenshots and interacts with it through simulated mouse clicks and keystrokes, the same way a human operator would. This approach works reliably for stable, predictable interfaces such as older terminal-based or Windows desktop applications common in insurance, banking and government systems, though it is slower and more fragile than a proper API integration, since any change to the interface layout can break the automation until it is updated. Where a legacy system exposes even a limited interface, such as a flat-file export, a database that can be queried directly, or an old SOAP or mainframe integration point, building a thin API wrapper around that interface is usually more reliable and maintainable long term than pure screen automation, and should be preferred whenever it is feasible. A practical strategy is to use screen automation as a bridge for the systems that truly have no other access path, while investing in lightweight API wrappers for systems where that investment pays off through reduced fragility. Nanobase AI has built agents against both patterns for clients whose core systems predate modern API standards.
Comparing the two viable approaches directly
There are really only two practical ways to connect an agent to a system with no modern API, and they trade reliability for reach in opposite directions. Choosing between them per system, rather than committing to one approach across an entire legacy estate, produces a more maintainable result than forcing every system through the same technique.
| Approach | How it works | Reliability | Maintenance burden |
|---|---|---|---|
| Computer-use / screen automation | Agent reads the interface via screenshots, interacts through simulated clicks and keystrokes | Lower; breaks when the interface layout changes | Ongoing, tied to how often the interface changes |
| Thin API wrapper | A small service exposes a clean API in front of an existing export, database, or old integration point | Higher; abstracted from the front-end interface entirely | Mostly one-time, plus normal service maintenance |
| Direct database or flat-file access | Agent or wrapper reads data directly from an underlying store or scheduled export | High, when available | Low, but depends on the system exposing this at all |
| Mainframe or old protocol integration (SOAP, terminal emulation) | Wrapper speaks the system's native old integration point | Moderate to high | Requires niche expertise but is stable once built |
A decision process for each legacy system
- Check whether the system exposes any programmatic access point at all, a flat-file export, a queryable database, an old SOAP endpoint, or a terminal integration, before assuming screen automation is the only option.
- If a programmatic access point exists, build a thin API wrapper around it rather than automating the visual interface, since the wrapper is more reliable and does not break when someone changes a button's position on screen.
- If genuinely no access point exists beyond the visual interface, use computer-use automation, but scope it to the most stable, least frequently changed screens in that application first.
- Budget ongoing maintenance time specifically for screen automation components, since interface updates, even minor ones, are the primary cause of breakage and need monitoring to catch quickly.
- Revisit the wrapper-versus-automation decision periodically as legacy systems get modernized or replaced, since the balance can shift as some systems gain real APIs over time. Checking for any programmatic access point before assuming screen automation is the only option avoids the more fragile choice by default.
Why stability of the interface matters more than its age
An old terminal-based insurance policy system with an interface that has not changed in a decade is often a better screen-automation candidate than a five-year-old web application still under active development, because the deciding factor is how often the interface changes, not how old the underlying system is. Screen automation against a frequently updated interface turns into a maintenance treadmill, since every release risks breaking the agent's interaction patterns, while automation against a genuinely frozen legacy interface can run reliably for years with minimal upkeep.
Where a thin wrapper pays for itself quickly
Building a small API wrapper takes real upfront engineering effort, typically more than pointing an agent at the screen directly, but it pays back through lower ongoing fragility and because that same wrapper can then serve any future integration need for that system, not just this one agent. Organizations planning multiple future automation projects against the same legacy system should weight this calculation toward the wrapper even when screen automation would technically work for the immediate task, since the wrapper's value compounds across future projects in a way single-purpose automation does not. A wrapper's value compounds across every future integration need for that system, not just the one prompting the current project.
Frequently asked questions
Is screen automation reliable enough for production use in 2026?
Yes, for stable, predictable interfaces common in older terminal-based or desktop systems, though it remains more fragile than an API-based integration and needs monitoring to catch breakage from interface changes quickly rather than silently.
How much does maintaining screen automation cost compared to an API integration?
Meaningfully more over time, since any interface change can require rework, whereas an API-based integration typically only needs updates when the underlying API itself changes, which happens far less frequently for stable legacy systems.
Can the same agent use both approaches for different systems?
Yes, and this is common. An agent orchestrating a multi-system workflow might call a modern API for one system, a thin wrapper for a second, and screen automation for a third, with the orchestration layer treating all three as equivalent tools.
Does this affect how many tools an agent ends up needing?
It can, since how many tools one agent can handle reliably depends partly on how consistent each tool's behavior is; a flaky screen-automation tool among otherwise reliable API tools can disproportionately hurt overall task success.
How Nanobase AI helps
Nanobase AI has built agents against both patterns, computer-use automation and thin API wrappers, for clients whose core systems, common in insurance, banking and government, predate modern API standards. The team evaluates each legacy system individually to decide which approach fits, rather than defaulting an entire integration project to one technique regardless of what each system actually supports.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.