A Hacker News thread from Wednesday had 400+ comments debating whether AI agents would eliminate most knowledge work by 2027. The top comment, with something like 1,200 upvotes, said “my company bought an AI automation platform and it can’t even fill out our internal expense form.” And buried in the replies, someone pointed out the obvious reason: the agent was running in a cloud browser that had never seen the company’s SSO login page.

This keeps happening. The entire discourse around AI browser automation has a massive blind spot, and it is not about model capability or reasoning or any of the stuff people love arguing about.

Cloud browsers start from zero

Every cloud browser agent works roughly the same way. They spin up a headless Chrome instance on a server, navigate to a URL, and try to complete your task. Sounds reasonable until you think about what that Chrome instance looks like: no cookies, no saved passwords, no logged-in sessions, no extensions, no bookmarks, no history, nothing. A factory-fresh browser that knows absolutely nothing about you.

So when someone demos a cloud agent booking a flight, they are showing you a flow where the agent logs into the airline from scratch, enters credentials, handles 2FA, and builds up session state that you already have sitting in your regular browser right now. And for the demo, that works fine because it is a controlled environment with test accounts and predetermined paths. But your actual work happens behind authentication walls that are genuinely hostile to automated access, because those walls were specifically designed to stop bots, which is exactly what a cloud browser agent is.

The session state problem nobody wants to solve

I was reading Adept’s old technical blog posts the other day (before they got absorbed into Amazon) and there’s a section where they describe the challenge of maintaining browser state across tasks. They basically admit that persistent authentication is an unsolved problem for cloud-based agents. Because the options are all bad: store user credentials on your servers (security nightmare), use session tokens that expire (breaks constantly), or ask users to re-authenticate for every task (defeats the whole purpose).

And this is not some edge case. According to Okta’s 2025 report, the average knowledge worker accesses 89 different SaaS applications. Every single one of those has its own authentication, its own session management, its own way of detecting automated access. A cloud browser agent would need to maintain active sessions across all of them simultaneously, which is both a technical headache and a security liability that no enterprise compliance team would ever approve.

Your browser already solved this

The browser you are reading this in right now has all of those sessions. You logged into Gmail this morning, you are still logged into Slack, your Jira session persists across restarts because you checked “remember me” six months ago and forgot about it. That accumulated state represents hours of authentication work that happened gradually over weeks and months, and it is sitting right there in your local Chrome profile.

Local browser agents tap into that directly. No credential transfer, no session replay, no cloud relay bouncing your data through someone else’s infrastructure. Dassi runs as a Chrome extension in the side panel, which means when you ask it to draft a reply in Gmail, it reads the actual thread in your actual inbox with your actual login. There is no middle step where your email content gets shipped to a cloud browser for processing.

Speed, and also just not being annoying

Beyond the auth problem, there is a latency gap that cloud demos carefully hide. A cloud browser agent navigating a page adds network round trips for every action: screenshot the page, send it to the model, receive instructions, execute the click, screenshot again. Each cycle takes seconds. Local agents read the DOM directly, which is closer to milliseconds.

But the part that bothers me more than speed is the friction. Cloud agents require setup, API configuration, sometimes a dedicated dashboard where you define “workflows” by clicking through a visual builder. You are building an automation about your browser work in a tool that is not your browser. The indirection is crap.

The automation hype and where it actually lands

Every few months there is a new wave of “AI will automate everything” posts, usually timed to a funding round or a model release. And the demos look great because demos always look great when you control the environment. But the productivity paradox that people keep writing about, where companies adopt AI tools and do not see measurable output gains, traces back partly to this gap between demo conditions and real working conditions.

The agents that actually change how people work are the ones that operate where the work already happens. Not in a sandboxed cloud browser. Not through a workflow builder. Inside the browser you already have open, with the sessions you already have active, on the pages you are already looking at.

I do not think cloud browser agents are useless. They have legitimate applications in testing, scraping public data, running tasks that genuinely do not need authentication. But for the kind of work that the automation hype keeps promising to eliminate, the kind that involves your email and your spreadsheets and your internal tools, running AI where you already are turns out to matter more than running a smarter model somewhere else.