Agent runs that survive the tab closing

An agent run on Kavela keeps going after you close the browser tab. The run executes server-side in a per-session durable object rather than in the page, so the tab is a viewer, not the thing doing the work. You can close it, lose your network, or switch devices, and the job continues.

That sounds like a small detail. It is the difference between agents that can do real work and agents that can only do things short enough to watch.

Why most agent runs die with the tab

The straightforward way to build an agent product is to run the loop where the user is. The page opens a stream, the model responds, tools fire, results render. It works well in a demo because a demo is thirty seconds long.

It breaks the moment a task takes real time. A research job that reads forty pages, a build that installs dependencies and runs a test suite, an overnight automation: all of these outlive the user's attention. If the run is anchored to the tab, then closing the laptop is indistinguishable from cancelling the job.

Worse, the failure is silent. Nothing errors. The user comes back, sees a half-finished transcript, and cannot tell whether the agent failed or was killed.

What we do instead

Each session gets its own durable object. The agent loop runs there, holding its own state, and the browser subscribes to a stream of events from it. If the subscriber disappears, the loop does not notice or care. When the user comes back, the client re-subscribes and replays what it missed.

This changes what a tool is allowed to depend on. A tool cannot require the client to be connected at run time, because at run time there may be no client. That rules out a whole category of convenient shortcuts, and it is worth being explicit about them:

Durable side effects have to go to durable stores. Writing a file only into the sandbox is not enough, because the sandbox sleeps. Anything that must survive gets written back through the filesystem seam to durable storage.

Credentials resolve server-side. The client supplies a secret once, at authorize time, into a credential field in the user's own session. At run time the server decrypts what it needs. A tool that tried to read a secret from the browser would work in a watched run and fail in every detached one.

Tools have to be safe to re-enter. A detached run can yield at a round boundary and resume in a fresh invocation, so a tool may execute more than once for the same logical call. External side effects are deduplicated rather than assumed to fire once.

The bug this design still let through

Being right about the architecture did not make us right about everything.

For a while, runs survived the tab closing but container builds did not. The sandbox had its own liveness rule, and the only thing keeping it awake was a websocket from the client's preview pane. Close the tab, and the agent loop carried on exactly as designed while the container it was using went to sleep underneath it.

The fix was to move liveness to where the work is. The durable object now pings the sandbox itself for as long as the loop is actively using it. The container stays alive while the agent is running and using it, and sleeps only once the loop has ended and the user is away.

The general lesson is duller than the specific one. A system is only detached-safe if every layer it touches is detached-safe. Getting the run loop right and leaving one client-anchored dependency in place produces a system that looks correct and fails on exactly the long jobs it was built for.

Why this matters if you are building agents

If you are evaluating agent platforms, this is a concrete thing to test rather than read about. Start a job that takes several minutes. Close the tab. Come back.

Either the work continued or it did not, and the answer tells you what the architecture actually is underneath the marketing.