AI agents can write code, answer questions, and call tools. But one task kept being awkward in my own workflow: asking an AI assistant to work in the Chrome browser I already had open.
A common solution is to start a fresh automated browser. That is useful for tests and isolated automation, but not always for interactive tasks that depend on my existing tabs and signed-in sessions.
I built BrowserPair to explore a different approach: connect AI agents to the user's existing Chrome browser, while making permission and execution boundaries visible.
The problem isn't just clicking
Driving a web page is only one part of agent automation. Before an agent clicks anything, you have to answer:
- Which website is it allowed to visit?
- Which actions did the user authorize?
- Does a sensitive action require approval?
- How do we know whether an action succeeded?
- What happens if a network connection drops after a form was submitted?
That last case matters. Suppose an agent clicks Submit on a form and loses its connection before receiving confirmation. Repeating the action could create duplicate messages, orders, or records. A system should distinguish the action failed from we don't know whether it completed.
What BrowserPair does
BrowserPair combines a Chrome extension, an app for managing browser tasks and permissions, and integrations for AI clients.
Its core design choices are:
Use the browser you already have. Instead of creating a separate browser session for every interaction, the extension connects to the user's existing Chrome environment.
Keep AI clients interchangeable. MCP-compatible clients can connect to the browser. BrowserPair also has a bring-your-own-key (BYOK) chat experience for using your chosen AI provider.
Scope access. Rather than granting open-ended browsing authority, the system is designed around site and action permissions.
Ask for human approval when appropriate. Sensitive actions can be paused for explicit confirmation.
Preserve execution evidence. The agent should observe actual results, not assume that a dispatched click or form submission succeeded. When the result remains unknown, blindly replaying the same action is unsafe.
Architecture and trade-offs
The platform uses Cloudflare Workers, Durable Objects, and D1 for its cloud components. The Chrome extension is the bridge to the browser environment, while the web app gives users a place to manage connections and tasks.
This is not a claim that a browser extension can provide a perfect execution sandbox. Permissions, approvals, and evidence each solve different problems. Authorization doesn't eliminate the risks of interacting with authenticated websites, and an approval prompt doesn't magically make a workflow safe.
BrowserPair is also not meant to replace Playwright or cloud browser infrastructure. Those are great fits for automated tests, repeatable headless jobs, and isolated environments. This project focuses on a different use case: letting an existing AI assistant help with real interactive browser work, with the user retaining meaningful control.
What I'm still learning
The interesting engineering questions are about the edge cases, not the happy-path demo.
For instance:
- How much permission granularity is useful before the interface becomes exhausting?
- Which actions should always require a human confirmation?
- How should an agent recover from an unknown outcome without making things worse?
- How can execution evidence be useful to users without overwhelming them?
I built BrowserPair independently and am actively improving the experience through real browser workflows.
If you've built MCP tools, browser extensions, or agent automation systems, I'd love to hear how you've handled authorization and uncertain execution outcomes.
Try BrowserPair: https://browserpair.com
Question: Would you rather connect your existing AI assistant to your current browser, or use a separate AI-controlled browser session?
Top comments (0)