Durable background runs start in milliseconds on the replica that accepted them

Agno's AgentOS calls wake() on its own QueueWorker right after a durable ticket commits, and the worker runs a claim pass on the spot. Earlier releases left the ticket waiting for the next poll, up to poll_interval (one second by default), which roughly doubled the time to the first event in an interactive chat.

We timed ten background runs from POST to the run reading RUNNING on both releases, using an embedded Postgres, the default poll_interval and a stub model in place of a real one:

Before  submit -> RUNNING ms: [526, 444, 91, 747, 452, 138, 763, 481, 115, 730]
        median 467 ms, max 763 ms
Now     submit -> RUNNING ms: [53, 25, 22, 23, 25, 18, 17, 23, 28, 17]
        median 23 ms, max 53 ms

Durability stays the same, since the row commits before anything is woken. A burst of submissions coalesces into one extra claim pass, a replica at its concurrency cap wakes as soon as a slot frees, and other replicas still find jobs on their own poll. The woken claim pass follows queue per session too, so it only claims the run at the head of each session.

Expect one shift on dashboards: the replica that accepts a submission now almost always runs it, where pickup used to spread across replicas. A replica at capacity still leaves the job for its peers.

Learn more about the durable queue and multi-replica deployments in the documentation.