The #16 was about how a single agent perceives a page — vision, accessibility tree, or runtime structural perception — and why the third one wins when the user is the user. This post is about the axis underneath that one, the part nobody names: not how the agent sees the page, but how many things are looking at it at once.
Today the answer is one. One driver per browser. That assumption is so baked in it's invisible — and it's the next thing to break.
Look at the three perception architectures from #16 and notice what they share. Vision spins up a headless browser the agent owns. Accessibility-tree agents drive a Chromium instance over DevTools Protocol — again, theirs. In both, the browser is a single-occupancy vehicle: the agent gets in, drives, gets out. The human isn't in the car. Neither is any other agent.
Runtime structural perception is the odd one out, and that difference is the whole point of this post. It runs as a peripheral to the user's own browser — the real session, already logged in. Which means the surface it reads is, by construction, a surface someone else is already on. The human is right there. The agent isn't operating a browser; it's operating the same browser.
Once that's true, "one driver" stops being a constraint and starts being a choice.
Call it BaSS — Browser-as-Shared-Space.
The claim is small to state and large in consequence: a browser tab is not one driver's cockpit. It's a surface several participants can occupy at once — you, an agent, a second agent from a different vendor — each addressing not just "the page" but individual elements by stable ID, on the same live DOM, at the same time.
surface: checkout (live, authenticated session)
el#a17 "Place order" [button]
· human — hovering, hasn't committed
· agent:claude — reading line items
· agent:codex — flagged a price mismatch on el#a09
That is a different primitive from "an agent that browses." An agent that browses is alone. BaSS is co-presence: humans and multiple agents sharing one live state, the way a shared document is one file several cursors edit — except the document is the live web app you're actually working in, with your real credentials, mid-task.
This is the part that matters architecturally. Of the three perception models, only runtime structural perception can host BaSS at all — and not by cleverness, by construction.
Vision and accessibility-tree agents each instantiate their own browser. There is no shared surface, because each participant brought their own. To put two agents and a human "in the same place," that place has to already exist and already be occupied — which is exactly what an in-session peripheral is, and exactly what a headless instance isn't. You can bolt coordination onto isolated browsers, but then you're rebuilding the shared surface in software that the in-session model gets for free.
So BaSS isn't a feature you sprinkle on any browser agent. It's only available to the architecture that was already sitting inside the user's real session. #16 argued runtime structural perception wins on cost, authentication, and real-app coverage. This is the fourth reason, and it has the longest tail: it's the only one that can be shared.
The instinct is to model this as access control: who's allowed to act, in what order. That's the wrong frame. In BaSS there's no hierarchy and no gate; participants are equals. The actual hard problem is coexistence: most of what's in a real DOM — you, foreign scripts, whatever automation the site itself runs — has no idea any protocol exists. The question isn't "who's allowed in." It's "how do independent actors share a space none of them coordinated in advance, without stepping on each other."
That's a concurrency problem on a surface no one owns. It's the interesting part, and it's most of the engineering.
Straight about status, because this series is read by people who build:
The substrate is in production. Runtime structural perception (the #16 approach), the relay that exposes it over MCP, single-agent perceive-and-act inside your real authenticated browser — shipped and running. We've already had two agents from different vendors act on one shared cart through the relay, which is the smallest honest proof that the shared part isn't a slide.
The full BaSS layer — multiple participants on one surface, element-level addressing across all of them, the coexistence logic that keeps them out of each other's way — is in active development and days from release. This post is the concept landing just ahead of the thing. The next snapshot will be the thing itself.
This is part 17 of the Runtime Snapshots series — exploring how structured browser data changes the way we build, test, and ship software. #16 mapped the three ways an agent can see a page; this one is about what happens when more than one of them is looking at the same page at once.
If you've run two agents against the same live page — what was the first thing that collided?