Talk by Kushan Raj (Sarvam AI) arguing that the main bottleneck for browser agents is not the model but the interface between the model and the browser. He proposes three design levers: what the agent sees (a compact page representation rather than a raw dump), what it can do (fast actions with stable handles rather than one click per call), and what it learns from (step-by-step feedback rather than end-of-run pass/fail). He presents a browser-agent runtime built around these principles, reports early results where interface changes alone enabled the same model to complete multi-step workflows on hostile pages, and discusses remaining failure modes. Note: performance claims are the presenter's own and reflect early runs. # Channel Presentation Observations — Browser Agents Video (Kushan Raj, Sarvam AI) ## Creator Self-Description (Explicit Claims) - **Role/background claim**: "I am Kushan. I worked at Seraphim as a founding engineer for 2 years." (Note: title metadata attributes him to "Sarvam AI"; transcript self-identifies with "Seraphim" — possibly a transcription variant.) - **Current focus claim**: "what I'm interested in right now... is browser agents." ## Intended Audience - **Developers/technical AI audience**: content assumes familiarity with benchmarks, tokens, DOM, models, and APIs. - Evidence: discusses token counts ("The full DOM for this would be around 20,000 tokens... My markdown's about 1,800 tokens"), references "browser challenge" benchmark, Claude comparisons, and API design. - **Potential users/adopters of browser agents**: frames the problem around low adoption — "I personally have not seen that adoption, and me myself, I don't use browser agents that much." ## Claimed Scope of Content - **Technical demos and personal projects**: "I want to show you what I've been building" — demonstration-driven content. - **Product/infrastructure thesis**: "models are pretty smart, but it's the infra around them that sucks"; "give a nice environment for the agent to use." - **Future roadmap content**: open-sourcing plans, "maybe an API... give me a URL, give me your intent and I will execute it for you," or "a website or... a plugin." ## Observable Presentation Patterns (Demonstrated, Not Claimed) - **Comparative benchmarking style**: repeatedly contrasts existing agent behavior (Claude taking "2 minutes" on Aadhaar download, stuck on date selection) against the creator's own faster system ("it just boots, and boom, done"). - **Quantified technical claims**: performance framed via token counts, timing ("10-20 seconds just to click the start button"), and model cost ("I'm using a much cheaper model"). - **Mission framing**: "I want to make browser agents faster, cheaper and more reliable and just make sure everybody in the world is using them." ## Notes on Evidence Reliability - Transcript appears lightly garbled in places (e.g., "Seraphim" vs. "Sarvam AI," "not very fluent in Canada" likely meaning Kannada), so exact quotes should be treated with caution. - No curated metadata beyond the title was supplied; identity context comes solely from the title and transcript. # Delivery Observation: "Browser Agents Don't Need Better Models. They Need Better Eyes." ## Voice & Tone - **Conversational, demo-driven talk style**: opens with a casual self-intro — *"Okay, everyone. I am Kushan. I worked at Seraphim as a founding engineer for 2 years."* - **Honest, self-critical framing** rather than pure promotion: *"I personally have not seen that adoption, and me myself, I don't use browser agents that much."* - Casual, blunt vocabulary at times: *"this actually reveals, you know, why browser agents suck"*, *"it's the infra around them that sucks"*. ## Recurring Phrases & Verbal Habits - **"Right?" as a frequent tag question** — appears repeatedly: - *"Browser agents as an idea are so cool, right?"* - *"I'm using a much cheaper model, right?"* - *"So, what's next, right?"* - *"you can see the entire website, right?"* - **"Boom, done"** as a recurring punchline for successful demos — used twice: - *"it just boots, and boom, done."* - *"puts in the date and boom, done. Right?"* - **"You know" as a filler/connective** throughout: *"it reveals, you know, why browser agents suck"*, *"the feeling of seeing what's happening, you know"*. ## Teaching / Demonstration Habits - **Live demo narration with direct audience address** — repeatedly points to what's on screen: *"on my screen right now, we have the browser challenge"*, *"If you saw at the beginning of the video…"*. - **Comparison as a core teaching device**: structures each example as a before/after contrast between a baseline agent (Claude) and his own build — *"this entire process took 2 minutes, whereas in my case… it just boots, and boom, done."* - **Concrete token-count quantification** to make an abstract point tangible: *"The full DOM for this would be around 20,000 tokens… This screenshot's about 1,100 tokens. My markdown's about 1,800 tokens."* - **Explicit thesis statements**, repeated in slightly varied wording: - *"The hypothesis here is models are pretty smart, but it's the infra around them that sucks."* - *"my core thesis here has been give a nice environment for the agent to use."* - **Personal anecdotes to motivate examples**: the Aadhaar download and *"my friends and I are going trekking on… Sunday"* examples. ## Structure & Communication Pattern - **Problem → demo → thesis → roadmap → close**: 1. Adoption problem and baseline failure cases 2. His faster demos 3. Thesis restated 4. Future plans (*"I'm thinking of open sourcing this project"*) 5. Bottom-line summary: *"I want to make browser agents faster, cheaper and more reliable."* - Uses **triple-parallel lists** when summarizing: *"faster, cheaper and more reliable"*; *"where it can plan long sequences, it can figure out where it failed, what is going on."* ## Uncertainty Notes - **Delivery tone beyond text** (pace, emphasis, humor timing) is not directly observable from transcript alone; the transcript suggests casual and energetic delivery, but this cannot be confirmed. - The transcript's ordering is partly non-linear (the closing "Thank you for watching" appears mid-transcript with technical explanation following), so some structure observations may reflect transcript segmentation rather than the actual talk flow. # Position Record: "Browser Agents Don't Need Better Models. They Need Better Eyes." — Kushan Raj, Sarvam AI ## Speaker Identification - **Kushan Raj** — self-identified; founding engineer at "Seraphim" (as spoken) for 2 years. Title metadata attributes him to **Sarvam AI**. ## Core Thesis > "Models are pretty smart, but it's the infra around them that sucks." - Browser agents need a **better environment/representation**, not better models. - Kushan explicitly notes his own agent demos run on a **much cheaper model** than baselines like Claude. ## Problem Statement - Browser agents are conceptually appealing, but **adoption is low** — including his own personal use. - On a browser-agent benchmark (30-step "browser challenge"), a baseline agent took **10–20 seconds just to click the start button**. - The baseline agent spent time "debugging what's going on" — trying to click without understanding page state. ## Proposed Solution - A **compressed representation of the full page** (markdown-based) that lets the agent: - See the **entire page in few tokens** - Plan **long task sequences** - Figure out **where it failed** - Token comparison (AIS example): - Full DOM: ~**20,000 tokens** - Screenshot: ~**1,100 tokens** (shows only one snippet) - His markdown: ~**1,800 tokens** (shows the whole page) - **Feedback loop**: the system tracks the end-to-end page and reports what's new, what's gone, what blocking elements were removed, and failed click attempts. ## Demonstrated Examples (claimed by speaker) 1. **Aadhaar download**: Claude "got stuck" after the initial click, scrolling and screenshotting for ~2 minutes; his agent completed near-instantly on a cheaper model. 2. **Trekking booking site** (in "Canada" — as spoken; likely "Kannada" given context, but preserved as expressed): Claude couldn't pick a date; his agent selected the date and finished. ## Stated Qualifications & Tensions - Kushan admits browser agents are "so simple and convenient to use **in theory**" — a hedge despite the demos. - He acknowledges his **code is not super defensible**, motivating plans to **open source** the project. - Comparisons are **self-run demos**, not a formal benchmark result; no third-party validation presented. ## Next Steps (as stated) - Open source the project - Possibly expose as an **API** ("give me a URL and intent, I execute it"), a **website**, or a **plugin** - Goal: browser agents that are **faster, cheaper, more reliable** for everyone # Observation Record — Speaker Attribution & Provenance ## Video Metadata - **Title:** Browser Agents Don't Need Better Models. They Need Better Eyes. - Kushan Raj, Sarvam AI - **Video ID:** `01a15ca8-e393-742b-b5aa-446ac72f04c9` - **Curated metadata supplied:** None (transcript only) ## Speaker Inventory | Speaker | Role | Evidence | |---|---|---| | Kushan (self-identified as Kushan Raj per title) | **Creator / presenter** | Opens: "I am Kushan. I worked at Seraphim as a founding engineer for 2 years." | - **No other speakers** identified — single-speaker presentation/demonstration format. - **No narrator, guest, or third-party voices** present in the transcript. ## Creator Self-Disclosed Background - Former **founding engineer at Seraphim** for 2 years (speaker's own claim; title associates him with **Sarvam AI**, stated only in the video title, not in the transcript). ## Claimed Affiliations & Third-Party Claims - **Claude (Anthropic, unnamed as company):** Speaker presents comparison demonstrations of Claude as a browser agent failing tasks (Aadhaar download flow, Canadian trekking booking site date selection). These are the speaker's own demonstrations and characterizations. - **Browser challenge benchmark:** Referenced on screen; speaker's own description ("30 steps", slow start-button click). No external source cited by name/URL. ## Demonstrations Shown (Speaker's Own Work) - Custom browser-agent environment using a **markdown page representation** with stated token comparisons: - Full DOM: ~20,000 tokens - Screenshot: ~1,100 tokens - Speaker's markdown: ~1,800 tokens - Examples: Aadhaar download, trekking-site booking, browser challenge run. - Claims use of a **"much cheaper model"** — model identity not named. ## Promotional Segments - ⚠️ **Self-promotional segment (closing):** Speaker discusses plans to **open-source the project** and possibly ship it as an **API, website, or plugin** ("Give me a URL, give me your intent and I will execute it for you"). This is promotion of the creator's own planned product. ## Provenance Facts & Availability - **Referenced sources:** None formally cited (no URLs, papers, or named external sources). - **Comments availability:** Not stated in transcript or metadata. - **Timestamps/quotes:** Demonstrations are described narratively; precise timestamps not provided in transcript. ## Uncertainty - Speaker's name appears fully only in the video **title**; transcript gives first name only. - Roles and affiliations beyond the creator's self-description are unverified. Okay, everyone. I am Kushan. I worked at Seraphim as a founding engineer for 2 years. Let's talk about what I'm interested in right now, and that is browser agents. Browser agents as an idea are so cool, right? The browser agent should go crazy, right? I personally have not seen that adoption, and me myself, I don't use browser agents that much. I've been exploring that for some time. I've been trying to understand why that is. So, on my screen right now, we have the browser challenge. But, this is a very interesting benchmark for browser agents because there are so many things that you have to do, long rising sequencing of your tasks. And this actually reveals, you know, why browser agents suck. If you saw at the beginning of the video, the browser this agent took like maybe 10-20 seconds just to click the start button. And now, we're on step one. There are 30 steps, and it has taken so long just to click one button. Um so, enough of this. I want to show you what I've been building. So, same website. Um I've tried to sort of replicate the feeling of seeing what's happening, you know, you can see what the browser agent is thinking. But as you can see, it is so much faster and so much quicker, and I'm using a much cheaper model, right? The hypothesis here is models are pretty smart, but it's the infra around them that sucks. If you noticed in the video earlier, maybe I'll put a screenshot, the agent is trying to debug what's going on. It's trying to click something, but it doesn't understand what's going on. So, my core thesis here has been give a nice environment for the agent to use, right? So, where it can plan long sequences, it can figure out where it failed, what is going on, and it can plan the click correctly. I figured out is a cool representation which compresses the website and lets the agent see the entire page in very few few tokens. Now, I want to show you some actual examples. Let's say I want to download my Aadhaar. Um so, this is Claude trying to do it. So, I'd assume that this is very simple for a browser agent. I take a screenshot, you see the button right there, click it. Uh but then, what's interesting is that it got stuck after this point. So, from 46 seconds until the end of this video, it took a screenshot, it scrolled for some reason, it took a screenshot. Basically, this entire process took 2 minutes, whereas in my case, in our video, so, it just boots, and boom, done. And that's the beauty of a browser agent. Just how quick was that? And I'm using such a cheap model for this. Another interesting example is So, my friends and I are going trekking on on Sunday. I was wondering, you know what? Because this this site is in Canada and I am not very fluent in Canada. Like it took me some time to figure out this website. So, I asked Claude like, "Hey, can you book this for me?" And by the end of it, it's unable to pick a date and it just stuck. This is the video of my agent. You can see it selects it and puts in the date and boom, done. Right? It's so simple and convenient to use in theory. So, what's next, right? What am I planning on doing? I'm thinking of open sourcing this project because again my this code is not super defensible. The product that I want to give is again maybe an API that as you can see we were running these commands. Maybe I just want to expose this command as an API. Give me a URL, give me your intent and I will execute it for you and give it back to you and or maybe open this as a website or expose this as a plugin. But yeah, so bottom line is I want to make browser agents faster, cheaper and more reliable and just make sure everybody in the world is using them because they can just do so much for you. So yeah, that's the broad idea here. Thank you for watching. This entire markdown presents the website, that particular page. And let's actually do this interesting comparison, right? Let's go to AIS. The full DOM for this would be around 20,000 tokens. But so, let's say we have this screenshot. All right, this screenshot's about 1,100 tokens. My markdown's about 1,800 tokens and instead in one screenshot where you could see only one particular snippet, you can see the entire website, right? A couple of other things that it's important to give feedback, right? So, we say that okay, hey, these are the new things that have popped up on the page. This is now gone, right? And similarly, we can say that you know, this thing that was blocking up things that you wanted to click has now been removed. You know, we give it feedback that you tried to click this, but that didn't happen because you know, we're keeping track of the entire end-to-end browser page. Right? So, all of this together, what I built is a very clean representation that that basically compresses the website, and you can give this along with the screenshot. It's pretty cheap token-wise. Um so, the model can reason really well, and then it can construct this long sequence of tasks to execute.