Naviquest Architecture
Comparison (Agent with Naviquest Vs Agent using Fetch tool)

What inspired me to build Naviquest

Naviquest began with a frustration I kept running into while working with web agents. An agent could need a small piece of information from a page, yet the only way to give it that information was often to hand it the whole page. It felt wasteful, but more importantly, it felt unreliable. The useful detail could disappear inside navigation, repeated controls, boilerplate, and markup that was never meant to explain anything to a person.

I kept thinking about the browser sitting in the middle of this process. The browser has already loaded the page. It knows what is visible, what is interactive, where the headings are, and how a control relates to the surrounding content. Asking a model to reconstruct all of that from a large page dump seemed backwards. I wanted the browser to do the work it is already good at, then let the agent ask for the small piece of evidence it actually needs.

That is where Naviquest came from. I wanted an agent to be able to arrive on a page, understand what kind of place it had reached, find the relevant information, and keep track of it after the page changed. The goal was never to make an agent sound more certain. I wanted it to have a more honest relationship with the page: to point to the evidence it used, to know when it had lost its place, and to say when an answer was not there.

My work on Octocode shaped that instinct. I learned that research becomes much stronger when an agent can orient itself before it starts searching, recover the exact source for a claim, and separate what it knows from what it is guessing. I wanted to bring that discipline into the browser. A web page should not be treated as an unstructured wall of text. It has meaning in its layout, accessibility information, controls, and changes over time.

Accessibility became an important part of the project for that reason. Names, roles, headings, landmarks, and state often explain a page better than its raw markup does. At the same time, I learned not to pretend that the page reveals everything. There are parts of the browser environment that a page script cannot truly see. Rather than hide those gaps, I wanted Naviquest to name them. That choice matters to me because a tool that is confidently wrong is much less useful than a tool that can clearly describe its limits.

The project also grew out of a practical question: what does it mean for an answer to stay grounded after someone interacts with a page? Pages move. Routes change, menus open, content loads late, and controls update without a full navigation. A reference to a DOM node can become meaningless quickly. I wanted a way for an agent to return to the meaning of what it found, rather than cling to a brittle pointer from an earlier moment.

I have tried to keep the foundation simple. Naviquest starts with deterministic page understanding and retrieval because that gives me a path I can inspect and trust. Browser AI can be useful for tasks such as checking a grounded response, shortening it, translating a query, or describing content that is otherwise hard to reach. But I do not want AI in the project merely because it is available. It has to earn its place by making the research experience better without weakening the connection to evidence.

Building this has made me more interested in the difference between having less context and having better context. A smaller payload is not automatically a better answer. The real challenge is preserving the detail that matters while leaving behind the noise. That is still the question I am working on: where does browser-side research genuinely help an agent understand a page, and where does it not?

Naviquest is my attempt to explore that question in a practical way. I want browsing agents to be better, more precise, and easier to trust. I want them to ask the page for help instead of swallowing it whole. And I want their answers to remain connected to something a person can inspect for themselves, and most importantly, tokes consumption is something that I truly bellieve that can be improved, give the APIs we are having today (including Chromium AI beta features https://developer.chrome.com/docs/ai/built-in)

P.S The biggest challenge was the demo video, which wasn't able to showcase all of Naviquest's capabilities the way I intended