Session Sharing — The Future of AI Browser Automation

For years, AI browser agents worked by taking screenshots of a page, deciding what to do next, and sending commands back through an API. It was slow and fragile — basically a co-pilot that could only see photos of the dashboard.

That approach is dying. Its replacement is session sharing: the AI and human work in the same browser context, sharing cookies, state, and control.

This isn't speculation. Google's Project Mariner shutdown, Cloudflare's Browser Run Live View, Browserbase's HITL templates, and ProxyHuman's core architecture all point to the same conclusion.

Two Architectures

Why Separate Visual Agents Failed

The separate-agent model ran into problems early:

Information loss

Screenshots capture pixels, not meaning. Hover states vanish. Tooltips may not render. JavaScript event handlers are invisible. Computed styles that affect layout go unseen. The agent guesses based on incomplete data.

Authentication walls

MFA codes arrive on phones. SSO flows require their own login. Tokens expire. A separate agent looking at screenshots has no way to reach any of these — it never gets past the first sign-in screen.

Latency compounding

Each step goes: capture screenshot, send it to the model, get a decision back, execute it, wait for the page to load, repeat. Ten steps means ten-plus seconds minimum, more with retries.

Cost at scale

Every screenshot sent to an LLM burns compute. Every retry adds another charge. Long workflows add up fast.

How Session Sharing Works

The setup is different:

1. Shared context. The AI agent connects to the browser via CDP (Chrome DevTools Protocol), reading DOM, cookies, localStorage, and network requests directly.
2. Direct interaction. Instead of guessing from screenshots, the agent reads the actual page structure and manipulates it programmatically.
3. Human handoff. When something needs human judgment, control passes to the human in the same session. No restart, no lost context.
4. Seamless resume. After intervention, the agent picks up where things left off.

What matters here: both the AI and the human share the same browser instance — authentication, state, history, everything. There's no translation layer between them.

Real-World Examples

ProxyHuman

Built around session sharing from the start. When an agent needs help, it mints a secure viewer link. The human opens it and sees the live browser over WebRTC — the actual session, not a stream of screenshots. They can click, type, navigate, then pass control back with a structured log of what happened. The agent continues without losing context.

Cloudflare Browser Run

Edge-hosted browser sessions with Live View mirroring. Human-in-the-loop works by passing the Live View URL to someone who takes over the same session through Slack, email, or a UI integration.

Browserbase

Managed browser sessions with HITL templates using SSE streaming. The agent pauses when it hits something it can't handle, the human reviews the live view, and execution resumes in the same session.

Auto Browser

Open-source MCP-native browser control with noVNC for visual takeover. Connect on localhost:6080 and take direct control of the running session.

Why This Matters

Session sharing changes both the economics and the user experience of browser automation.

Lower costs

No per-screenshot inference charges. Direct DOM manipulation needs far fewer model calls than interpreting images repeatedly.

Higher reliability

Working with the actual browser state instead of pixel snapshots reduces errors dramatically. Authentication works because sessions are shared. Dynamic UI changes don't confuse the agent — it reads the current DOM.

Better user experience

Humans interact naturally — clicking, typing, navigating — rather than describing actions in text for an agent to interpret visually. Handing someone the mouse feels better than telling them what to do with it.

Scalability

Multiple viewers can watch the same session at once. Team members observe, learn, and jump in when needed. Training happens as a group activity, not in isolation.

Tradeoffs

Shared sessions come with real challenges:

• Security. Shared sessions mean shared access to cookies, tokens, sensitive data. Ephemeral sessions, scoped permissions, and encryption are not optional.
• Infrastructure. Managing live browser sessions requires more infrastructure than piping screenshots.
• Concurrency. Multiple actors in one session creates conflicts. Coordination is required.

These are solvable problems. The alternatives — unreliable autonomous agents or expensive visual loops — are worse.

What to Look For in Session-Sharing Tools

• CDP compatibility. Not locked into a single provider.
• Low-latency streaming. WebRTC or similar, not delayed screenshots.
• Multi-viewer support. More than one person watching or intervening at a time.
• Action logs. Structured records of what happened during handoffs.
• Mobile access. Taking over from a phone, not just a desktop.
• Ephemeral links. Time-limited, auto-expiring for security.

Conclusion

The move away from separate visual agents toward session sharing is a practical shift, not a philosophical one. Full autonomy never worked well enough to justify its cost and unreliability. Shared sessions let AI and humans work together without fighting each other.

Google learned this with Project Mariner. Everyone else in the space is moving in the same direction. Session sharing is already the default for serious browser automation — not coming soon, but in use now. Tools built around this architecture will be the ones that ship reliably at scale.

Sources

Digital Trends, "Google Shuts Down Project Mariner", May 7, 2026

Cloudflare Browser Run documentation — developers.cloudflare.com/browser-run/

Species.gg, "Why Building Browser Agents Is Hard", Mar 2026

Industry analysis on browser agent architecture trends, 2026