Operations
Long-running asynchronous agent execution tracking
Agent runs and bulk operations are queued work, not blocking requests. The API returns once the work is accepted; everything after that is followed through the job's own progress record.
Open Global jobs dashboard in the consoleQueued work, not blocking requests
Starting a run does not hold an HTTP request open. The call returns once the work is accepted onto the queue, and a worker picks it up independently — so a slow run never becomes a slow API.
- The run's own record is the durable state; nothing important lives only in a worker's memory.
- A cancellation is observed by the worker rather than killing it mid-write.
- Work orphaned by a worker that disappeared is swept and made available again instead of being lost.
Following a job
Follow a long job through its progress record rather than by polling for completion: it shows where the work currently is, and a failed job stays listed with its reason instead of disappearing.
Cancelling a run
A cancellation is observed by the worker rather than imposed on it. The worker notices and stops at a boundary, so work in progress is not torn down mid-write and the run's recorded state stays coherent.
When a worker disappears
Work claimed by a worker that then vanished is swept and made available again rather than being lost. That is what keeps a crashed or restarted worker from stranding a run in a state nothing will ever pick up.
Put it into practice
Run a fleet with these guardrails on from day one.
Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.