The API Barrier Is Falling and the Meaning Barrier Is Not.

On bounded tasks, generative AI can produce meaningful gains. In a large field study of customer-support agents, access to an AI assistant increased the number of issues resolved per hour by 14%. The NBER study is one of the clearest pieces of evidence that the technology can make work faster.

At enterprise level, the picture is much less impressive. McKinsey's 2026 global survey found that nearly nine in ten respondents said their organizations regularly used AI in at least one business function, yet 63% did not attribute any EBIT impact to it. The 37% who did were roughly the same share as a year earlier. Among respondents outside the small group of high performers, just one quarter said their organizations had fundamentally redesigned workflows because of AI.

Those findings are not contradictory. A tool can make one step faster while the end-to-end process remains unchanged. A draft still waits for approval. A decision still crosses several handoffs. A result still has to be re-entered into the system that runs the business. The local gain is real; the organization simply struggles to capture it.

We explored the first part of this problem in Enterprise AI Still Doesn't Work: most elapsed time in enterprise workflows sits in queues, handoffs and approvals rather than in the work itself. Adding AI to one activity often creates a faster version of the same process. Productivity requires redesigning the process around what the technology can now do.

That is where a second barrier appears. A redesigned process cannot remain inside a chat window. To move from a useful assistant to a production deployment, the agent has to retrieve a customer, prepare a booking, update an order, post a transaction or complete another action in the operational systems where the company already works.

Those systems are often old, heavily customized and difficult to integrate. MuleSoft's 2026 Connectivity Benchmark puts the average organization at 957 applications, only 27% of them connected, and 82% of IT leaders name data integration as one of their biggest challenges in using AI. Some do not expose an API for the relevant task. Others have one in principle, but access requires a lengthy project, additional licensing or cooperation from a vendor. Until recently, that left companies with a familiar choice: build a connector, deploy brittle robotic process automation or keep a person in the middle.

Computer use changes the choice between a connector, RPA and a person in the middle. Imagine a typical computer-use demonstration: an agent opens a flight-booking platform such as Amadeus, enters an itinerary, compares fares and fills the fields required to create a booking. Nobody built an Amadeus connector for it. There is no MCP server translating the application into a set of approved tools. The agent uses the screen, and an old enterprise constraint appears to disappear.

That is possible today. A modern vision-language model can inspect a screenshot, identify fields and controls, decide what to do next, and return mouse and keyboard actions. An execution layer performs those actions, captures the updated screen and gives it back to the model. The loop continues until the task is complete or the agent needs help.

In a browser, the system may combine visual understanding with the page structure exposed through HTML and accessibility attributes. On a desktop, it may use operating-system accessibility controls, SAP GUI Scripting or direct mouse and keyboard input. Through Citrix or another virtual desktop, it may have nothing but pixels. Recent computer-use systems can work across all three environments, although reliability falls as the available structure disappears.

The absence of a target API is therefore becoming less of a blocker. A screen-based agent can begin with the interface employees already use.

For the target system, little may change. The same form appears. The same user account logs in. The same authorization checks apply. From the application's perspective, the interaction may look much like an employee clicking and typing.

A computer-use agent typically receives a goal rather than a fixed sequence of clicks. It might be asked to find a refundable flight within a company's travel policy or prepare a purchase requisition in SAP. The model then plans the next step from the current state of the screen.

• The execution environment captures the current browser or desktop state.
• The model interprets the visible controls, values and messages.
• It chooses an action such as click, type, scroll, drag or keypress.
• The environment executes that action and returns the resulting state.
• The agent checks whether the intended change occurred before proceeding.

OpenAI describes this directly in its computer-use documentation: the model can operate browser and desktop interfaces, using screenshots and other tool results to decide what to do next. The implementation can generate structured mouse and keyboard actions or write code that controls an interface through tools such as Playwright and PyAutoGUI.

Traditional robotic process automation works differently. Classical RPA usually follows a flow designed in advance: find this field, enter that value, click this button. It works well while the interface and process remain stable. A computer-use agent can reason through moderate variation. It may recognize that a dialog moved, that a field has a different label, or that an unexpected warning must be resolved before the next step.

It is still software operating an imperfect interface. A changed layout, an unfamiliar exception, a timeout or a misleading confirmation can derail the run. A polished demo proves that a path can be completed. Production requires evidence that the relevant paths, exceptions and failure states are controlled.

SAP illustrates what computer use changes. In a modern Fiori application, an agent can often work through the browser using both page structure and visual understanding. In SAP GUI for Windows, it can use SAP's own scripting interface, Microsoft UI Automation or visual control. In a Citrix session, it may rely almost entirely on screenshots, keyboard input and mouse movements.

SAP has long provided a GUI Scripting API for Windows and Java, while Microsoft UI Automation exposes desktop controls to accessibility and testing software. These interfaces give automation more structure than raw screenshots, but administrators can enable, disable and govern them.

The practical result is that an agent can retrieve a customer record, prepare an invoice, enter a purchase requisition, download a report or update a defined set of fields without waiting for a new SAP integration project.

This should change how companies think about the last mile of enterprise automation. APIs remain faster, cheaper and more dependable at scale. They are still the right choice when a stable, supported interface exists. Computer use fills the gaps: legacy applications, rare workflows, vendor bottlenecks and tasks that span several interfaces designed only for people.

Imagine an agent creating a customer-related transaction in SAP. It has retrieved the account from Salesforce and matched it to a record in the ERP. Both systems contain a customer status. The labels look clear. The values disagree.

Sales considers the account active because an opportunity is open. Finance considers it inactive because no invoice has been issued for twelve months. Operations uses a third definition tied to service consumption. None of those definitions is necessarily wrong. Each was created for a different purpose.

A human employee often resolves this without noticing the amount of institutional knowledge involved. They know which definition matters for the transaction, which exception applies to this legal entity and which report Finance will use at month-end. The screen does not contain that reasoning. An agent can inspect every visible field and still lack the context required to choose correctly.

This is the same problem companies already encounter when they ask AI to answer questions across SAP, Salesforce, a warehouse and a BI tool. The systems often contain several technically valid versions of revenue, churn, margin or active customer. Giving an agent access to all of them does not settle the disagreement.

Computer use raises the stakes because the output is no longer limited to an answer in a chat window. The agent can now enter the value, submit the transaction and propagate its interpretation into another system.

Companies have spent years paying what we call the Meaning Tax: the cost of reconciling different definitions, tracing why reports disagree, waiting for data teams and relying on a small group of people who know which system to trust.

Computer-use agents can reduce the engineering work required to reach an application. Without a shared meaning layer, they can also multiply the number of places where inconsistent logic is applied. One agent interprets active customer from Salesforce. Another follows the SAP status. A third copies the definition embedded in a management report. Each completes its task successfully according to the screen in front of it.

This is how an access breakthrough can produce a governance problem. The enterprise gains more hands before it has agreed what those hands should believe.

This is the capability we are building at LazyFox. LazyFox connects read-only to the existing stack and reconciles meaning across systems without requiring the underlying data to be migrated first. It gives models and agents a governed representation of the enterprise rather than asking each of them to reconstruct that representation from screens, schemas and prompt context.

That representation operates at three levels.

• Structural meaning maps entities, fields and relationships across systems. It establishes, for example, how an SAP business partner relates to a Salesforce account and a warehouse customer record.
• Logical meaning holds approved metrics, calculations, exclusions and business rules. It determines how revenue, churn or performance periods are calculated rather than leaving the model to infer them.
• Contextual meaning preserves legitimate variation by role, domain, geography and time. Finance and Sales may use different customer definitions, but the variation becomes explicit, governed and selectable for the task at hand.

When definitions conflict, LazyFox surfaces the disagreement and routes it to the relevant business owner. Approved logic is versioned, monitored for drift and executed deterministically. The company retains its institutional context independently of whichever model or automation framework happens to be in use.

That changes the role of a computer-use agent. Instead of guessing from labels on a screen, the agent can retrieve the definition, relationships, row- and column-level permissions and arbitration rule relevant to the task. Before a consequential action, the values the agent is about to submit can be checked against the same governed logic used elsewhere in the company.

LazyFox does not need to replace SAP, Salesforce, Amadeus or the automation layer controlling them. Those systems remain the systems of record and action. LazyFox provides the context that tells the agent what the enterprise means.

The interaction layer can remain pragmatic. Use an API or MCP tool when one exists and is dependable. Use browser automation for modern web applications. Use desktop controls or computer vision for legacy systems. The semantic layer should remain stable across all of them.

This separation also protects the enterprise from model churn. Models and agent frameworks will continue to improve. The company's definitions, exceptions, ownership decisions and historical context should not have to be rebuilt whenever the model changes.

• Identify the real interaction method. Is the agent using page structure, an accessibility interface, vendor scripting or screenshots alone? Reliability and control differ materially.
• Keep authorization explicit. Which identity is acting, what may it read or change, and can the target vendor permit or prohibit the automation?
• Treat everything on screen as untrusted input. An agent that reads emails, tickets, documents or web pages can be steered by instructions hidden inside them. Which content can reach the agent, and what stops it from following an instruction that did not come from the user?
• Map the consequential actions. Which clicks create a booking, post an invoice, transmit data, trigger a payment or make another change that is difficult to reverse?
• Require confirmation at the right point. A human should review the exact action and values before high-impact submission, not merely approve a vague goal at the beginning.
• Keep an audit trail of every action. Record what the agent saw, which values it entered, which rule it relied on and who approved the step, so a disputed transaction can be reconstructed afterwards.
• Design for retries. If the screen times out after submission, how will the system determine whether the transaction succeeded and avoid creating it twice?
• Test exceptions rather than only the happy path. Popups, missing fields, conflicting records and authorization errors are where production reliability is decided.
• Find the hidden business definitions. Which decisions currently depend on an employee knowing which status, metric, system or exception governs?
• Separate access from truth. If SAP, Salesforce and the warehouse disagree, which definition should the agent use for this task and who approved that choice?
• Make meaning executable. Definitions should govern calculations and validation at runtime rather than sit in documentation beside the workflow.
• Keep institutional context model neutral. The company's knowledge should survive a change in model, agent framework or user interface.

If these questions remain unanswered, the absence of an API is probably no longer the main constraint. The agent may already have enough access to act. What it lacks is a reliable way to understand what the company means.