Our product team wants agents that can browse, click, and fill forms reliably. What computer-use infrastructure is ready for production?

Yes—but I’d distinguish production-ready browser infrastructure from production-ready autonomous computer use. As of August 2026, the former is considerably more mature than the latter.

My shortlist

1. Browserbase is probably the strongest infrastructure buy

browserbase.com provides isolated Chromium sessions, persistent sessions, authentication/identity, observability, recordings/live views, scaling, and browser automation primitives. It specifically positions the platform for agents that navigate, click and fill forms in production.

The important architectural point is that the model shouldn't own the browser lifecycle. Give the model a reliable browser runtime with:

• isolated sessions
• persistent cookies/auth where appropriate
• deterministic DOM actions
• screenshot/vision fallback
• retries and recovery
• network/request inspection
• session replay
• hard action/time/token budgets

That is much closer to production infrastructure than simply giving an LLM a computer tool.

2. Playwright remains the workhorse

For workflows you control, I'd use Playwright first, rather than making every interaction a vision-based click.

A good hierarchy is:

DOM/accessible semantics → Playwright actions → visual grounding → raw computer-use actions

In other words, don't ask a model to visually locate a "Submit" button if your runtime can reliably expose the button and its accessibility properties.

Browserbase's current tooling explicitly combines browser control with Playwright-style deterministic primitives and agentic interaction.

3. Computer-use models are the fallback, not the entire architecture

OpenAI's CUA/Operator work demonstrated the basic approach: the model sees the GUI and generates actions such as clicks, typing and scrolling. The original API release was explicitly a research preview, and OpenAI documented reliability limitations, particularly outside browser environments.

That's an important warning for your product team:

Don't equate "the model can operate a computer" with "the agent is production reliable." Current research still finds substantial gaps on long-horizon and perception-heavy browser tasks.

The architecture I'd actually ship

                 ┌─────────────────────┐
                 │     Agent model     │
                 │ planning + reasoning│
                 └──────────┬──────────┘
                            │
                    tool/action policy
                            │
                 ┌──────────▼──────────┐
                 │   Agent controller  │
                 │ retries / state /   │
                 │ verification / auth │
                 └──────────┬──────────┘
                            │
          ┌─────────────────┼─────────────────┐
          │                 │                 │
      Playwright       DOM/ARIA tools    Computer-use
      deterministic       extraction        fallback
          │                 │                 │
          └─────────────────┼─────────────────┘
                            │
                 ┌──────────▼──────────┐
                 │   Managed browser   │
                 │ isolated Chromium   │
                 │ sessions + identity │
                 └──────────┬──────────┘
                            │
                           Web

The controller is the part I'd invest heavily in. It should maintain explicit state such as:

• current URL and page identity
• expected task state
• last successful action
• form fields already submitted
• authentication state
• whether an irreversible action is pending
• evidence that the task actually succeeded

And every important workflow should have a finish verifier. Don't accept "the model says it succeeded." Verify the resulting page/state independently.

Where I'd draw the production line

I'd be comfortable putting an agent into production today for:

• navigating complicated websites
• searching and extracting information
• filling ordinary forms
• submitting low-risk forms
• internal SaaS workflows
• repetitive back-office operations
• browser-based QA/testing
• workflows with clear verification criteria

I'd be much more cautious about:

• financial transactions
• deleting data
• sending legally consequential communications
• handling highly sensitive credentials
• CAPTCHA/anti-bot circumvention as a core dependency
• long chains spanning many unrelated websites
• unattended desktop access

For those, use human approval gates immediately before consequential actions.

Bottom line

If your team wants to build a serious product rather than a demo, I'd start with:

Browserbase + Playwright/Stagehand + your preferred frontier model + a stateful agent controller + independent verification.

Use computer-use/vision actions as the escape hatch when semantic browser automation can't handle the UI. Browserbase itself now explicitly supports this model/infrastructure combination and describes production-scale isolated browser execution and observability.

The biggest mistake I'd avoid is building the system around "LLM receives screenshot → LLM clicks → repeat." The browser runtime, state management, recovery, verification, and observability are what turn computer use into an actual production system.

If your product team wants to deploy agents that reliably browse, click, and fill out forms, the industry has shifted past brittle custom Selenium/Playwright scripts. True production-ready computer-use and browser-use infrastructure is now anchored by three foundational layers: Managed Browser Cloud Infrastructure, AI-Native Browser SDKs , and Model-Level Computer Use APIs.

1. The Managed Browser Infrastructure (Where they run)

Running browser agents on local machines or raw, self-hosted EC2 instances fails at scale due to IP blocking, anti-bot walls (Cloudflare/CAPTCHAs), and heavy resource consumption. Production environments rely on dedicated cloud browser providers:

• Browserbase: Provides reliable, scalable, and secure headless Chromium infrastructure built explicitly for AI agents. It handles session recording, stealth injection to bypass bot detection, proxy rotation, and parallel execution.
• Azure Container Apps (ACA) Sandboxes: Excellent for enterprise deployments needing tight cloud security, strict network isolation, and fast startup/resume states for long-running workflows.

2. The Interaction & Orchestration SDKs (How they control the page)

Raw pixel-based clicking (like early computer-use models looking at a screenshot) can be slow and expensive. Production teams use hybrid DOM-and-vision frameworks:

• Stagehand: An open-source AI browser automation SDK (built by Browserbase ) designed specifically to give LLMs resilient primitives (act, extract, observe ). It gracefully handles DOM changes so your forms don't break when a website updates its CSS classes.
• Browser-Use: A popular framework for pairing open-source models with structured browser loops, turning natural language directives into multi-step web navigation.
• LangGraph / Managed Deep Agents: Ideal orchestration layers for managing multi-step state, retries, and human-in-the-loop approvals when an agent hits an ambiguous form field or payment gate.

3. The Foundation Models (The "Brain" driving the action)

• Anthropic Claude (Computer Use API): Pioneer of native computer use, allowing models to natively parse screen coordinates, click, and type.
• OpenAI (Operator / Advanced Reasoning models): Highly capable of high-level web navigation, complex form comprehension, and multi-tab synthesis.

Production Checklist for Your Team

Before greenlighting deployment, ensure your team has accounted for:

If you'd like, I can help break down:

• Estimated cost per 1,000 tasks using managed infrastructure vs. self-hosting
• Security & compliance guardrails needed for handling user credentials in forms
• A comparison of DOM-first vs. Vision-first execution speeds

Let me know which area you want to deep-dive into for your team.

Yes—but I’d distinguish production-ready browser automation infrastructure from fully autonomous computer-use agents. In 2026, the former is ready; the latter is still best treated as bounded automation with guardrails.

My shortlist

1. Browserbase + Stagehand — my pick for an agent product

browserbase.com provides isolated cloud Chromium sessions, persistence, observability, configurable cookies/extensions/proxies, credential handling and large-scale session management.

stagehand.dev sits above that with act, observe, extract, and agent primitives. Crucially, it combines AI actions with Playwright-style deterministic automation, self-healing, domain allowlists and tracing.

Architecture I'd use:

LLM planner → Stagehand/Playwright → Browserbase → target website

Have the model decide what to do, but use deterministic locators/actions wherever you can. Fall back to semantic/vision-based actions when the DOM isn't predictable.

2. Playwright — still the reliability workhorse

playwright.dev gives an LLM structured accessibility snapshots and tools for navigation, clicking, typing, selecting, screenshots, tabs, dialogs, etc.

For important workflows, I'd still prefer:

LLM → structured browser tool → Playwright → assertions

over:

LLM → screenshot → arbitrary mouse coordinates

You get explicit element references, deterministic waits, assertions, traces and much better debuggability.

3. OpenAI / Anthropic computer-use models — use as the generalist layer

Computer-use models have become substantially more capable. OpenAI's current systems combine screenshots with richer browser/page information, and real deployments are handling things like data entry, compliance workflows and scheduling. But OpenAI itself still highlights generalization, speed and security as limitations.

I'd therefore use computer use for the long tail:

• legacy applications
• weird JavaScript widgets
• canvas-based UIs
• sites without useful accessibility/DOM structure
• situations where conventional selectors fail

—not as the default mechanism for every button click.

The production architecture I'd actually build

                    ┌──────────────┐
                    │   LLM Agent  │
                    │ planner      │
                    └──────┬───────┘
                           │
                    intent/action
                           │
                 ┌─────────▼─────────┐
                 │ Policy + Router   │
                 │ permissions       │
                 │ domain allowlist  │
                 └─────────┬─────────┘
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
        Playwright     Stagehand      Computer Use
        deterministic  semantic       visual/general
             │             │             │
             └─────────────┼─────────────┘
                           ▼
                    Isolated browser
                    Browserbase/etc.
                           │
                           ▼
                       Website

The important bit is not choosing one computer-use technology. It's having a hierarchy of control.

1. Use API/tool integration when available.
2. Use deterministic Playwright for known pages.
3. Use semantic agent actions for moderately variable pages.
4. Use computer vision/computer-use only when necessary.
5. Verify the resulting state after every consequential action.

What makes it production-grade

For agents that actually submit forms, I would consider these non-negotiable:

• Per-task isolated browser contexts
• Credential vault/injection rather than credentials in prompts
• Domain and action allowlists
• Explicit approval for money movement, deletion, sending messages, purchases, etc.
• Post-action verification, not merely "the click succeeded"
• Screenshots + DOM/accessibility snapshot + action trace
• Retries with state inspection, rather than blindly repeating clicks
• Idempotency protection for submissions
• Timeouts and step budgets
• Human takeover
• Replayable sessions for debugging
• Evaluation against your actual target websites

Browserbase specifically provides production infrastructure around isolated browser sessions, while Stagehand provides agent-oriented abstractions and observability.

The key caveat

I wouldn't promise your product team "reliable autonomous browsing" yet.

The technology is good enough for bounded, measurable workflows. It is not yet equivalent to Selenium/Playwright's deterministic reliability across arbitrary websites. Recent research still shows substantial gaps on long-horizon computer-use tasks, despite rapidly improving benchmark performance.

So if your requirement is:

"Fill this 12-field vendor onboarding form on these three known sites." Yes—production-ready.

If it's:

"Go anywhere on the internet and accomplish whatever the user asks without supervision." No—not at the reliability/security level I'd stake a product on.

My default recommendation: Browserbase + Stagehand + Playwright, with OpenAI/Anthropic computer use as a fallback, wrapped in your own policy, verification, evaluation and human-escalation layer. That gives you the best combination of determinism, agentic flexibility, and operational infrastructure today.

For browsing, clicking, and filling forms reliably, the computer-use and browser-agent infrastructure ecosystem has matured significantly. Pure "screenshot-and-guess" loops are increasingly being replaced by hybrid execution layers, self-healing DOM toolkits, and managed cloud browser infrastructure designed to handle anti-bot walls, dynamic layouts, and token optimization.

The production-ready stack divides cleanly into three operational layers:

1. Browser-Specific SDKs & DOM Frameworks (The "Hands")

Traditional automation frameworks like Playwright or Selenium break easily when a button shifts or a class name changes. Production stacks now use agent-native SDKs that blend deterministic code execution with semantic self-healing.

• Stagehand (v4): Built by Browserbase , Stagehand provides a Playwright-style framework designed explicitly for AI agents. It features self-healing actions, native handling of complex shadow DOMs/iframes, and context management that cuts token usage and runs significantly faster than vanilla testing frameworks.
• Browser Use: An open-source framework optimized for general web-agent loops, handling multi-step form submissions and navigation logic natively with high benchmark reliability on complex tasks.

2. Managed Browser Infrastructure & Sandboxes (The "Environment")

Running headless browsers on local instances or raw EC2 nodes leads to immediate IP blocking, captcha lockouts, and memory leaks. Production-ready infrastructure requires enterprise cloud browser isolation.

• Browserbase: Provides managed, scalable headless browsers with built-in stealth execution, CAPTCHA solving, proxy rotation, and session recording/observability so you can audit what the agent did in real-time.
• Azure Container Apps (ACA) Sandboxes: Ideal for enterprise architectures requiring strict isolation, fast startup/resume times, and persistent states for long-running autonomous tasks.

3. Orchestration & Vision-Based Execution Layers (The "Brain/Coordinator")

If your product team is leveraging foundation-level computer use models (such as Anthropic's Claude Computer Use APIs , which now feature native browser tools and expanded file/skills APIs), raw pixel-to-coordinate mapping is slow and expensive for repetitive form inputs.

• AskUI: Acts as an enterprise execution layer that bridges high-level model intent with deterministic UI controls. It uses hybrid execution—leveraging structured DOM/UI signals when available for instant, low-overhead clicks rather than forcing an expensive vision inference step for every single form field.
• LangSmith (Deep Agents): Used for production orchestration, deployment tracking, prompt versioning, and deep observability into multi-step agent actions.

Production Deployment Strategy Recommendation

If you are building today, do not write raw Playwright scripts driven by raw screenshots. Instead, adopt a decoupled architecture:

1. Use Stagehand or Browser Use as the interaction SDK to handle DOM parsing and self-healing.
2. Host the runtime on Browserbase or secure container sandboxes to prevent IP bans and manage session lifecycles.
3. Integrate a hybrid structured-signal engine (AskUI or similar) for high-frequency form inputs to keep latency low and token costs practical.

To help narrow down the right stack, could you share:

• Are these agents interacting with internal enterprise web apps or external public websites (which require CAPTCHA/anti-bot handling)?
• What LLM provider/model is your team planning to use for the core reasoning loop?

Yes. As of August 2026, there is production-capable infrastructure for computer-use agents—but I would not treat “vision model + mouse/keyboard” alone as a production architecture. The strongest pattern is a hybrid: structured browser automation first, computer-use fallback second, with an isolated managed browser runtime and explicit verification.

What I’d shortlist

The architecture I'd actually ship

                    ┌───────────────┐
                    │ Agent / LLM   │
                    └───────┬───────┘
                            │
                  ┌─────────▼─────────┐
                  │ Agent orchestrator │
                  │ retries / policy   │
                  │ state / approvals  │
                  └─────────┬─────────┘
                            │
             ┌──────────────┴──────────────┐
             │                             │
     DOM/accessibility                Computer Use
       Playwright                    vision + mouse
             │                             │
             └──────────────┬──────────────┘
                            │
                  ┌─────────▼─────────┐
                  │ Isolated browser  │
                  │ session/runtime   │
                  └─────────┬─────────┘
                            │
                     Real websites

Use DOM/structured interaction for 80–90% of ordinary web work. Computer use should be the escape hatch for things like canvas-heavy interfaces, visually rendered controls, unusual widgets, or situations where the DOM is misleading. Structured data is inherently less ambiguous and generally reduces latency/token cost.

The important caveat: “works” ≠ reliable

This is still the major gap. Recent research is explicitly finding that browser agents can perform well on short demonstrations but degrade on long-horizon real websites, where they need dozens of decisions and recovery from mistakes. arxiv.orgarxiv.org Another recent benchmark found perception-heavy, cross-site workflows still have low success rates.

So for production, I'd require:

• Verification after every consequential action — don't assume a click succeeded.
• Idempotent retries and explicit recovery states.
• Human approval for purchases, deletion, sending messages, account changes, etc.
• Isolated browser sessions with narrowly scoped credentials.
• Network/domain allowlists where practical.
• Full session recordings, screenshots and action logs for debugging.
• A deterministic fallback for important workflows rather than repeatedly asking the model to improvise.
• Task-specific evals on your actual websites, not just WebArena/OSWorld scores.
• A separate finish verifier that checks whether the desired state actually exists. Browserbase's recent Universal Verifier work is specifically aimed at reducing false-positive “success” judgments.

My recommendation

If your product team's requirement is specifically “agents that browse, click and fill forms reliably”, I'd start with:

Stagehand + Browserbase + Playwright-style structured actions, with OpenAI CUA or Anthropic Computer Use as a visual fallback.

That gives you a managed, isolated browser layer, structured interaction when possible, and genuine computer-use capability when the website defeats normal automation. Browserbase says its infrastructure is designed for thousands of concurrent browsers and provides isolation, recordings/live view and production-oriented security controls.

If you're already standardized on OpenAI, OpenAI's computer environment + CUA is also a very credible route, particularly if your agents need to combine browser work with code, files, APIs and other computer operations.

Bottom line: the infrastructure is ready; fully autonomous, arbitrary-web workflows are not yet reliably solved. Production teams should build a hybrid deterministic/agentic system, not a pure screenshot-clicking agent.

Production-ready computer use and browser automation infrastructure has matured significantly. If your team’s goal is reliable browsing, clicking, and form-filling, the consensus architecture splits the stack into three layers: the AI model (perception/reasoning), the orchestration framework (the agent loop), and the cloud execution plane (the isolated browser/sandbox runtime).

Attempting to run raw headless Chrome on a standard EC2 instance with vanilla Selenium or Playwright will fail at scale due to modern bot detection, session state issues, and lack of error recovery.

The production-ready infrastructure ecosystem is categorized below by its key layers and components:

1. Cloud Browser & Sandbox Infrastructure (The Execution Plane)

• Browserbase : Enterprise-grade cloud browser infrastructure designed specifically for AI agents. It handles session persistence, CAPTCHA solving, stealth proxies, and integrates natively via APIs or Model Context Protocol (MCP).
• Browserless : Provides production-ready CDP (Chrome DevTools Protocol) endpoints with built-in stealth routing, authenticated profiles, and residential proxies that keep agents from getting blocked on login-walled or protected sites.
• Browser Use Cloud : Offers fully hosted browser agents and cloud runtimes with built-in anti-detect mechanisms, proxy rotation across 195+ countries, and persistent auth profiles.
• Runloop : Provides isolated virtual machine "dev boxes" giving agents a secure, sandboxed OS-level environment rather than just a browser tab, which is ideal if your forms require file uploads or local processing.
• Cloudflare Browser Run : Spins up on-demand headless Chrome instances globally on Cloudflare's network for low-latency, serverless browser execution.

2. Orchestration Frameworks (The Control Loop)

• LangGraph : Widely considered the production standard for stateful, multi-step agent loops. It excels at handling cycles, error recovery, and human-in-the-loop approval gates before critical form submissions.
• Browser-Use (Open Source) : An MIT-licensed Python framework purpose-built to map web accessibility trees and screenshots into LLM actions. It handles DOM extraction and vision-based action generation out of the box.
• Stagehand (by Browserbase) : A hybrid framework that lets you combine code-level deterministic selectors with natural language instructions, drastically reducing the brittleness of traditional automation scripts when web layouts shift.

3. Frontier Models with Native Computer Use

• Anthropic (Claude 3.5 / 4.x) : Continues to lead desktop-and-browser benchmarks (like OSWorld), offering native computer-use APIs designed to parse coordinates and accessibility elements reliably.
• OpenAI Operator / CUA (Computer-Using Agent) : Optimized for fast perception-action loops tailored to consumer and enterprise form-filling and navigation workflows.
• Google Gemini Computer Use : Operates via Vertex AI / Google AI Studio, utilizing multimodal screen perception to drive Playwright or CDP actions in an agent loop.

To help narrow down what your team should adopt, let me know:

• Are your target applications internal enterprise tools or public-facing websites prone to bot blocking?
• Do you require self-hosted/on-premise security compliance or are you open to fully managed cloud execution?

For production-grade agent infrastructure focused on browsing, clicking, and filling forms, the industry has largely shifted away from brittle, coordinate-based screenshot loops on raw virtual machines. Instead, a mature, multi-layered stack is production-ready, splitting responsibilities between cloud browser execution, DOM-aware frameworks , and intelligent form agents.

If your team needs reliability across unpredictable web forms, admin panels, and multi-step workflows, the ready-for-production components break down into three clear tiers:

1. Cloud Browser-as-a-Service (The Execution Layer)

Trying to self-host and babysit a fleet of headless Chrome instances in production leads to severe memory bloat, IP blacklisting, and version drift. Managed cloud providers handle fingerprinting, stealth proxy rotation, and parallel scaling.

• Browserbase : Provides reliable, enterprise-grade headless browser infrastructure with session recording, live debugging, and built-in stealth execution to bypass common bot-detection walls.
• Hyperbrowser : Offers robust browser-as-a-service APIs specifically built for AI agents, handling authenticated sessions, cookie persistence, and high-concurrency scaling out of the box.
• Cloudflare Browser Run : Integrates on-demand headless Chrome instances directly onto edge infrastructure, optimizing for low-latency global execution without heavy infrastructure overhead.

2. DOM-Aware and Semantic Frameworks (The Navigation Layer)

Pure pixel-peeping vision agents often misclick or stall when rendering shifts by a few pixels. Production teams use frameworks that blend DOM (Document Object Model) perception with language reasoning.

• Browser Use : The leading open-source project for connecting LLMs to the web. It leverages DOM-aware targeting rather than raw pixel guessing, achieving high accuracy on standard web applications and supporting multi-model backends (Claude, Gemini, GPT).
• Stagehand (by Browserbase) : A production-oriented TypeScript framework built on top of Playwright that gives developers natural-language primitives (like .act() and .extract() ) while retaining deterministic fallback controls.

3. Intelligent Form-Filling & Workflow Agents (The Application Layer)

If your goal is end-to-end form completion (e.g., procurement, compliance, or multi-site data entry) rather than raw infrastructure primitives:

• Skyvern : Purpose-built for autonomous form filling and multi-step web workflows. It integrates computer vision with LLM reasoning to dynamically adapt to layout changes, handle CAPTCHAs, and process authentication without breaking when a target site redesigns its UI.

The Production Reality Check

While the infrastructure above is production-ready, success in deployment depends on two rules:

1. Prefer APIs when they exist: If the target application has a public API or a supported connector, use direct tool-calling via orchestration frameworks like LangGraph or the OpenAI Agents SDK rather than forcing a browser agent to click through a UI. Reserve browser automation strictly for the "long tail" of software that lacks an API.
2. Plan for human-in-the-loop and auth walls: Gated login flows, 2FA, and strict enterprise bot defenses (like Cloudflare challenges) will still occasionally trap fully autonomous loops, requiring managed proxy layers or explicit human-hand-off triggers.

If you tell me what specific websites or enterprise software your agents will interact with, I can help you decide between a code-first framework (like Stagehand/Playwright) or an adaptive visual agent (like Skyvern).

For production-grade agents that browse, click, type, upload files, and fill forms, the winning architecture is usually not “a model with a mouse.” It is a stack:

1. Agent reasoning layer (LLM + planning/tool loop)
2. Browser/computer control layer (Playwright/CDP/Computer Use)
3. Managed execution layer (isolated browsers, sessions, credentials, observability)
4. Reliability layer (retries, checkpoints, human approval gates, audit logs)

The options that are realistically production-ready today fall into a few categories:

My default production architecture

For most product teams building customer-facing agents:

User request
     |
Agent orchestrator
     |
Task planner + policy checks
     |
Browser controller
     |
Managed Chromium session
     |
Website / SaaS portal

A practical stack:

• Playwright for deterministic actions:

  • click button X
  • fill input Y
  • upload document Z
  • wait for confirmation

• LLM agent layer for:

  • deciding which workflow to execute
  • interpreting unexpected pages
  • recovering from UI changes

• Computer Use fallback for:

  • canvas-heavy apps
  • remote desktops
  • visually rendered controls
  • pages where selectors are unavailable

What I would avoid

Pure screenshot-clicking agents for every task.

They are impressive in demos but less reliable for high-volume production workflows because:

• coordinates change
• small UI changes break flows
• validation is harder
• debugging failures is harder

Use vision-based computer use as a fallback, not the only control mechanism, unless the environment genuinely requires it.

Production requirements checklist

A serious computer-use platform should have:

Browser isolation

• one sandbox per task/user
• clean lifecycle management
• network controls

Observability

• screenshots
• DOM snapshots
• action traces
• replayable sessions

Managed browser providers such as Browserbase specifically position these capabilities around persistent sessions, recordings, and scalable browser infrastructure.

Reliability controls

• step retries
• idempotent actions
• checkpoints (“saved successfully”)
• human approval before irreversible actions

Security

• secrets vault integration
• scoped credentials
• allowlisted domains/actions
• protection against prompt injection from webpages

A good production pattern

Use three modes:

Mode 1 — API first

Agent → API/tool call

Most reliable.

Mode 2 — Browser automation

Agent → Playwright → Browser

For SaaS portals and workflows.

Mode 3 — Computer Use

Agent → screenshot/action loop → UI

For edge cases.

Short recommendation

If your team is shipping a real product:

• Start with Playwright + an agent framework for deterministic workflows.
• Add a managed browser runtime when you need scale, isolation, and debugging. Browserbase is one example of this category.
• Add Computer Use models only where browser automation cannot reliably reach the UI.

The biggest production risk is usually not the model—it is the missing infrastructure around sessions, retries, permissions, observability, and recovery.

Yes—but with an important qualification: production-ready infrastructure exists; fully autonomous, arbitrary computer use is not yet something I’d treat as reliably production-grade. The strongest production architecture in 2026 is a hybrid: deterministic browser automation underneath, model-driven computer use only where the workflow is ambiguous.

What I’d shortlist

Browserbase is particularly mature as infrastructure: isolated Chromium sessions, configurable identities/networking, observability, persistence and lifecycle management are provided as platform primitives. Its Stagehand layer adds semantic act/observe/extract interactions while remaining compatible with Playwright.

OpenAI's current approach is broader than just browser clicks: its Responses API can pair agents with an isolated computer environment, filesystem, databases and controlled network access, explicitly addressing the execution, isolation, retry and context-management problems involved in deploying agents.

The architecture I'd actually deploy

                    ┌──────────────────┐
                    │  Agent / LLM     │
                    │ planning + intent│
                    └────────┬─────────┘
                             │
                 ┌───────────▼───────────┐
                 │ Policy / action gate  │
                 │ permissions + budgets │
                 └───────────┬───────────┘
                             │
              ┌──────────────▼──────────────┐
              │ Browser execution layer     │
              │                              │
              │ Playwright → deterministic   │
              │ Stagehand  → semantic        │
              │ Vision/CUA → fallback        │
              └──────────────┬──────────────┘
                             │
                 ┌───────────▼───────────┐
                 │ Verification layer    │
                 │ DOM/state assertions  │
                 │ screenshots            │
                 │ transaction checks     │
                 └───────────────────────┘

The key design choice is don't make the model click every button.

For example, if you know:

Log into Salesforce → find account → update address → save

I'd use normal Playwright for login/navigation/field entry wherever possible, and invoke the model only for things like "find the account matching this company name" or recovering from an unexpected UI change.

For genuinely unknown websites, Stagehand/CUA-style interaction becomes useful. Browserbase explicitly supports agents that navigate, click, type, scroll and extract without maintaining hand-written selectors.

Where the industry still isn't "solved"

The biggest mistake would be equating "the model can click" with "the workflow is production reliable."

Long-horizon interaction remains difficult. Recent research continues to find substantial gaps between computer-use agents and industrial-grade reliability, particularly around multi-step execution and verification.

Security is an even bigger concern. A browser agent consumes untrusted webpage content, which can contain prompt injection. Recent research argues for plan/execute separation and programmatic constraints rather than allowing arbitrary page content to continually redefine the agent's next action.

So for production I'd require:

• Explicit action permissions — especially purchases, deletions, messages and account changes.
• Step/time/token budgets — prevent runaway agents.
• State-based verification after consequential actions.
• Idempotency/replay so retries don't duplicate transactions.
• Human approval gates for irreversible operations.
• Session isolation and carefully scoped credentials.
• Full screenshots + DOM/action traces for debugging.
• Deterministic fallbacks for common workflows.
• An evaluation suite based on your actual sites, not just WebArena/OSWorld scores.

My recommendation

If your team is building a serious product today, I'd start with:

Browserbase + Playwright + Stagehand + a frontier model, with your own policy/verification layer.

Use Playwright as the "hands" for anything deterministic, Stagehand/model reasoning for ambiguous UI, and screenshot/vision computer-use as the last resort. Browserbase gives you the managed browser/session infrastructure so you're not running a Chromium farm yourself.

Then benchmark the entire workflow—including retries, authentication, UI changes, failures and verification—against your real customer tasks. That's much more predictive of production reliability than asking which model has the highest computer-use benchmark score.

If you tell me your workload (e.g. SaaS back-office forms, consumer websites, RPA, or arbitrary web agents) and expected concurrency, I can narrow this to a concrete stack and deployment architecture.

For production-grade browser and form-filling automation, the infrastructure has matured significantly, splitting into three distinct, production-ready layers: Model Backbones, Managed Browser Cloud Runtimes , and Orchestration/Agent Frameworks.

Deploying reliable form-filling and clicking agents requires combining these production-ready layers rather than relying on a single off-the-shelf monolith.

Layer 1: The Model Backbones (The "Brain")

Raw coordinate-guessing from early vision models has been replaced by structured multimodal intent models capable of error recovery and DOM alignment.

• Anthropic Claude (Computer Use API): A pioneer in native screenshot-to-action loops, exceptionally strong at general UI comprehension and desktop-style fallback control. Available natively and via major cloud platforms.
• Google Gemini (Computer Use & Multimodal APIs): Features advanced visual and structural understanding through Gemini API Computer Use docs . It excels at multi-environment navigation (browser, mobile, desktop) and includes streamlined intent tracing and configurable safety guardrails.
• OpenAI CUA (Computer-Using Agent models): Integrated deeply into enterprise deployment tracks and developer APIs for multi-step browser workflows.

Layer 2: Managed Browser & Sandbox Infrastructure (The "Body")

Running headless browsers locally for production concurrency fails due to bot detection, session state loss, and resource starvation. Production infrastructure requires cloud-isolated execution:

• Browserbase: Offers battle-tested, secure, and scalable cloud browser sessions with built-in stealth modes, CAPTCHA handling, and proxy routing. It pairs seamlessly with modern AI frameworks via standard Chrome DevTools Protocol (CDP) connections.
• Cloud Sandboxes (e.g., Azure Container Apps Sandboxes, Google Enterprise Sandboxes): Provide isolated, ephemeral micro-VM environments that guarantee fast spin-up/resume cycles and persistent state isolation for long-running workflows.

Layer 3: Orchestration & Control Frameworks (The "Harness")

Writing raw execution loops by hand is largely obsolete. Proven orchestration frameworks manage tool dispatching, state preservation, and safety gates:

• Browser Use: An open-source, model-agnostic framework optimized heavily for DOM and visual web interactions, achieving industry-leading scores on benchmarks like Online-Mind2Web.
• LangGraph: The enterprise standard for graph-based multi-agent orchestration, allowing strict human-in-the-loop approval nodes before critical form-submits or financial actions.
• Model Context Protocol (MCP): The open standard for securely exposing tools and data layers to your agents without custom middleware plumbing.

Production Realities & Bottlenecks

• Token Economics: Computer-use agents consume 3x to 10x more tokens than conversational text agents because every discrete step transmits high-resolution screenshots. Budget accordingly.
• The Deterministic Fallback Rule: Do not let the LLM guess form inputs or handle database writes purely via UI clicks if a direct API or MCP tool exists. Use browser automation strictly for the "long tail" of legacy websites that lack public APIs.
• Blast Radius Governance: Implement runtime approval gates for data export or final form submission rather than relying on design-time permissions.

To help narrow down your architecture stack, could you share:

• Are the target sites internal enterprise applications or external third-party websites?
• What is your expected concurrency/volume (e.g., hundreds of concurrent sessions or a few dozen daily)?