Computer-use agents are becoming a new automation layer

AI can now operate browsers and desktop software through screenshots, clicks and typing. The capability is useful, but dependable work still requires isolation, verification, narrow authority and human control at consequential steps.

Evidence confidence94%
Hype riskHigh
Adoption stageEarly production, supervised
The 60-second answer

What is happening?

A computer-use agent operates software the way a person does: it looks at the screen, decides what to do, then clicks, types or scrolls. That makes it useful for websites and desktop programs that were never designed for AI. It also makes the system fragile. The agent can click the wrong control, lose track of the active account, repeat an action after a timeout or follow malicious instructions hidden in a webpage. The safest design gives it a small workspace, limited permissions, clear completion rules and a requirement to prove the result before moving on.

Why now

Why this trend is moving

  • 01Major AI platforms now let models see screens, click, type, scroll and operate signed-in browser or desktop sessions.
  • 02Computer use can reach legacy and proprietary software that has no stable API or connector.
  • 03New systems increasingly mix visual control with terminals, connectors, APIs and structured tools.
  • 04Benchmarks are moving from short web tasks to long, cross-application workflows with realistic state and safety checks.
  • 05Prompt injection becomes more consequential when an agent can read private data and act inside authenticated accounts.
  • 06Current product guidance increasingly recommends isolation, confirmation, supervision and tool-first execution rather than unrestricted autonomy.
What it changes

What this means in practice

  • Visual control should be treated as a compatibility layer, not as a replacement for every API or deterministic workflow.
  • A dedicated browser profile or virtual desktop should contain only the accounts and data required for the task.
  • The system must verify application state after a consequential action rather than trusting the click or the agent’s narration.
  • Retries require duplicate detection or idempotency because a second submission may create a second real-world effect.
  • Webpages, documents and emails are untrusted observations and must not gain authority over the agent’s plan.
  • Confirmation should show the exact recipient, amount, file, permission or destination that will change.
  • Evaluation should include long tasks, changed layouts, slow pages, expired sessions, prompt injection, intervention time and complete cost.
Engineering Lens

What the headline leaves out

This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.

01

How it is built

A production computer-use system begins with a bounded task contract and risk classification. It runs inside an isolated browser profile, virtual desktop or sandbox with least-privilege identities. Screenshots are combined with accessibility trees, DOM state, application metadata or structured tool output. A planner maintains constraints and expected postconditions, then selects the most precise available action path: API, connector, script or visual control. Every state-changing step is verified against the resulting application state. Purchases, messages, permission changes, disclosures and deletions pause for transaction-bound confirmation or human takeover. Screenshots, actions, tool calls, confirmations, errors and final state are retained for replay, regression and rollback.

02

How inference behaves

Computer-use models combine visual perception, GUI grounding, planning and action generation. Screenshot-based systems return cursor coordinates and keystrokes; hybrid systems can also use DOM nodes, accessibility structures, terminals, browser automation or API tools. The agent operates in a loop: observe, decide, act and re-observe. Long tasks add state management, constraint tracking, recovery and confirmation. Structured tools usually provide stronger parameter validation and outcome checks, while visual control offers broader compatibility at the cost of ambiguity, latency and environmental fragility.

03

What the tests can miss

A credible evaluation scores the resulting application state, not only the model’s proposed action or final message. It reports end-state completion, critical-step success, GUI grounding, action efficiency, postcondition verification, recovery, duplicate-action rate, constraint retention, confirmation recall and precision, prompt-injection success, sensitive-data disclosure, human intervention and complete cost. Comparisons must state the observation mode, tool access, action space, reasoning setting, step budget and evaluator. Production tests should run in reproducible copies of the real workflow and include layout changes, pop-ups, slow responses, account expiry and mid-task information.

04

What deployment involves

Start with read-only browsing or a narrow task in an isolated test tenant. Prefer connectors, APIs and deterministic browser automation for important state changes, using visual control only for GUI-only gaps. Add logged-in access one account and one workflow at a time. Require postcondition checks, bounded retries, pause and takeover controls, and confirmation at consequential boundaries. Promote updates through recorded replay, changed-layout tests, prompt-injection exercises and canaries. Remove visual steps when a safer structured interface becomes available.

05

Where the risks sit

Computer-use agents combine the risks of browsers, credentials, private files, connected applications and generative models. Indirect prompt injection can arrive through webpages, email, documents, images or downloaded files. Dedicated profiles, domain allowlists, network restrictions, least privilege, short-lived sessions, protected downloads and transaction-bound confirmation reduce exposure. The agent must treat observed content as data rather than authority. Screenshots, traces, cookies and browser state can themselves contain sensitive information and need access, retention and deletion controls.

06

What it really costs

The operating cost includes model tokens, screenshots, browser or virtual-desktop runtime, connectors, tool calls, retries, human supervision, credential administration, evaluation environments and maintenance after interface changes. A visual agent may be economical for low-volume work across systems that are expensive to integrate. It can be a poor choice for stable high-volume processes that justify an API or conventional automation. The useful denominator is a verified accepted task completed without an unintended state change, not an agent run or a successful click.

07

What the evidence supports

The capability is established and improving. OpenAI’s Computer-Using Agent, Anthropic’s computer-use tool and Google’s Project Mariner demonstrate browser or desktop action from visual observations. Product documentation now extends the pattern into signed-in browsers, Windows and macOS applications, developer APIs and hybrid tool use. The reliability boundary remains clear. OpenAI and Anthropic describe the systems as requiring confirmations, supervision or beta precautions; Google’s early Mariner description acknowledged accuracy and speed limits. OSWorld, WebArena, WorkArena, VisualWebArena and newer long-horizon benchmarks show that agents still struggle with grounding, hidden state, constraint retention, efficiency and verification. Security research and vendor system cards identify prompt injection and data exfiltration as persistent risks. The evidence supports supervised, bounded automation with strong controls—not general unattended access to a person’s digital life.

How it works in practice

Computer-use agents are becoming useful bridges into software that lacks a clean API, but the screen is a weak control surface. Reliable deployment depends on isolated environments, explicit task contracts, tool-first routing, state verification, transaction-bound confirmation, prompt-injection resistance and a complete record of every action and consequence.

Architecture Constraints Benchmarks Security Deployment
The full system

How the parts work together

The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.

  1. 01

    Task contract and risk class

    Define the intended outcome, allowed applications, prohibited actions, data boundaries, deadlines, completion evidence and which steps require a person. “Handle my inbox” is not a safe execution contract.

  2. 02

    Isolated identity and environment

    Run the agent in a dedicated browser profile, virtual desktop or sandbox with only the accounts, files and permissions needed for the task. Separate test, staging and production identities.

  3. 03

    Observation and interface model

    Capture screenshots, accessibility trees, DOM state, application metadata and structured tool output. Preserve scale, viewport, focus, window and tab state so coordinates and elements remain meaningful.

  4. 04

    Plan and state ledger

    Break the objective into verifiable steps, record assumptions and expected postconditions, and track pages, accounts, artifacts and constraints as the environment changes.

  5. 05

    Action selection

    Prefer deterministic APIs, connectors, scripts or browser automation when available. Use visual clicking for GUI-only steps, while constraining domains, applications, action types and step budgets.

  6. 06

    Execution and postcondition checks

    After each consequential step, read the resulting system state rather than trusting the click. Detect stale pages, partial form submission, unexpected dialogs, duplicate actions and navigation drift.

  7. 07

    Confirmation and human takeover

    Pause before purchases, messages, permission changes, deletions, disclosures and other state-changing actions. Show the exact recipient, amount, destination, scope or object that will change.

  8. 08

    Trace, recovery and change control

    Store screenshots, actions, tool calls, confirmations, errors and final state. Reproduce failures in a controlled environment, add regression cases and roll back model, prompt or browser changes that alter behavior.

Back-of-the-envelope planning

Estimate the limits before the demo

These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.

Long workflows multiply small action errors

workflow success ≈ Π(critical step successᵢ)

The approximation is simplified because real failures are correlated. It still shows why a browser agent that succeeds on 98% of critical steps can complete only about 67% of twenty-step workflows before recovery is considered.

  • A correct search followed by one wrong recipient can invalidate the whole task.
  • Retries improve completion only when they do not duplicate an irreversible action.
  • A verified API step can replace several fragile visual steps.

Confirmation quality needs both recall and restraint

confirmation precision = necessary confirmations ÷ all confirmations requested

An agent that confirms every click becomes unusable, while one that misses the final consequential action is unsafe. Confirmation evaluation must measure both whether risky actions are caught and whether ordinary navigation remains fluid.

  • Opening a product page should not require approval.
  • Placing the order should show the item, price, address and payment boundary.
  • Changing document permissions needs confirmation at the exact sharing scope.

Economics belong to verified completion

cost per accepted task = model, browser, tool, retry and human-review cost ÷ correctly completed verified tasks

A cheap run that silently edits the wrong record is not productive automation. Include supervision, failed trajectories, duplicate actions, recovery and the cost of maintaining isolated environments.

  • A connector may cost more per call but eliminate dozens of visual steps.
  • A long agent trace can cost more than a short manual task.
  • Human review may remain economical when it is concentrated at one high-impact boundary.
Useful because software is fragmented

The screen is a universal adapter, not a reliable API

Computer-use models can read screenshots, move a pointer, type and navigate applications built for people. That matters because many real workflows cross legacy systems, vendor portals, desktop software and websites with incomplete or unavailable APIs. OpenAI, Anthropic and Google now expose or demonstrate this capability across browsers and desktop environments.

The flexibility comes from using the same interface as a person. It also inherits every weakness of that interface: layout changes, animations, hidden state, scroll position, focus, modal dialogs, accessibility defects and ambiguous labels. A click can land correctly while the underlying business action still fails.

Treat visual operation as an adapter layer. When a stable connector, API or scripted contract exists, it usually provides stronger identity, parameter validation, idempotency and outcome verification. The agent should choose the most precise interface that can complete the step.

  • Prefer structured tools for state changes.
  • Use GUI control for software that truly lacks a safer interface.
  • Record viewport, scaling, focus and application version.
  • Do not equate a successful click with a successful business outcome.
Pixels must become actions

Grounding errors remain a basic failure mode

A computer-use model must map an instruction such as “open the latest invoice” to a specific element on a changing screen. Screenshot-only agents estimate coordinates. Other systems add DOM nodes, accessibility trees, OCR, application metadata or specialized grounding models.

Resolution and scaling matter. Anthropic’s current guidance emphasizes screenshot dimensions because coordinate errors propagate into every later action. VisualWebArena and OSWorld-G show that charts, icons, dense interfaces and fine manipulation remain difficult even when the high-level plan is correct.

Observation should be layered. Screenshots preserve appearance; accessibility and DOM structures provide names and relationships; structured tools expose authoritative values. None is complete alone. The agent also needs to know which window, tab and account is active.

  • Normalize screenshot and coordinate spaces.
  • Combine visual and semantic observations where available.
  • Detect focus, tab and window changes.
  • Re-observe after dynamic pages settle before acting again.
The interface does not show everything

Long tasks fail when the agent loses state, constraints or intent

OSWorld 2.0 extends computer-use evaluation into workflows that take people more than an hour and require hundreds of actions. Its reported failures are not limited to clicking. Agents lose constraints, miss information arriving mid-task, guess instead of asking and skip final verification.

A durable plan needs a state ledger: which source supplied a value, which account is active, which rows were already changed, which files were downloaded and which assumptions remain unresolved. The ledger should be compact enough to stay usable but detailed enough to prevent duplicate or contradictory work.

The agent should ask when hidden state matters. Guessing a billing period, recipient, folder or account can be more damaging than stopping. A task contract should define which ambiguities may be resolved automatically and which require clarification.

  • Track constraints separately from narrative reasoning.
  • Use explicit postconditions for every state-changing step.
  • Mark unresolved assumptions rather than silently filling them.
  • Support checkpoint and resume without repeating completed actions.
Execution needs evidence

Postcondition checks matter more than confident narration

A model may report success after clicking Submit even though the page showed a validation error, timed out or saved a partial record. Reproducible benchmarks such as WebArena score the resulting application state rather than the agent’s explanation. Production systems need the same discipline.

Verification can inspect confirmation pages, database state, sent-message folders, generated files, API responses or application-specific signals. It should distinguish a reversible navigation error from a duplicated payment, deleted record or message sent to the wrong person.

Recovery rules belong in the workflow before execution begins. Safe retries require idempotency keys, duplicate detection or an independent query of current state. When the system cannot establish whether an action completed, it should stop and escalate rather than repeat blindly.

  • Verify the state that matters, not the visible button press.
  • Classify actions as read-only, reversible, compensatable or irreversible.
  • Check for duplicates before retrying.
  • Preserve enough evidence for a person to resume safely.
The environment contains instructions too

A webpage can attack the agent that reads it

Computer-use agents treat webpages, email, documents and application text as observations. An attacker can place instructions inside that content and attempt to redirect the agent, reveal data or trigger an unintended action. OpenAI’s agent system card treats prompt injection as a product-specific risk because the agent can combine browser access with files, connectors and other tools.

The defence cannot be one model instruction. Separate user intent from environmental content, restrict destinations and tools, classify sensitive data, screen candidate actions and require confirmation at the transaction boundary. An untrusted page should never gain authority merely because the model can read it.

Persistent browser state increases the stakes. Logged-in sessions, autofill, downloads and cookies can expose more than the current page. Use a dedicated profile, minimal connected applications and short-lived credentials for the task.

  • Treat external content as data, not authority.
  • Restrict domains, downloads and outbound destinations.
  • Disable unnecessary connectors and logged-in sessions.
  • Test indirect injection through webpages, email, documents and images.
The user remains the principal

Confirmation must bind to the exact consequence

OpenAI, Google and Anthropic all describe human control or confirmation around sensitive computer-use actions. The design detail matters. “Continue?” is weak when the user cannot see what will be sent, bought, deleted or shared.

A useful confirmation presents the final object and consequence: recipient and message, item and total, document and permission scope, file and deletion set, account and changed setting. The agent should not alter those parameters after approval without asking again.

Human takeover is also necessary for passwords, multifactor authentication, captchas, unexpected legal terms and ambiguous security warnings. Takeover should pause model observation of sensitive input where the product supports that boundary.

  • Bind approval to concrete parameters.
  • Reconfirm when the destination or scope changes.
  • Keep authentication and high-risk secrets under user control.
  • Measure missed confirmations and unnecessary interruptions separately.
One benchmark score is not a deployment case

Evaluate the workflow, not only the model

OSWorld, WebArena, VisualWebArena, WorkArena and BrowserGym provide increasingly realistic, reproducible environments. Their results show rapid improvement and a persistent gap on long, dynamic and stateful work. OSWorld-Human also highlights inefficiency: agents may take far more steps and time than a person even when they eventually succeed.

Benchmark comparisons need the exact observation mode, action space, step budget, model, reasoning setting, tool access and evaluator. A model using APIs or MCP tools is not directly comparable with one restricted to screenshots and mouse clicks.

Deployment evaluation should replay the organization’s own workflows in isolated copies. Include changed layouts, slow pages, pop-ups, expired sessions, mid-task messages, conflicting records and tasks that should be refused or escalated.

  • Report end-state success and partial progress.
  • Measure steps, latency, retries and human intervention.
  • Separate GUI-only from tool-assisted results.
  • Run security and confirmation tests alongside capability tests.
Automation creates a new operating surface

Maintenance and supervision decide whether the agent saves work

A browser agent requires more than a model call. Teams maintain browser images, profiles, extensions, site allowlists, login procedures, selectors or grounding prompts, traces, evaluation environments and incident response. Live websites change without notice.

Visual agents can be valuable where integration cost is otherwise prohibitive or where a person already spends time moving information between systems. They are less attractive for high-volume stable processes that deserve a direct API or conventional automation.

Measure cost against verified accepted work. Include model tokens, screenshots, browser runtime, tool calls, failed trajectories, review time, credential administration and break-fix maintenance. The best design is often hybrid: structured tools for important state changes and computer use for the few GUI-only gaps.

  • Compare against API, RPA and manual baselines.
  • Track maintenance caused by interface changes.
  • Concentrate human review at consequential boundaries.
  • Retire visual steps when a stable structured interface becomes available.
Test it properly

What a benchmark worth believing should report

A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.

MetricHow to measure itWhy it matters
End-state task success Verify the target application and artifacts after execution rather than accepting the agent’s final statement. A plausible trajectory can end in the wrong state.
Critical-step success Score each required state transition and identify the first point of failure. Aggregate completion hides the component that limits long workflows.
GUI grounding accuracy Test text fields, icons, menus, charts, drag operations and dense layouts across resolutions. A correct plan still fails when the action lands on the wrong element.
Action efficiency Compare agent steps and elapsed time with a validated human or deterministic trajectory. Completion that takes ten times longer may not be useful.
Postcondition verification rate Count consequential actions followed by an authoritative state check. Clicks and narration are not proof of completion.
Recovery success Inject timeouts, stale pages, dialogs, focus changes and partial completion. Real software rarely follows one clean trajectory.
Duplicate-action rate Count repeated sends, submissions, payments or edits after uncertainty and retry. Naive recovery can create a worse failure than stopping.
Constraint retention Test long workflows with changing requirements, exceptions and mid-task information. Agents often lose earlier constraints as trajectories grow.
Confirmation recall Measure whether every policy-defined consequential action pauses before execution. Missed confirmation removes the user’s final control.
Confirmation precision Measure how often requested confirmation was genuinely necessary. Excessive interruption destroys the value of automation.
Prompt-injection attack success Attempt direct, visual and indirect attacks through every observed content channel. The browser contains untrusted instructions alongside useful data.
Sensitive-data disclosure Test whether account, file and connector data can be sent to unauthorized destinations. Computer use can combine multiple private contexts in one trajectory.
Human intervention burden Record takeover, clarification, reset and review minutes by task and failure type. Hidden supervision can erase the claimed productivity gain.
Complete cost per accepted task Include inference, browser runtime, tools, retries, review, environment maintenance and incident handling. Per-call price understates the operating cost.
Product choices

Four sensible deployment patterns

01

Read-only browser copilot

Where it fits
Research, comparison and extraction where the agent can navigate but cannot submit forms or change accounts.
What you take on
Lowest action risk, although privacy and prompt injection still require controls.
02

API-first workflow with GUI fallback

Where it fits
Business processes where structured connectors handle important state and computer use fills a few legacy gaps.
What you take on
Strongest reliability, with integration work needed to maintain two action paths.
03

Isolated autonomous task runner

Where it fits
Bounded repetitive work in a dedicated profile, virtual desktop or test tenant with limited permissions.
What you take on
Scalable and reproducible, but environment images, credentials and site changes need active maintenance.
04

Supervised logged-in desktop agent

Where it fits
Low-volume complex work where a person can monitor, clarify and approve important actions.
What you take on
Broadest reach and highest exposure to private data, accidental actions and environmental attacks.
Lessons from the edge cases

Where projects usually go wrong

01

The agent clicks the right-looking element in the wrong window

What you see: The visible interface resembles the expected page but another account, tab or application has focus.

What to do: Track window, tab, origin, account and focus before every consequential step.

02

A layout change breaks grounding

What you see: Clicks miss after a responsive redesign, banner or browser zoom change.

What to do: Normalize viewport, combine semantic observations and maintain layout-variation tests.

03

The task contract is vague

What you see: The agent invents recipients, scope, priorities or completion criteria.

What to do: Require explicit outcomes, constraints and escalation rules before execution.

04

The agent trusts its own click

What you see: It reports success despite validation errors or unsaved state.

What to do: Verify authoritative postconditions after every state-changing action.

05

A retry duplicates the action

What you see: Messages, orders, records or payments are created twice.

What to do: Use idempotency, duplicate queries and stop when completion state is uncertain.

06

Web content hijacks the plan

What you see: A page or document instructs the agent to reveal information or leave the approved workflow.

What to do: Treat environmental text as untrusted data and screen actions against user intent and policy.

07

The browser profile has excessive authority

What you see: One compromised trajectory can reach email, storage, finance and administration.

What to do: Use isolated profiles, least privilege, short-lived sessions and task-specific connectors.

08

Confirmation is too generic

What you see: The user approves without seeing the final recipient, amount or permission scope.

What to do: Bind confirmation to immutable transaction parameters.

09

The agent loses constraints during a long task

What you see: Later actions violate an early date, budget, recipient or formatting requirement.

What to do: Maintain a structured constraint and state ledger with checkpoint validation.

10

The benchmark does not match production

What you see: A strong score fails on the organization’s layouts, accounts and failure conditions.

What to do: Build reproducible local evaluations from real workflows and representative changes.

11

Human supervision is hidden from the business case

What you see: Staff constantly watch, reset and correct the agent while reports call the task autonomous.

What to do: Record intervention minutes and include them in success and cost metrics.

12

Visual automation remains after a safer interface appears

What you see: A fragile click path persists even after the vendor adds an API or connector.

What to do: Review action paths periodically and migrate consequential steps to structured contracts.

Before release

A checklist you can actually use

  1. Define the exact final state and evidence of completion.
  2. List allowed applications, domains, accounts and data classes.
  3. Classify each action as read-only, reversible, compensatable or irreversible.
  4. Prefer APIs, connectors or deterministic automation before GUI control.
  5. Use a dedicated browser profile, sandbox or virtual desktop.
  6. Grant only task-specific permissions and credentials.
  7. Record viewport, scaling, focus, tab, origin and active account.
  8. Combine screenshots with accessibility, DOM or structured state where available.
  9. Maintain an explicit plan, constraint list and state ledger.
  10. Define expected postconditions for every state-changing step.
  11. Wait for page and application state to stabilize before acting.
  12. Use idempotency or duplicate detection before retrying.
  13. Treat webpage, email, document and image instructions as untrusted.
  14. Restrict outbound destinations, downloads and connected applications.
  15. Bind confirmations to exact recipients, amounts, files and permissions.
  16. Require takeover for authentication, secrets and unresolved security warnings.
  17. Provide stop, pause, resume and safe-handoff controls.
  18. Test changed layouts, slow pages, dialogs, expired sessions and mid-task updates.
  19. Run prompt-injection and data-exfiltration evaluations.
  20. Measure completion, verification, efficiency, recovery and intervention.
  21. Preserve screenshots, actions, confirmations and final state for replay.
  22. Calculate complete cost per verified accepted task.
  23. Migrate GUI steps to structured tools when safer interfaces become available.
Plain-language definitions

Terms worth knowing

Computer-use agent
An AI system that observes and operates graphical software through actions such as clicking, typing and scrolling.
GUI grounding
Mapping an instruction or target to the correct visible interface element and action coordinates.
Accessibility tree
A structured representation of interface elements, names, roles and relationships used by assistive technology and automation.
Action space
The set of operations an agent is allowed to perform, such as clicks, keystrokes, API calls or scripts.
Postcondition
The application state that must be true after an action is considered successful.
State ledger
A structured record of completed steps, constraints, artifacts, accounts and unresolved assumptions.
Idempotency
A property that allows an operation to be repeated without creating an additional unintended effect.
Human takeover
A controlled pause in which the user directly operates the browser or application.
Transaction-bound confirmation
Approval tied to the exact action parameters rather than a generic request to continue.
Watch mode
A supervision mode that requires the user to remain present while an agent operates in a sensitive context.
Indirect prompt injection
Malicious instructions embedded in external content that an agent reads while pursuing the user’s task.
Visual fallback
Using screen interaction only when a structured API, connector or automation contract is unavailable.
Trajectory
The sequence of observations, reasoning steps, actions and resulting states during a task.
Execution-based evaluation
Scoring an agent by the resulting software state rather than by its explanation or predicted action.
Intervention burden
The human time required to clarify, supervise, approve, reset or recover an agent workflow.
About the author

H. Omer Aktas

H. Omer Aktas is the independent editor and publisher of WTFIsTrending.com. He applies more than 30 years of operational, surveillance, analytics and systems experience from regulated casino environments to questions of evidence, controls, implementation risk and deployment reality.

Source trail · 37 references

Primary references and technical starting points

These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.

  1. 01 OpenAI: Computer-Using Agentopenai.com
  2. 02 OpenAI: Operator System Cardopenai.com
  3. 03 OpenAI: o3 Operator system-card addendumopenai.com
  4. 04 OpenAI: ChatGPT Agent System Carddeploymentsafety.openai.com
  5. 05 OpenAI: ChatGPT agent safety and privacy guidancehelp.openai.com
  6. 06 OpenAI: Built-in browser in the ChatGPT desktop apphelp.openai.com
  7. 07 OpenAI: Computer use and remote control for Windowshelp.openai.com
  8. 08 OpenAI: Evolving browser-based agentic workhelp.openai.com
  9. 09 Anthropic: Introducing computer useanthropic.com
  10. 10 Anthropic: Developing a computer use modelanthropic.com
  11. 11 Anthropic: Computer use tool documentationplatform.claude.com
  12. 12 Anthropic: Best practices for computer and browser useclaude.com
  13. 13 Anthropic: Computer use in Coworksupport.claude.com
  14. 14 Anthropic: Computer use personal-data processingprivacy.anthropic.com
  15. 15 Google: Gemini 2.0 and Project Marinerblog.google
  16. 16 Google: Project Mariner and the universal AI assistantblog.google
  17. 17 Google Developers: Gemini API computer use tooldevelopers.googleblog.com
  18. 18 Google Cloud: Gemini Enterprise Agent Platformcloud.google.com
  19. 19 OSWorld: Real computer environments benchmarkproceedings.neurips.cc
  20. 20 OSWorld 2.0: Long-horizon computer-use benchmarkarxiv.org
  21. 21 OSWorld-Human: Computer-use efficiency benchmarkarxiv.org
  22. 22 OSWorld-MCP: GUI and tool-invocation benchmarkarxiv.org
  23. 23 OSWorld-G: GUI grounding benchmarkosworld-grounding.github.io
  24. 24 WorkArena: Knowledge-work web-agent benchmarkproceedings.mlr.press
  25. 25 BrowserGym ecosystem for web-agent researcharxiv.org
  26. 26 WebArena: Realistic web environment benchmarkproceedings.iclr.cc
  27. 27 VisualWebArena: Realistic visual web tasksaclanthology.org
  28. 28 WebVoyager: End-to-end web agent benchmarkarxiv.org
  29. 29 SecureWebArena: Security evaluation for visual web agentsarxiv.org
  30. 30 WebChoreArena: Tedious and long web tasksarxiv.org
  31. 31 MacAgentBench: Real-world macOS desktop agentsarxiv.org
  32. 32 W3C: WebDriver specificationw3.org
  33. 33 W3C: Accessible Rich Internet Applications 1.2w3.org
  34. 34 Playwright: Actionability and automatic waitingplaywright.dev
  35. 35 OWASP: Prompt Injectiongenai.owasp.org
  36. 36 NIST AI Risk Management Frameworknist.gov
  37. 37 NIST AI 600-1 Generative AI Profilenist.gov