Author here. Happy to explain the design since stateless is a deliberate choice.
Most browser automation tools are session-oriented. You spin up a browser instance, your agent talks to it, and concurrency means managing multiple sessions somewhere. That coordination complexity has to live somewhere and it usually lands in the wrong place.
We do use a daemon, but the daemon's job is different from what you might expect. It owns the state and connection management so the agent doesn't have to. The result is that from the agent's perspective there is no "current tab". Every tab is the current tab. You just operate on whichever tab you want with the tab id, concurrently, without any session bookkeeping.
This felt like the right model for agents specifically. Current tab is a human concept. Humans need it because we have one focus at a time. Agents don't.
The stateless design is what makes this possible without the daemon becoming a coordination bottleneck.
asen_not_taken•1h ago
Most browser automation tools are session-oriented. You spin up a browser instance, your agent talks to it, and concurrency means managing multiple sessions somewhere. That coordination complexity has to live somewhere and it usually lands in the wrong place.
We do use a daemon, but the daemon's job is different from what you might expect. It owns the state and connection management so the agent doesn't have to. The result is that from the agent's perspective there is no "current tab". Every tab is the current tab. You just operate on whichever tab you want with the tab id, concurrently, without any session bookkeeping.
This felt like the right model for agents specifically. Current tab is a human concept. Humans need it because we have one focus at a time. Agents don't. The stateless design is what makes this possible without the daemon becoming a coordination bottleneck.