by Dmitry CreedThe hottest thing in agent-land this week isn’t a new model. It’s agents driving real browsers. In the space of a few days the feed filled up: Freeact pitching “undetectable browser automation for AI agents via real browsers,” rtrvr.ai shipping an in-browser agent that bulk-enriches any webpage, and Coasty (YC S26) launching “an API for computer-use agents” that drives browsers and legacy desktops through screenshots, mouse, and keyboard.
Everyone has arrived at the same conclusion at the same time: the most useful thing an agent can do next is operate a browser like a person does. And they’re right — that’s genuinely powerful.
But there’s a question hiding under the excitement, and it’s the one that actually keeps platform teams up at night: where, exactly, do you let an agent do that?
The industry just answered its own question — with sandboxes
The tell is in the counter-current. The same week the browser-driving demos went viral, the containment story went mainstream. Perplexity unveiled SPACE , a secure sandbox platform “engineered to safely unlock the full capabilities of Perplexity Computer’s agentic AI stack while maintaining a high bar for security.” Others shipped sandbox infrastructure for autonomous agents and open-source snapshot/pause-resume VMs for computer-use agents in the same window.
That convergence is the real signal. Once you concede an agent can drive a real browser — click real buttons, type into real forms, follow real links — you’ve conceded it can do those things somewhere consequential. A browser session carries cookies, hits internal endpoints, and can reach anything the network can reach. “Let it drive a browser” and “give it a blast-radius boundary” are the same sentence. The market figured that out this week. Forge shipped it a while ago and just proved it end-to-end.
What we shipped: an agent drove a real Chrome — inside a throwaway stack
On July 19 we ran a full end-to-end proof that an agent turn, executing inside a per-run isolated Forge stack, drives a real headful Chrome: navigate to Wikipedia, type a query, run the search, and capture the article that came back. The interaction returned HTTP 200 with the real Alan Turing article — a live multi-step browser session, not a mock.
The interesting part isn’t that the agent browsed. Plenty of tools do that. The interesting part is where it browsed. The whole session ran through a browse credential signed by the isolated stack — and that credential is scoped to the isolated stack only. We proved it the boring, load-bearing way: the exact same isolated token, replayed against production browser infrastructure, returned HTTP 401. Not “was politely rate-limited.” Structurally rejected. The agent could drive a browser to its heart’s content and still had no path from its throwaway environment into anything that matters.
That’s the differentiator, and it’s the sequel to something we already wrote about: isolated stacks that tame relentlessly proactive agents . That post argued for the boundary. This one is the boundary doing a real job — containing a real browser session driven by a real agent.
We didn’t demo it once. We gated it.
Here’s the part that separates a tweet from a platform. The browser-driving capability didn’t just pass one smoke test and get a victory lap. It shipped with a QA extended-smoke gate so that future changes to the browse path automatically re-run the full end-to-end interaction. The capability isn’t “proven on the day it launched.” It’s continuously proven — every subsequent change has to walk the same navigate-type-search-capture path and clear the same isolation check before it merges.
That maps to where the agent conversation is actually maturing. The Coasty launch put it plainly: getting an agent to complete a task once is easy; the hard part is doing it repeatably, recovering from unexpected states, and producing evidence of what it did. The community is now benchmarking agent-devtool reliability as a first-class concern. A one-off demo doesn’t survive that bar. A gated capability does.
One honest caveat
We’re not going to overclaim. The July 19 run used known-selector interaction — the agent knew which field to type into and pressed Enter to search. The fully LLM-driven browser verbs (where the model itself decides what to click) need the AI gateway wired into the isolated service set, which a browser-plus-conductor-only stack doesn’t include by default. So: a real agent drove a real browser end-to-end inside a real isolated stack — verified. A model autonomously deciding every click inside that same minimal stack is the next slice, not today’s claim. We’d rather tell you the exact shape of what shipped than sell you the rounded-up version.
The takeaway
The 2026 version of “let your agent use a browser” isn’t a browser bolted onto an agent with nothing underneath. It’s a browser the agent drives inside a box with a door — and a scoped token that literally can’t open the door to production. This week the whole industry rediscovered that agents can drive browsers, and then rediscovered, one beat later, that they need a sandbox to do it in. Forge shipped both halves and proved the boundary with a 401. The browsing is the easy part. The box is the product.
Try it
See the Workflow Engine for what runs the loop, revisit how isolated stacks contain proactive agents , or reach out at [email protected] if you want agents that can drive a browser without being able to drive off a cliff.