23.2The Design in Five Ideas

1. A single Go binary as a BiDi proxy. One ~10MB binary launches Chrome, speaks W3C WebDriver BiDi over WebSocket, and exposes ~22 CLI commands (navigate, click, type, find-all, screenshot, tab management…). No driver zoo, no language bindings required.

2. A skill, not a protocol. The vibe-check SKILL.md teaches any coding agent the full command set for a few hundred tokens — the same skills thesis this module opened with, and the same conclusion Microsoft later reached with playwright-cli install --skills.

3. Server-side actionability. The five Playwright-pioneered checks (visible, stable, receives-events, enabled, editable) run in a 100ms polling loop with a 30s timeout — but implemented once, in Go, server-side, so every client (CLI, JS, Python, MCP) gets identical behavior instead of each client library reimplementing them. Failures name the failing check ("obscured by div.modal-overlay"). This is arguably a cleaner architecture than Playwright's per-client implementation, and it's a great interview example of the "implement once at the chokepoint" principle.

4. Daemon vs oneshot. A background daemon keeps Chrome hot (~100ms per command vs ~2s cold start) for interactive agent sessions; oneshot mode gives fresh-browser isolation for CI. The daemon work surfaced a real systems problem — Chrome's 8–12 child processes get orphaned to PID 1 when the driver dies — solved with three-phase cleanup (graceful session delete → recursive tree kill → orphan sweep). Worth knowing as a systems-thinking story regardless of the tool.

5. Sense → Think → Act roadmap. V1 shipped only "Act" (the Clicker) with an MCP server built into the binary. The more ambitious pieces — Retina (a Chrome extension observing everything) and Cortex (SQLite + embeddings "app map" memory so the agent remembers your application between sessions) — remain roadmap. The persistent-app-memory idea is the one to watch: nobody has shipped it well yet, and whoever does changes the economics of exploratory agent testing.