A 311 engineering team wants tool failures to retry with backoff before control returns to Claude. Where should that retry logic live?

Retry logic with backoff before control returns to Claude should live in the agent harness surrounding tool execution. When a 311 ticket API hiccups, the harness is the patient dispatcher that retries transient failures, applies backoff, and only then returns a tool error or success to the model. Keeping retries in the harness makes behavior consistent across tools, avoids burning model turns on mechanical retries, and prevents the model from inventing ad-hoc retry policies per conversation.

In the system prompt instructing Claude to wait and retry failed tool calls with increasing delays fails by concept: a system prompt is guidance to the model, not enforceable harness logic, and asking Claude to pause and retry itself burns model turns without controlling the network call or backoff timer. Inside a specially fine-tuned model variant that is trained to retry known tools on its own fails because model weights do not execute network calls or backoff timers; a fine-tune can change what Claude says about retrying, not make the harness actually retry a failed municipal API call. Inside the downstream API service by extending its timeout window for slow tool responses fails operationally: a longer timeout only postpones a single failure; it does not retry with backoff, return control to Claude only after exhaustion, or give the harness consistent retry behavior across tools.

Exam caveat: harness retries are for transient faults (timeouts, 429/5xx). Do not blindly retry permanent errors (4xx auth/validation) or non-idempotent writes without idempotency keys.

Operational check: wrap tool calls in harness retry with capped attempts and exponential backoff, classify retryable errors, return structured failure to Claude only after exhaustion, and alert on elevated retry rates for specific 311 endpoints.