Agents Need APIs, Not Screens
At month-end, the account movements are in Business Central, and someone has to turn them into a booking batch for DATEV. At MAFU-SHERPA, that step long relied on a spreadsheet rebuilt by hand for every closing cycle. Imagine giving this task to an AI agent that operates your programs through the screen. It sees an amount and an account name in a list. The screen does not show whether that amount belongs in the DATEV file as a debit or a credit; the answer comes from a sign held internally by the application. Nor can a screen reveal the order in which DATEV expects its mandatory columns.
That approach is called computer use. The agent sees a screen, moves the mouse, clicks buttons and operates software the way a person would. This has a genuine advantage: existing systems become usable without anyone building an integration. By contrast, an agent working through an API, the documented interface programs use to talk to each other, receives structured data rather than pixels. It calls a documented action, sends a JSON object, gets a machine-readable response and can log every step.
As a rule of thumb, then: where a system exposes a usable API, the agent should use it. Computer use remains the fallback for systems without an interface, for one-off operation of legacy software, and for tasks where the visual presentation genuinely has to be judged.
Why GUI operation is expensive for agents
A graphical interface is built for humans and compresses context visually. A filter, a hover state and a greyed-out button all carry meaning that a person absorbs without thinking about it. The agent has to translate that meaning into language first, and doing so takes screenshots, repeated observation and usually several intermediate steps before it even knows where it stands.
An API provides the same state directly. Project ID, status, timestamp and the next allowed action arrive as fields rather than having to be inferred from a screen. Benchmarks show how large that difference can be. In the WebArena benchmark (ICLR 2024), the strongest system tested completed 14.41 % of the longer web tasks, while people reached 78.24 %. Its extension OSWorld-Human compared 16 agent systems with human step sequences in June 2025; even the strongest systems needed 1.4 to 2.7 times as many steps, with much of the waiting time going into planning and reflection calls. Such figures age quickly and say nothing about whether one particular task will work in your company. The mechanism behind them remains relevant, however: state that exists only in an image has to be inferred, and long click chains give errors more opportunities.
Four advantages of API-first agents
- Token efficiency. An API response carrying the five relevant fields is many times smaller than a description of the screen those same five fields sit on.
- Speed. A single call replaces a chain of clicks, waits and visual verification steps.
- Accuracy. An account ID or a debit/credit indicator arrives as a value, while the same information on a screen has to be inferred from position, sign and habit.
- Auditability. An API call can be logged with its input, the permission used and the result, which is worth considerably more in a dispute than a recording of a click path.
What month-end closing reveals about interfaces
Back to MAFU-SHERPA. Its DATEV workflow uses a fixed transformation, which is precisely why the case shows the requirement so clearly. The application reads the filtered export from Business Central, processes only general ledger accounts with movements and writes posting records with amount, debit/credit indicator, account, contra account, document date and booking text. The result is an EXTF CSV file with metadata, complete column structure and Windows-compatible line endings. A person reviews it once more before the import.
Four details decide whether DATEV accepts the file. The sign has to be translated correctly into a debit/credit indicator. The amounts need the German decimal separator. Empty DATEV fields have to be set correctly, and all mandatory columns have to be delivered in the required order. None of these four details is visible on the screen where a person does the same work. A rule from our own delivery work: people rely on habits to judge whether an operation is correct, but an agent has no such habits.
When the agent has write access, a wrong click can change data immediately and without confirmation.
The same distinction matters across the back office. An agent that classifies a ticket and checks an order in ERP should be allowed to read broadly and write narrowly: small reversible steps run automatically, while anything touching money, dates or customers goes for approval. Agents in the Back Office: CRM, ERP and Ticketing via APIs explains where to draw that boundary in daily work.
Where else this difference matters
For deployment, someone used to open a cloud dashboard, create a database and inspect logs across four tabs. Through the APIs of Terraform, Cloudflare, Vercel or GitHub an agent instead reads repository state, queries migration status and, when something fails, reads exactly the log line belonging to the step that failed. Above all it can check whether the resource already exists, rather than blindly creating it a second time. The cluster article Why Deployment Agents Need APIs Instead of Dashboards goes deeper.
Many teams still treat SEO research as browser work to this day, although the same data is simply available. DataForSEO supplies keyword and SERP data, Google Search Console the actual queries, PostHog the behavior on the page. The gain only shows up in the second month, however, when the agent places the raw responses from last time alongside and marks what changed, which becomes practically impossible across interfaces that keep changing. More detail is in SEO Research with Agents: API Data Instead of Browsers.
In market and supplier research, the brief shifts in the same way: instead of “visit these pages and summarize them”, it becomes “collect these defined fields, flag every uncertainty and write the result into a reviewable data model”. A plausible but unsourced value is worse than a gap, and Research Agents Need APIs for Repeatable Source Work explains how to put this into practice.
When computer use still makes sense
GUI operation still matters when no API exists, when a task is rare or when the visual presentation itself must be evaluated. Admin interfaces without an API belong here, as do visual quality checks and operating a portal your company does not own.
In practice it therefore comes down to a layered model. APIs carry the stable, repeatable work, computer use is the adapter for the exceptions, and irreversible or unclear decisions go to a person for approval; which task belongs in which layer is decided by the risk involved rather than by the technology.
What companies should build now
Agents make interfaces more strategic than they used to be. If you are having an internal business app built or adapted anyway, you can put these six questions to your provider without analysing any software yourself.
- Which actions can another program trigger inside your software, and where are they documented?
- Do record IDs stay the same after an update, or do they change?
- How narrowly can a technical account be restricted to single roles and data areas?
- Is every change logged, with its timestamp, the account that triggered it and the previous value?
- Is there a test environment with real sample data where a write can fail without consequences?
- What happens if the same step runs twice? Does a second order appear?
The answers show you where an agent would later have to work through the screen and where it can connect cleanly instead. Switching systems is therefore rarely necessary; the first worthwhile investment usually sits exactly on that boundary. When you own the software, you control that choice. This fits our view that you can build software faster with AI while keeping control over architecture, data and processes.
The question worth asking
Computer use makes agents compatible with old software, and it will continue to be needed for that. Anyone putting agents into business processes, however, should ask less about which model clicks best and more about which of their systems offer structured, auditable interfaces. In our experience, the answer is more sobering than people expect. For MAFU-SHERPA’s month-end closing, the real work was not connecting the systems. It was documenting rules that nobody had needed to write down before. Whether an agent later handles that step or a fixed transformation does so is a secondary question.
Test whether a workflow is ready for agents against one real case: the systems involved, the roles and the places where a mistake would hurt. The interface needed becomes clear from that map. Discuss a concrete workflow.
When is an AI agent better through an API than through the screen?
Whenever the task recurs, has a fixed result and an error costs money or time. Through the API, the agent receives values instead of images, every step can be logged, and a second run does not create a second order. Working through the screen makes sense when no interface exists or when the presentation itself has to be checked.
Why are API calls cheaper for agents?
A call transfers only the relevant fields and the permitted action. Screen work needs screenshots, image reasoning, intermediate steps and verification glances, and that costs compute time and waiting time. The OSWorld-Human measurement compared 16 agent systems against human step sequences in June 2025; even the strongest systems needed 1.4 to 2.7 times the human step count, with much of the delay going into planning and reflection calls.
What makes our internal software agent-ready?
Documented actions, unique IDs, clear roles, status models, audit logs, a test environment and safe write paths for anything that cannot be taken back. The interface still matters, it is simply no longer the only working surface. Ask your provider about this before planning an agent, because the answer decides the effort involved.
Our standard software has no usable interface. What can we do?
Start with one concrete workflow and only then consider the platform. A lean application that runs beside the standard system and reads its export can often handle the valuable part, as the DATEV workflow out of Business Central does. Where that is not possible, computer use handles the exception, and risky steps still go to a person for approval.
For what this division of labor looks like in practice – including the question of which step legitimately stays in the dashboard – see our field report Dashboard or API? Secure Cloud Access for AI Agents.