Author: a16z

Translator: Deep Tide TechFlow

Deep Tide Guide: As computers use AI to transition from demonstrations to large-scale production, investors need to focus not on which model scores the highest, but on which companies can turn soft skills like validation, fault tolerance, and process knowledge into reusable products. This article disassembles real deployment data from front-line teams, revealing the true bottlenecks and moats of AI agents landing in corporate backends.

Can agents use computers now? We answer with data

When your most important users stop looking at the leaderboard, the leaderboard is no longer a story

This principle seems simple, but if you leave Silicon Valley and go to other parts of the world telling people, "There is something called an agent, quite smart, that can work with you and automate the repetitive parts of your work," the other party will likely ask, "Can they use computers?"

This is a good question! Can they? The productivity potential we need to unleash in the coming decades runs through extremely routine work: can an agent (figuratively speaking) sit at a desk for 24 hours, trusted to use a browser, fill out forms, click buttons, and make no mistakes? This is the domain of business process outsourcing. In the past, this meant, "Can this work be outsourced?" But now there is a new frontier driven by agents. We wrote about this topic last year when the prospects for computer usage were still essentially just a series of demonstrations. Since then, the changes have been significant.

The pace of model advancement has exceeded almost everyone's expectations. Agents capable of using computers have begun to secure their footing in scalable production, aimed at narrow, repeatable workflows: updating record systems, transporting data between portals, processing work orders, verifying records, handling those long-tail software applications without clear strong APIs. With the right infrastructure, computer capabilities can now be deployed to handle end-to-end tasks, whereas these jobs previously required human supervision or were done directly by humans.

Today, workflows leveraging computer capabilities are far from perfect: agents become fragile when work deviates from standard operating procedures; in some uncacheable cases (more on this below), the costs are high enough that the math doesn’t add up. But we have already seen standardized deployment of backend work, especially for tasks that otherwise would require manual clicks in legacy systems; cost curves are beginning to look attractive, considering that workflows utilizing computer capabilities provide structural advantages, such as being available around the clock, and most importantly—scalable to meet demand.

The first wave of computer usage infrastructure aimed at enabling agents: seeing, clicking, typing, recovering from errors. The next wave is making them useful in real companies. When raw page navigation becomes a commodity at the model layer, models are no longer the main bottleneck, and enduring advantages will shift upward: context, permissions, procedural knowledge, validation, upgrades, error handling, caching, and the hard-won understanding of how work is actually done within a specific customer organization, thus mapping a workflow from end to end. In other words, the frontier is shifting from "Can agents use computers?" to "Can they reliably do this job?"

From humans supervising every step to truly autonomous workflows

A year ago, the best computer usage model scored 42% on OSWorld-Verified; today, the best model scores 85%, surpassing humans' approximately 72% on the same task (which means it successfully completed 85 out of 100 tasks). In production, the performance of these generalized frontier models is very similar to how they appear in benchmark tests: major labs expose computer usage as APIs—models receive a screenshot, return clicks and key presses, and OpenAI's CUA even overlays accessibility trees or DOM data when available—builders wrap this cycle in their own control systems: a sandbox virtual machine or browser, plus orchestration, validation, and retry logic. Notably, almost no one deploys consumer-grade products (like Claude, ChatGPT agent modes) for this purpose—founders and companies build directly on the original APIs, or purchase from suppliers that package those APIs. The leap in capabilities is precisely what has made these setups feasible; "It wasn't until February 2026 with Opus 4.6 that models truly proved sufficient by themselves in production environments," said one founder starting a business in this field. At some point in the past eighteen months, computer usage capability crossed the threshold from demonstration to deployable in the field.

Figure:OSWorld-Verified Computer usage benchmark scores have improved year by year, with the best model in 2026 surpassing human levels

Source: a16z

Of course, benchmarks are not always the best representation of real-world deployment feasibility. OSWorld counts completed tasks, so 85% still means that 15 out of 100 tasks failed, while a business process is only considered complete when every step is successful. Backend work does not look at curves: if every output needs to be reviewed by a human, then labor hasn't been saved at all. (This is similar to what is happening in the current code-writing field: the scarce resource is no longer writing code but ensuring the code.)

We find that the best way to think about what matters most is to go beyond benchmarks and focus on core issues: can a business process be reliably automated using computer capabilities? From this perspective, what has the most impact are all the surrounding factors—namely validation, upgrades, error handling, and what to do when a retail portal is redesigned overnight.

Perhaps the clearest signal is that one operator we spoke with runs millions of automated tasks every month, and he can't tell us which model is executing the tasks; he doesn't need to know. His supplier switches models underneath just like cloud vendors switch hardware. But he does trust that the agent using a computer is running these tasks. The key point: when your most important users stop looking at the leaderboard, the leaderboard is no longer a story.

Thus, the above explains why production deployment emerges in 2026 instead of 2024. From there on, everything else decides their effectiveness—which is what the rest of this article will discuss.

Agents are adhering to protocols

We have talked to many teams running computer usage workflows in production, and have learned from their experience that tasks adhering to protocols perform best. It is no surprise that agents using computers fail more often on complex workflows where accuracy is harder to verify. The overall conclusion is that computer usage agents are strongest in standardized, repeatable tasks where there is a clear, well-defined path. The real transformation is in the long-tail software that has no clean APIs and would otherwise require manual clicks in the interface. In practice, these tasks look like updating records in CRM, quality assurance, logging into government and insurance portals, pulling data from databases and regulatory pages, retail order processing, contract processing, or IT work orders in ServiceNow.

We believe that the user's voice explains things better than any theory. Here are a few examples: A consumer goods data platform demonstrated to us how they run about 15 to 20 million automated portal interactions monthly, using an agent as a self-healing fallback for manually coded crawlers—when a retail portal is redesigned, the agent diagnoses the failure, repairs the automation, and maintains data flow before engineers even see any errors. They told us that after implementation, the dedicated crawler maintenance engineering team was cut in half, with labor being reallocated to other workflows. Another case from a global systems integrator revealed they have 27 real-time workflows utilizing computer usage agents to process approximately 1500 to 2100 IT work orders daily, with the ultimate goal of redeploying 20% to 25% of labor in low-margin managed service contracts. Finally, an agency told us how they automated a recruitment workflow end-to-end, filling data into an applicant tracking platform right after candidate interviews. For this purpose, they were running a cheap non-frontier model, as it "did all the things we needed, and did it well."

The clearest pattern is those tasks that, in theory, computer usage agents can operate and resolve, but for which there isn’t a clear answer on "what counts as good" (i.e., difficult to evaluate), or for which there is no reliable way to determine if the task was successful. Problems often arise quickly when: (1) You can't cross-verify outputs—imagine an agent extracting payment terms from a contract to an ERP: if it reads "net 60" as "net 30," the record looks entirely reasonable, passing all visual checks, until an incorrect invoice is discovered; (2) In some cases, there’s simply no signal during task execution to verify success—imagine an agent submitting a claim on an insurance portal: submission goes through, the screen says "Received," task complete. Only two days later does the claims adjuster call the office, because the policy number needs confirmation to proceed. The human employee who submitted the claim will pick up the phone, sort it out in half a minute; the agent has no idea that this call ever happened, and the claim quietly gets stalled. In summary, if the real basis of the process relies on a phone call that lands on someone's desk a week later, even smarter models are of no use unless the control system was designed from the start to handle such edge cases.

Buyers care about infrastructure

For buyers we spoke with, the models themselves are rarely the deciding factor, because "today's models are good enough." In practice, what they evaluate and pay for is everything surrounding the models: the infrastructure that can operate reliably at scale, pass security reviews, and demonstrate return on investment. Users don't care whether the solution uses a particular frontier model; they only care whether it can reliably complete tasks at scale. That’s all.

Thus, failure modes are more important than any benchmark, and designing around failures must be a top priority from day one, because a solution that handles failures poorly will never be adopted in production environments. A common pattern we encountered more than once: agents run a workflow once, and the system caches it as deterministic code, then executes it repeatedly at low cost; the model only comes back during failures—for diagnosis, repair, and re-caching. By this method, the cost of each workflow decreases every time it runs over its lifecycle, and using cheaper models will only reduce the bill. What’s interesting here is how it manages uncertainty. In the past, deterministic code could only fail directly, or required human review and repair after every failure, whereas here agents absorb that uncertainty themselves. This is a failure-designed approach and shows what buyers are truly rewarding and using under real scale.

Among the users we interacted with, we did not encounter more complex use cases, which tells us that the market is still harvesting those easy-to-pick fruits. That said, there’s a substantial batch of workflows that can be automated in this way before anyone needs to tackle more challenging tasks.

Models are not the source of differentiation, context is

For founders, a more important shift is which things are becoming commodities. In the past, building a computer usage agent meant struggling with Selenium or Playwright (or more recently Stagehand), sewing together DOM or video recordings to capture a workflow. The entire execution layer is being abstracted away, just like Claude Code has abstracted away the scaffolding around coding agents. If clicking buttons is no longer the bottleneck, then it is no longer a moat.

Not surprisingly, the context and knowledge of workflows are what endures. The challenge lies not in whether agents can navigate an SAP interface, but whether they understand how a specific company actually gets work done: that internal experiential knowledge, internal terminology, preferred formats, when to escalate to whom, how to deal with failures, and how to reliably validate outputs. In practice, this context exists in standard operating procedures, in access credentials and authorizations, in test cases and guardrails for when work goes off-track, and increasingly in a single video of a person doing the work once. None of this is generic; it is all tailored to a particular company, and often even just to a single team. That said, this is precisely the type of concrete, unglamorous problem that focused startups tend to solve better than model providers, which is why we believe that the building of the next generation of agent colleagues happens at the application and context levels, not at the model level.

The buyers we spoke with confirmed this. They select vendors based on whether the product can report hours saved without adding much extra work, and whether a junior engineer can use it. For now, the moat is not frontier capabilities—but being a vendor allowed and capable of using it in scaled production.

The real turning point is economic, not just technical

Cost data is equally encouraging. Please view the above figures as orders of magnitude rather than precise quotes. Today, running an intelligent agent costs about $6 to $8 per hour of reasoning, but in reality, depending on how the stack is built, expenses can fluctuate between $3 and $15—depending on screenshot frequency, the amount of context carried, and how much work can be handed off to deterministic code. The above data describes scenarios where the agent operates the interface through screenshots, triggering frontier models, which is the most expensive mode. Well-designed stacks leave this mode for when it’s truly needed and allow cheap deterministic code to handle the repeatable parts—not every workflow can be optimized this way, but wherever it can, mixed costs will quickly drop. Thus, this comparison can be seen as a worst-case scenario; even so, agents are roughly breaking even compared to the all-inclusive rate of about $10/hour for offshore BPO, while comparing to US backend labor at around $30 to $45/hour, provides a gross margin of 70% to 80%. In actual production, stacks and real models also significantly affect actual costs.

Figure: Hourly all-inclusive cost comparison for computer usage agents, offshore BPO, and US backend labor

Source: a16z

There are similar premises regarding speed. In agent mode, agents are still slower than humans, and the gap is not small—tasks that take a person two or three minutes take an agent eight to ten minutes, and academic benchmarks show even larger gaps. The opposite is true for deterministic execution: code runs far faster than any human—but when it comes to agent work, the key is not speed. It's that agents can operate round the clock at costs only a fraction of US labor, and they can scale without hiring.

This kind of comparison holds true for BPO buyers and operations teams, but if you’re on the selling side of agent hours, the unit economic model is different, because costs in real scenarios are less predictable. The cost of sales equals reasoning plus the number of retries (i.e., failed runs still consume tokens), and as context increases or screenshot frequency rises, profit margins tighten. Service providers can manage pricing by task, by hour, or by outcome, each corresponding to different risk exposures, depending on workflow volatility. There are also practical issues like monitoring, maintenance, and manual upgrades, all of which are factored into pricing, just as when calculating human labor costs. There is yet to be a universal business model; different verticals offer different answers.

And the arithmetic will only get better—reasoning costs continue to decline, and open-source models have proven sufficiently good for more and more workflows. For any tasks that can be reliably solved by agents, embedding computer capabilities is likely to be much more convenient than human labor. So the real question is no longer whether it is economically viable, but how far the set of tasks that can be reliably solved can scale, which is precisely the direction of future developments.

Where do we go next?

In the past year, major labs and a batch of startups have invested hundreds of millions of dollars into reinforcement learning environments for computer usage—these sandboxes allow models to practice real tasks and receive rewards upon completion—companies like Mechanize, Habitat, Fleet, Chakra, Deeptune, Matrices, and Originator are constructing the foundations for training and evaluation beneath frontier models. These investments manifest as stronger reasoning abilities, better state tracking, and greater tolerance for application errors. Models still require finely-tuned stacks to withstand in generation; running caches is the most obvious example, but raw capabilities are consciously acquired through these training infrastructures and will only get better over time.

However, architecture is a different story. Today, most deployed computer usage systems in production are single-agent: single model, single task, single session. As workflows become more complex and latency becomes a constraint, multi-agent architectures begin to matter. For instance, planners break down workflows, executors parallel process sub-tasks, and long-running agents introduce their own issues: memory, trust, and a failure rate that deteriorates over time. Teams making interesting progress in this respect are all building custom orchestration because there’s currently no standard framework. The analogy with Claude Code is enlightening: when programming agents mature, a scaffolding layer emerged to abstract orchestration. For workflows utilizing computer capabilities, a similar thing is likely to happen, and this abstraction layer is one of the most interesting unresolved infrastructure issues in the field.

From here, future developments will unfold along three main lines: accuracy, latency, and costs. Accuracy is the most important, as explained above—it is the dividing line between cool demonstrations and truly solving problems—capturing anomalies, verifying work, and upgrading only when truly necessary. Latency is likely to surprise: some teams today are already shortening latency by using accessibility trees instead of screenshots. Standard Intelligence’s general computer action model has trained on an 11 million-hour video dataset to run at 30 FPS, which is an early signal indicating that the gradual screenshot cycle that drags down today’s agents is a solvable issue, not a long-term burden. Costs will continuously decline as reasoning becomes cheaper, with smaller non-frontier models taking over routine click operations. Additionally, there are safety and governance vectors (like credentials, audit logs, data retention, prompt injection, and accountability and permissions management).

Enterprises are capable of and are benefiting from computer usage agents for those narrow workflows that are large-scale, repetitive, have stable business rules, and exist only in legacy interfaces or lack APIs. Currently, they are best suited for tasks that have immediate, machine-observable success evidence, tolerable failure consequences, and clear escalation paths. But with the developments mentioned above, the progress is real and rapid, making computer usage agents applicable for a broader range of work types.

In conclusion—the future for computer usage capabilities is bright!