CoChat can now use a real browser – securely, in the background

Most “AI workflows” break the moment they touch the real world.

Because the real world is… websites:

  • no APIs
  • endless login walls
  • dashboards that only exist behind SSO
  • vendor portals designed by chaos
  • UI changes every week

Today we’re shipping Browser Use as an MCP tool inside CoChat.

That means: your CoChat agents can open a real browser, navigate, click, type, download, and extract data—inside a private, isolated VMs.

And two things make this actually usable in a team setting:

  1. The browser session can be streamed (so you can see what the agent is doing).
  2. Credentials can be passed through without the LLM ever seeing them.
  3. Sessions will be remembered

This is the missing piece between “AI that writes plans” and “AI that ships work”.

What you get

1) Browser control via MCP (not a toy web-scraper)

Under the hood, the model isn’t “guessing” what happened—it’s driving an actual browser session and interacting with the page structure (the same direction the ecosystem is moving with Playwright MCP and accessibility-based browsing).

2) Private, isolated execution (Fly.io Docker session)

Every run happens in a private containerized browser session. You get the benefits of real browsing without turning your laptop into the runtime.

3) Live streaming for oversight + debugging

When an agent is doing something that matters—submitting a form, downloading invoices, updating a CRM—being able to watch it is the difference between “cool demo” and “usable tool”.

Streaming also makes debugging fast:

  • see where it hesitated
  • see what UI state confused it
  • see which step failed (and why)

4) Credential passthrough (without exposing secrets to the model)

A lot of “agent” products quietly solve auth by… handing credentials to the model.

We don’t.

With CoChat browser runs, credentials can be injected into the session without the LLM having access to the raw secret. This is what makes browser automation viable in real operations and team workflows.

Why this matters: the highest-value work still lives behind a login

When people get value from browser agents today, it’s usually in one of these buckets:

A) “No API” workflows (ops + finance)

Examples:

  • Download invoices/receipts/statements from vendor portals
  • Pull monthly usage reports from tools that don’t expose the right endpoints
  • Collect renewal dates, plan tiers, and contract details from admin consoles

This lines up with where AI web agents are gaining adoption: procurement, invoice retrieval, and cross-portal data extraction, precisely because traditional Selenium-style scripts are brittle and expensive to maintain.

B) Repetitive web ops (revenue + success)

Examples:

  • Enrich a lead list by checking each company’s website, pricing page, job posts, tech stack hints
  • Verify inbound leads aren’t students / bots / irrelevant (quick validation passes)
  • Update fields in CRMs that are “possible but painful” to do via UI

C) QA + monitoring (product + engineering)

Examples:

  • “Can a user still sign up and reach the dashboard?”
  • “Did the pricing page change?”
  • “Is the checkout flow broken in production?”
  • Generate reproducible steps from a streamed run when something fails

D) Competitive + market intelligence (growth)

Examples:

  • Monitor competitor pricing / feature pages weekly and summarize diffs
  • Track marketplace listings or app directories
  • Pull structured data from sites that block basic scraping but allow normal browsing

Where this fits with OpenClaw-style workflows

Browser access becomes really powerful when you combine it with what OpenClaw-type agents already do well: multi-step, goal-driven execution with tool calls.

High-leverage patterns that typically map well:

1) Lead sourcing → enrichment → CRM update

  • Find accounts matching ICP
  • Visit site + LinkedIn + “About” pages
  • Extract signals (industry, headcount range, hiring, pricing tier fit)
  • Write a short rationale + confidence score
  • Push to CRM / spreadsheet

2) “Portal grunt work” for finance and ops

  • Log into vendor portal
  • Download latest invoices
  • Rename files consistently
  • Upload to Drive / attach to a record
  • Post a summary in Slack/email (optional)

3) Support workflows that require web verification

  • Reproduce a reported bug in the hosted app
  • Confirm a customer configuration in an admin UI
  • Capture evidence (screenshots/steps) with the streamed session as the audit trail

4) Web-to-internal-system bridging

When the source is only accessible in a browser (admin portals, legacy tools) but the destination is structured (Linear/Jira, HubSpot/Salesforce, Airtable, internal DB).

Browser automation becomes the glue.

A few concrete prompts you can run in CoChat

  • “Open our Stripe dashboard, find failed payments from the last 7 days, and summarize top failure reasons.”
  • “Log into [vendor portal], download this month’s invoice PDFs, and upload them to our Drive folder.”
  • “Go through our signup flow as a new user, verify email, and confirm you land on the dashboard. Stream the run.”
  • “Check competitor pricing pages for changes since last week and produce a bullet diff.”
  • “Enrich this CSV of domains: pull company description, ICP fit score, and likely buyer title.”

(We strongly recommend starting with workflows that have clear success criteria—download X, verify Y, extract Z—then expanding.)

What’s next

Browser automation is one of those capabilities that’s either:

  • terrifying (if it’s uncontrolled), or
  • transformational (if it’s governed)

Our focus is making it the second one:

  • isolated runtime
  • streamable execution
  • secret-safe auth
  • team visibility

If you want to try it, reply to this email or spin up a workflow in CoChat and add the Browser MCP tool.

Ship the work. Watch it run. Keep your secrets.