Some agent tasks finish before the user has time to blink. Others wait for a provider, a document, a human approval, or a long-running import. Keeping the browser request open for all of them is a recipe for timeouts and duplicate work. A queue gives the job somewhere to live after the initial request has ended.

Give the job a real identity

Create a task ID and record what was requested, who requested it, which tenant it belongs to, and what state it is in. A useful state model might include received, queued, working, waiting, completed, failed, and cancelled. The names matter less than making transitions explicit and visible.

Expect the worker to disappear

Workers crash, providers slow down, and networks lie about whether a request succeeded. Make each step restartable. Store progress and use idempotency keys around side effects so a worker can safely resume instead of starting the whole job again. Keep a maximum runtime and an attempt count so one bad task cannot consume the queue forever.

Let a person intervene without guessing

When a task is waiting for approval or missing information, show the reason, the evidence already gathered, and the action that will happen next. Give operators pause, retry, cancel, and replay controls with appropriate permissions. Users should see an honest status rather than a spinner that quietly becomes a support ticket.

Measure the queue as part of the product

Watch age, throughput, retries, dead-letter volume, approval wait time, and tasks that never reach a terminal state. A queue is not just infrastructure. It is the memory and hand-off point that lets an agent do useful work without pretending every job is instantaneous.