Background subagents die permanently on transient server-side rate limits instead of retrying with backoff

Summary

Background subagents (Agent tool with run_in_background: true) die permanently when the API returns a transient server-side rate limit, surfacing API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited as their final result. The error text itself identifies the condition as temporary and not the user's quota — yet the agent loop treats it as terminal, the task completes "successfully" with the error string as its result, and all in-flight work/context is lost.

Observed

Two consecutive background drivers for a long autonomous orchestration task (driving an 11-job multi-model workflow) died the same way, hours apart:

| attempt | lifetime | tool uses | final result |
|---|---|---|---|
| 1 | 129 s | 27 | API Error: Server is temporarily limiting requests (not your usage limit) · Rate limited |
| 2 (relaunch) | 44 s | 14 | same |

Both agents had made real progress (claimed work leases, written draft files) that was orphaned when they died — external lease-based systems then reaped their sessions, compounding the loss.

Expected

• Transient throttles (429/overloaded/"temporarily limiting") should be retried inside the agent loop with exponential backoff — at minimum a few attempts over tens of seconds — before giving up. An interactive session survives these; background agents should too (arguably more important for them, since nobody is watching).
• If retries are exhausted, the task should end as resumable/failed-transient (e.g., relaunchable with its transcript, or reachable via SendMessage) rather than completed with an error string as the result — the orchestrating session currently can't distinguish "agent finished" from "agent died at startup" without parsing the result text.

Impact

Long-running autonomous background work cannot survive ordinary platform weather. Orchestrators must re-spawn from scratch, losing context and re-paying cold-start tokens, and any external state the dead agent held (locks, leases, sessions) leaks.

Suggested

1. In-loop retry with backoff for explicitly-transient API errors in background agents (the error classification already exists — the message distinguishes "not your usage limit").
2. Mark rate-limit deaths as failed (transient) in the task notification rather than completed.
3. Optionally: auto-resume option (retry_on_transient: true) or transcript-preserving relaunch.