Three clickable concepts for watching — and taking over — an agent's browser, in response to Adam's Browserbase note. Built on the Cockpit v2 tokens so they drop into the existing shell. The interesting problem here isn't streaming a browser; that's solved and Adam picked the right vendor. It's that two parties can now act on the same live page, and the consequences are real. Everything below is organised around that.
Adam's sketch, built properly: shell left, live browser right. Control state is the loudest thing on screen. Every state is clickable — watch, take control, paused, stalled stream, approval gate.
Open concept A →A grid of live tiles, one per agent holding a session. Sessions needing a human sort to the front structurally. Answers "which one needs me", then promotes into the Bench.
Open concept B →Timeline-first. The viewport becomes the head of a scrubber whose track is coloured by who held control. Built for evidence, approvals and attribution.
Open concept C →They are three views of one feature, not three options to choose between. Same data source, same control model, same tokens. The only things that differ are how many sessions you are looking at and whether they are happening now:
| Live | Past | |
|---|---|---|
| Many sessions | B · Watchfloor"which one needs me?" | — |
| One session | A · Bench"work with it" | C · Record"what happened?" |
Three different questions, so all three eventually earn their place — discarding one leaves a real question with nowhere to go. That is about eventual shape, not build order; the sequence further down still stands.
The split workspace is the container. Live Browser is something you put in it. Not a neighbouring feature that connects to it — the same feature. The split is a shell-level capability; Live Browser is one pane type in its right-hand slot, alongside the others.
Correcting myself: I first described all three as "modes of one context pane". Two of them are. Watchfloor is a page you navigate to, and Record can be either. That flattening is probably what made the relationship unclear.
Same three, sequenced. This is the part that is a decision:
A fourth page covers the parts that aren't the pane itself — D · Opening it, and the split itself: the browser icon's five session states, the global Open beside command, URL-encoded split behaviour, and the mobile fallback. Read it second; it's where the honest scope of the build lives.
Adam proposes "a site-wide persistent split-workspace UI". We already designed that — it's live at split-view.pages.dev (any two Cockpit pages side by side, Khoa-requested 26 Jul) and warroom-split.pages.dev (2–3 War Room lanes). Adam's instinct to avoid a Warroom-only feature is right, and it goes one step further than he wrote: Live Browser shouldn't be a new split system at all. It should be a new pane type in the one that exists.
Correction (30 Jul). I first wrote here that the divider, resize, collapse, swap, full-screen, URL-encoded layout and mobile fallback were "all already specified" by that mock. I went and checked, and that was wrong: it has a drag splitter and two panes and nothing else. The recommendation stands — extend that system rather than build a second one — but the remaining work is larger than I implied. The missing behaviours, plus how you open a session in the first place, are designed in D · Opening it, with an honest what-exists-today table at the bottom.
The failure is a human who believes they have control typing into a field the agent is also editing — or believes they're watching while the agent has already moved on. A button labelled "Take control" is not enough, because after you click it the pane looks exactly as it did before.
So control state changes three things at once: hue (teal agent / violet you / slate nobody), the control bar's ground and left edge, and a bezel around the viewport itself. Control also gets its own token scale — it deliberately does not reuse --run, because a task can be running while the agent is paused and you hold the keyboard, and those two must never look alike.
This is the silent failure that matters. A frozen frame and a live frame of a page where nothing is happening are pixel-identical. So liveness is bound to frame arrival, never to socket state — a socket can be healthy while frames have stopped — and a stale frame is visibly degraded: desaturated, with the age stamped over it. If the stream is 8 seconds behind, you should not be able to look at it and think it's now.
Decided by Khoa, 30 Jul: no capture suppression. Adam's note asked for "enter passwords, 2FA, or sensitive information without showing it to the agent" alongside full session recording to Test Evidence. Those are the same pixels, so I raised it as a conflict. Khoa's call is that these are our own agents on our own systems, so the recording stays unbroken and the private-input mode is out of the design.
What that means in practice, stated plainly so nobody is surprised later: a session recording contains whatever was typed during it. The Playwright trace is the sharp edge — it captures DOM snapshots and network bodies, not just pixels, so a credential entered during a takeover is recoverable from the artifact, not merely visible in a frame. Anyone who can open the Test Evidence attachment can read it.
That is an acceptable trade for internal agents driving internal systems, which is the brief. Two things would change the answer, and they are worth writing down now rather than rediscovering: a session that authenticates against a customer's system rather than ours, or Test Evidence becoming shareable outside the team. Either one turns an accepted internal risk into someone else's credential in our storage.
The moment you take control, the recording contains human actions inside a session named after an agent. We have already been bitten by exactly this class of problem with agent git commits landing under a human's name. So every timeline row carries its actor, the scrubber track is coloured by who held control, and the session summary counts agent actions and your actions separately. Concept C is built around this.
Adam has approval-gating in the capability list but not in the layout. If the gate renders only in the shell, your eyes are on the browser and the request is somewhere else. In these concepts the gate is a card positioned over the element being acted on, naming the specific consequence ("visible to the public immediately and is not a draft"), with the agent paused behind it.
Adam's Focus view "automatically follows and enlarges the area where the agent is working". That fights the user the moment they scroll to look at something else. Focus should hand back on any manual scroll and offer a quiet "follow again" — auto-follow that can't be overridden is the same mistake as a chat that scrolls away from what you're reading.
| Concept | Strongest at | Costs you | Build |
|---|---|---|---|
| A · Bench | Live intervention on one agent. Control legibility. The flagship workflow Adam describes. | Doesn't scale past one session — with six agents you're tab-hopping. | Needs the provider integration + control handoff. The real v1. |
| B · Watchfloor | Triage across a fleet. Surfaces "needs you" structurally rather than by notification. | Six live streams is real cost and bandwidth. Tiles are too small to act in. | Cheap if the provider gives cheap thumbnails; expensive if each tile is a full stream. |
| C · Record | Approvals, evidence, attribution, "what happened at 3am". Works with zero live sessions. | Not for driving. It's the after-the-fact view. | Least provider-coupled — mostly Playwright trace, which we already produce. |
Bench first, as the pane type inside the existing split system, with Browserbase behind Adam's provider interface. It's the flagship workflow and it forces us to solve control handoff, which everything else depends on.
Record second, and it's more valuable than its position suggests — it's the least vendor-coupled of the three, it works when nothing is live, and it's the piece that makes agent browser work admissible as Test Evidence. Given how much of our delivery pain has been "what actually happened", I'd argue it earns its place before the Watchfloor.
Watchfloor last, once we know what a live tile actually costs per session. If thumbnails are expensive, the same triage job can be done with static last-frame captures and the design barely changes.
Sana · design · 30 Jul 2026 · concepts, not a build spec. Nothing here is wired to a browser provider; the states are mocked so the interaction can be judged before we commit to Browserbase.