Show HN: Vessel Browser – An open-source browser built for AI agents, not humans(quantaintellect.com)
quantaintellect.com
Show HN: Vessel Browser – An open-source browser built for AI agents, not humans
https://quantaintellect.com/
9 comments
Interesting approach building a dedicated browser for AI agents. The browser-as-infrastructure angle makes sense — most MCP browser servers just wrap Chrome with CDP, which adds significant overhead.
One thing I've been thinking about is whether we even need a separate browser process. On macOS, Safari's AppleScript bridge lets you run JS in any tab without launching anything new. Your existing browser with all its sessions is already there.
The trade-off is obvious though: a purpose-built browser like Vessel can add agent-specific features (structured DOM output, action recording) that you'd never get from a general-purpose browser's scripting API.
How are you handling authenticated sessions? That's been the biggest pain point I've seen with headless/separate browser approaches — users have to re-login or copy cookies.
One thing I've been thinking about is whether we even need a separate browser process. On macOS, Safari's AppleScript bridge lets you run JS in any tab without launching anything new. Your existing browser with all its sessions is already there.
The trade-off is obvious though: a purpose-built browser like Vessel can add agent-specific features (structured DOM output, action recording) that you'd never get from a general-purpose browser's scripting API.
How are you handling authenticated sessions? That's been the biggest pain point I've seen with headless/separate browser approaches — users have to re-login or copy cookies.
The supervisor sidepanel concept is the right mental model — I've found that the biggest problem with agent-driven browsers isn't the automation itself, it's the human not knowing where the agent is in its reasoning loop when things go wrong.
Curious about the MCP tool schema design: with 40+ tools, are you using a flat tool registry or do you have any grouping/namespacing? I've run into issues where agents get confused when they have too many tools with similar-sounding names and start hallucinating tool calls that don't exist.
Curious about the MCP tool schema design: with 40+ tools, are you using a flat tool registry or do you have any grouping/namespacing? I've run into issues where agents get confused when they have too many tools with similar-sounding names and start hallucinating tool calls that don't exist.
This is a really good question; currently Vessel uses a flat registry, but the design is specifically oriented toward solving the hallucination problem.
The way that I manage that in Vessel is contextual surfacing. This way, the model doesn't necessarily have 40+ tools to choose from at any given time, but rather is focused toward a subset of tools that are applicable given the current page context.
Speed and efficiency are my number 1 priority with this browser so this framework may change/shift as time goes on, but this is an approach that I'm particularly interested in exploring.
The way that I manage that in Vessel is contextual surfacing. This way, the model doesn't necessarily have 40+ tools to choose from at any given time, but rather is focused toward a subset of tools that are applicable given the current page context.
Speed and efficiency are my number 1 priority with this browser so this framework may change/shift as time goes on, but this is an approach that I'm particularly interested in exploring.
Contextual surfacing is the right instinct — it's essentially dynamic tool windowing. The interesting design question is what signals you use to determine relevance: URL pattern, page content category, prior agent action, or something else?
I've been packaging reusable MCP tool schema definitions (the JSON spec layer, not implementations) as a way to give agents a consistent vocabulary across different harnesses. The hallucination problem you're solving at the surfacing layer is related but distinct from the schema consistency problem — both matter for reliable tool use in production.
I've been packaging reusable MCP tool schema definitions (the JSON spec layer, not implementations) as a way to give agents a consistent vocabulary across different harnesses. The hallucination problem you're solving at the surfacing layer is related but distinct from the schema consistency problem — both matter for reliable tool use in production.
Vessel primarily uses DOM content analysis to identify interactive elements on the page which then indicates which sort of tools might be relevant to surface to the agent. URL pattern is the obvious next indicator, and prior agent action is where it gets REALLY interesting imo because that's where you start building a predictive model of what the agent needs next rather than just reacting to whatever the current state is.
Your schema work sounds pretty interesting - any links? I'd be curious to check it out!
Your schema work sounds pretty interesting - any links? I'd be curious to check it out!
I've used agents extensively in my workflows for the better part of the last year - the biggest pain point was always the browser. Every tool out there assumes a human operator with automation bolted on. I wanted to flip that - make the agent the primary driver and give the human a supervisory role.
Enter: Vessel Browser - an Electron-based browser with 40+ MCP-native tools, persistent sessions that survive restarts, semantic page context (agents get structured meaning, not raw HTML), and a supervisor sidepanel where you can watch and control exactly what the agent is doing.
It works as an MCP server with any compatible harness, or use the built-in assistant with integrated chat and BYOK to 8+ providers including custom OAI compatible endpoints.
Install with: npm i @quanta-intellect/vessel-browser