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

Watch a computer-use demo and an old enterprise constraint seems to disappear. An agent opens Amadeus, enters an itinerary, compares fares and fills in the fields needed to create a booking. Nobody built an Amadeus connector for it, and no MCP server translates the application into a set of approved tools. The agent uses the screen the way a travel coordinator would.

For large companies, that matters more than any model benchmark. MuleSoft's 2026 Connectivity Benchmark counts 957 applications in the average organization and finds only 27% of them connected, and 82% of IT leaders name data integration as one of their biggest obstacles to using AI. Some of those systems have no API for the task at hand. Others have one that takes a lengthy project, extra licensing or a vendor's cooperation to use. Until recently the options were to build a connector, deploy brittle robotic process automation or keep a person in the middle.

That boundary explains much of the gap between what AI does for a task and what it does for a company. In an NBER field study, customer-support agents with an AI assistant resolved 14% more issues per hour. In McKinsey's 2026 survey, 63% of respondents attribute no EBIT impact to AI at all. As we argued in Enterprise AI Still Doesn't Work, most elapsed time in enterprise workflows sits in queues, handoffs and approvals, and a faster step inside an unchanged process rarely moves the P&L. A redesigned process has to reach the systems where the work is recorded, and until now that meant waiting for integration.

Computer use moves that boundary, and it exposes what was behind it. Give an agent the SAP screen your finance team uses and it will find the customer status field in seconds. It won't know that Sales calls the account active, Finance calls it inactive, and the renewal it is about to process depends on which of them is right.

A computer-use agent receives a goal, such as finding a refundable flight within travel policy or entering a purchase requisition, rather than a fixed sequence of clicks. A vision-language model reads a screenshot, identifies fields and controls, and returns a mouse or keyboard action. An execution layer performs the action, captures the new screen and hands it back, and the model checks whether the change it intended took place before it picks the next step. OpenAI's computer-use documentation describes the same loop, driven either by screenshots or by code that controls the interface through tools such as Playwright and PyAutoGUI.

How much the agent can rely on depends on the interface. In a browser application such as SAP Fiori, it combines visual understanding with page structure and accessibility attributes. In SAP GUI for Windows, it can use SAP's GUI Scripting API or Microsoft UI Automation, where administrators have left them enabled. Through Citrix, it has pixels, a keyboard and a mouse.

On any of these rungs, the agent can retrieve a customer record, prepare an invoice, enter a requisition or update a defined set of fields without a new SAP integration project. The target system sees the same form, the same user account and the same authorization checks it would see if an employee were clicking and typing.

The loop is also what separates computer use from classical RPA. An RPA bot follows a path designed in advance and breaks when a dialog moves or a label changes, while an agent can reason through that kind of variation. It is still software driving an interface built for people. A changed layout, an unfamiliar exception or a timeout after submission can derail a run, and a polished demo proves only that one path can be completed. Where a stable, supported API exists, it remains faster, cheaper and more dependable. Computer use fills the gaps: legacy applications, rare workflows, vendor bottlenecks and processes that span several screens.

Say an agent is processing a renewal discount. It pulls the account from Salesforce, where the status is active because an opportunity is open. It opens the matching SAP record, where no invoice has been issued for twelve months and the account is flagged inactive. Operations would classify the same customer differently again, based on service consumption. None of these definitions is wrong, because each was built for a different purpose.

An experienced employee settles this in seconds and would struggle to explain how. They know the discount policy follows Finance's definition, that this legal entity has an exception, and that month-end reporting is reconciled against SAP. None of that is on the screen, so the agent sees two valid fields and has to pick one.

Companies already run into this when they ask AI to answer questions across SAP, Salesforce, a warehouse and a BI tool, which often hold 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 cost of picking wrong. The result is no longer a bad number in a chat window. It is a discount Finance never approved, sitting in the system of record and feeding every report that reads from it.

Companies have paid what we call the Meaning Tax for years: the cost of reconciling definitions, tracing why reports disagree, waiting on data teams and depending on the few people who know which system to trust.

Computer-use agents cut the engineering needed to reach an application. Without a shared meaning layer, they also multiply the places where inconsistent logic gets applied. One agent reads active customer from Salesforce, another follows the SAP status, and a third copies the definition embedded in a management report. Each completes its task correctly according to the screen in front of it.

That is how an access breakthrough turns into a governance problem. The enterprise gains more hands before it has agreed what those hands should believe.

To process the renewal correctly, the agent has to know that the Salesforce account and the SAP business partner are the same customer, which status the approved discount rule follows, and whether that rule differs for this entity or period. None of it can be read off a form. We call the layer that supplies it an Enterprise Intelligence Layer, and it is what we are building at LazyFox.

LazyFox connects read-only to the existing stack and reconciles meaning across systems without migrating the underlying data. It gives models and agents one governed representation of the enterprise, instead of asking each of them to rebuild it from screens, schemas and prompt context. That representation works at three levels.

• Structural meaning maps entities, fields and relationships across systems, 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, so the model does not have to infer how revenue, churn or a performance period is calculated.
• Contextual meaning keeps legitimate variation by role, domain, geography and time. Finance and Sales can keep different customer definitions, and the difference becomes explicit, governed and selectable for the task.

When definitions conflict, LazyFox surfaces the disagreement and routes it to the business owner. Approved logic is versioned, monitored for drift and executed deterministically, and it stays with the company whichever model or automation framework is in use.

In the renewal example, the agent retrieves the governing definition, the entity mapping, the row- and column-level permissions and the arbitration rule before it acts, and the discount it is about to submit is checked against the same logic Finance uses at month-end. SAP, Salesforce and Amadeus remain the systems of record and action, and the automation layer driving them stays in place. LazyFox supplies what the enterprise means.

The interaction layer can stay pragmatic: an API or MCP tool where a dependable one exists, browser automation for modern web applications, and desktop controls or computer vision for legacy systems. The meaning layer should stay the same across all of them.

Keeping the two apart also protects against model churn. Models and agent frameworks will keep improving, and the company's definitions, exceptions and ownership decisions should not have to be rebuilt each time one of them is replaced.

Access questions

• Identify the real interaction method. Is the agent using page structure, an accessibility interface, vendor scripting or screenshots alone? Reliability and control differ materially between them.
• Keep authorization explicit. Which identity is acting, what may it read or change, and does the target vendor permit 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 the user never gave?
• Map the consequential actions. Which clicks create a booking, post an invoice, transmit data, trigger a payment or make another change that is hard to reverse?
• Require confirmation at the right point. A person should review the exact action and values before a high-impact submission, not approve a vague goal at the start.
• 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.
• Design for retries. If the screen times out after submission, how does the system find out whether the transaction went through, and avoid creating it twice?
• Test the exceptions, not only the happy path. Popups, missing fields, conflicting records and authorization errors decide production reliability.

Meaning questions

• Find the hidden business definitions. Which decisions today 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, not sit in documentation beside the workflow.
• Keep institutional context model neutral. The company's knowledge should survive a change of model, agent framework or user interface.

Most teams piloting computer use are working through the first list. If the second list is still open, a missing API is no longer what holds the agent back. It already has enough access to act, and no reliable way to know what the company means.