39 / 168 · 01 Agent Skills for Browser Automation · Under the Hood: How Playwright Became Agent-Native← prev⊞ allnext →☰ Read as one page
6.2`browser.bind()`: One Browser, Three Consumers
Before 1.59, the agent exploring your app, the test runner executing specs, and the MCP server answering ad-hoc queries each spawned their own browser. State diverged: the agent healed a test against one session while the runner failed it against another.
browser.bind() lets all three attach to the same browser instance. Practical consequences:
- The healer inspects the exact browser state that produced the failure — not a reproduction attempt.
- An agent can watch a human click through a flow (via Screencast) and then act in the same session.
- Login/state setup happens once, not three times.
This is infrastructure you get for free by staying inside the Playwright ecosystem, and it's genuinely hard to replicate when your agent tooling and your test runner come from different vendors — worth raising in any build-vs-buy discussion.