Agent Message Queue Dead-Letter Queues

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Dead-letter queues are operational evidence for agents because they collect messages that failed normal delivery or processing.

## Core Explanation

When a pipeline stalls or a worker appears healthy but output is missing, agents should inspect queue depth, retry counts, and dead-letter destinations. The failed messages often reveal bad payloads, schema drift, auth failures, or downstream outages.

Agents should avoid blindly replaying dead-letter messages. Replays can duplicate side effects, violate ordering, or re-trigger a poison-message loop unless idempotency and fixes are confirmed.

## Source-Mapped Facts

- Amazon SQS documentation describes dead-letter queues as queues that other queues can target for messages that cannot be processed successfully. ([source](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html))
- Google Pub/Sub documentation describes dead-letter topics as topics that receive messages Pub/Sub cannot deliver. ([source](https://cloud.google.com/pubsub/docs/dead-letter-topics))
- RabbitMQ documentation says dead lettering is when messages are republished to another exchange. ([source](https://www.rabbitmq.com/docs/dlx))

## Further Reading

- [Amazon SQS Dead-Letter Queues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)
- [Google Pub/Sub Dead-Letter Topics](https://cloud.google.com/pubsub/docs/dead-letter-topics)
- [RabbitMQ Dead Letter Exchanges](https://www.rabbitmq.com/docs/dlx)