What makes desktop software easy for AI agents to use

A new kind of user

Language-model agents are starting to operate ordinary desktop programs: editing documents, building slide decks, styling maps, modelling parts. But those programs were designed for two other audiences. The graphical interface assumes someone who can see buttons and watch the screen change. The scripting interface, or SDK, assumes a developer who will read documentation, learn an object model, write code and debug it. An agent has to imitate one of those people, and it often does so badly.

Benchmarks have made the gap visible. OSWorld, a widely used test of agents on real computers, gives each of its 369 tasks a setup script and an execution-based checker. When it was published, humans completed over 72 percent of the tasks while the best model managed about 12 percent, with the authors pointing to weak GUI grounding and missing operational knowledge as the main causes.

Using software history as an experiment

A recent preprint, A Decade in a Day, asks a sharper question: what is it about an interface that helps or hurts an agent? Rather than inventing interface variants, the authors noticed that software evolution already supplies them. Across years of releases an application's core features stay roughly the same while its programming interface is reworked by developers responding to real pressure from users.

They built a benchmark of 255 tasks across six applications: LibreOffice Writer and Impress, Inkscape, Blender, QGIS and FreeCAD. Every task specifies a saved result, not a screen state, and comes with a script that inspects the output file and returns pass or fail. Holding the agent, the model, the task and the checker fixed, they changed only which release of the application was installed.

The newest release beat the oldest in all twelve model and application combinations. The biggest jump was QGIS, where success rose from 33 to 65 percent for one model and from 41 to 69 percent for the other. In one mapping task, the older release forced the agent through a long chain of poorly documented calls and it failed after 33 turns; the newer release offered a single, clearly described classification operation and the same agent finished in 11 turns using a small fraction of the input.

Three properties that matter

Reading the agents' step-by-step logs, the authors traced the gains to three properties. Discoverability means the agent can find what operations exist while the program is running, with descriptions clear enough to call them correctly. Agents in the study spent roughly a quarter to a third of their input on discovery alone, and handing them the shipped documentation did not consistently help.

Granularity means the interface offers operations that match common goals, so the agent does not have to assemble them from dozens of low-level calls. Every extra call is another chance for a wrong parameter. When QGIS added higher-level processing tools, the average number of calls per task fell from about 30 to about 21.

Observability means that whatever the agent can change, it can also read back at the same level. This one did not improve across releases. The authors found 581 runs in which the agent reported success but the saved file failed the check, and they point to places where a setting can be written but has no matching way to read it.

Building the interface agents want

The paper then proposes a system called ANIS that builds an agent-oriented interface from an installed application. It collects candidate operations from the running program, keeps only those whose effects survive saving and reopening the file, and turns each into a small, uniformly described command, paired with a read command wherever one exists. As agents use it, recurring command sequences are packaged into verified goal-level commands.

On an expanded set of 368 tasks across eight applications, the atomic commands lifted success from 68.5 percent with the native SDK to 72.3 percent, and goal-level commands raised it to 74.5 percent, while tokens per task fell by roughly 73 percent. It was not a clean sweep: the native SDK still did better on FreeCAD and Blender, and building each interface took between about 17 and 36 hours.

The same lessons for anyone writing tools

These findings line up with practical guidance for people who write tools for agents. Anthropic's engineering advice recommends consolidating several low-level tools into one that matches a real task, such as a single scheduling tool instead of separate list and create calls; grouping tools under clear names; describing them as you would to a new hire; returning meaningful, compact context; and making error messages say how to fix the problem. In other words: make capabilities easy to find, size them to the job, and let the agent see what it actually did.