# One Daemon, Many Conversations

The browser daemon had a fairness problem with a long history: it served
exactly one request at a time, in arrival order, holding the line until the
current one finished. For quick verbs — navigate, screenshot, click — nobody
noticed. The day an agent-driven `do` run took forty minutes, three other
sessions discovered they were standing in a queue behind it, and the browser
those sessions needed sat idle for most of that time, because most of a
model-driven step is spent waiting on the model, which needs no browser.

1.8.0a2 ends the serial era, and the interesting part is what it refused to
change to get there. The public API stays synchronous — every existing
script, skill, and muscle memory calls the same `BrowserAutomation` methods
with the same signatures. Underneath, the driver core is async and the
daemon runs sessions concurrently; the synchronous surface is a facade over
the async engine, not a parallel implementation that would drift from it.

The ordering rule that matters is per-session, not global: your own steps
still happen in the order you issued them, because a session's frames form
one logical conversation. What disappeared is the false coupling *between*
conversations — session B's screenshot no longer waits for session A's
forty-minute errand.

The lesson generalizes past browsers: when one worker serves many
conversations, the coupling you must break is *between* conversations, and
the compatibility you must not break is *within* one. Getting those the
right way round is the whole difference between a rewrite users celebrate
and one they have to migrate through.