An unreleased prototype Raj built to support long browser workflows. It supplies compressed whole-page context, tracks appearing and disappearing elements, and detects unsuccessful clicks. Raj discussed open-source, API, website, and plugin delivery as prospective options rather than completed releases.
Kushan Raj works on browser agents and the infrastructure that helps them interpret pages, execute long sequences of actions, and recover from failures. In his talk, “Browser Agents Don’t Need Better Models. They Need Better Eyes.”, he said that he had worked at Sarvam as a founding engineer for two years. The talk was presented with an ARK affiliation, though no specific role at ARK was established.
Making browser agents easier to use
Raj’s browser work begins with a practical adoption problem: although browser agents promise to handle everyday online tasks, he found that slow, uncertain interactions often made them less convenient than completing the work manually. In one browser challenge, he showed another agent taking roughly 10–20 seconds to click a Start button before reaching the first step of a 30-step sequence.
His response was to build a browser runtime that gives the model a more useful execution environment. The runtime is intended to help an agent see broader page context, plan long action sequences, identify where execution failed, and choose what to do next.
Compact whole-page context
The runtime represents a page as compact Markdown that can be supplied alongside a screenshot. In the supplied current recording transcript, Raj estimated approximately 20,000 tokens for the full document object model, or DOM, about 1,100 tokens for a screenshot, and about 1,800 tokens for the Markdown representation. Unlike the individual screenshot, which showed only part of the page, the Markdown representation covered the whole page.
These figures were estimates for one example rather than a general benchmark. Raj did not specify the extraction algorithm or fully describe what information the compressed representation might omit. The demonstration nevertheless illustrates his central idea: models may act more effectively when browser infrastructure supplies broad page context without requiring the full DOM.
Feedback about action outcomes
Raj’s runtime also tracks how the page changes during execution. It can report elements that appeared or disappeared, indicate that an obstruction was removed, and tell the agent when an attempted click did not take effect. This distinguishes issuing an action from successfully completing it and gives the model evidence it can use to revise its next step.
Raj demonstrated the approach on an Aadhaar-download interaction and a trekking-site date selector. He reported that his prototype progressed more quickly than the Claude workflows he showed while using what he described as a cheaper model. These were demonstrations, not controlled comparisons, and they do not establish a general speed or reliability advantage. The trekking example specifically showed the agent selecting and entering a date; it did not establish that a booking or payment was completed.
Prospective release options
At the time of the presentation, Raj was considering open-sourcing the prototype. He also proposed exposing it through an API that would accept a URL and a user’s intent, execute the browser task, and return the result. A website and browser plugin were mentioned as other possible interfaces. These were prospective directions rather than released products.
Raj’s broader argument is that browser-agent performance depends not only on model capability but also on the environment around the model. Compact whole-page context, long-sequence support, and explicit feedback about failed actions may make existing models faster, cheaper, and more dependable for practical browser work.
Kushan Raj argues that browser agents often waste capable models on fragmented page views and ambiguous actions. His prototype instead gives the model compact whole-page context and explicit feedback about what changed after each interaction.
A capable model can still waste time when its browser interface supplies fragmented observations and weak confirmation that actions succeeded.
For the demonstrated page, Raj compares a roughly 20,000-token DOM with an approximately 1,100-token screenshot and an approximately 1,800-token whole-page Markdown representation.
State deltas—what appeared, disappeared, became unblocked, or failed to change—give the model a clearer recovery signal than repeated screenshots alone.
The examples support an interface-design hypothesis, not a general performance result: the talk provides no controlled success-rate, latency, cost, safety, or information-loss evaluation.
▶ Watch ↗