## TL;DR
Retry only 429, 5xx, and network timeouts. A 422 (or any 4xx except 429) means the request itself is wrong, and sending it 50 more times will fail 50 more times. On a 422, log the full response body, fix the payload, and only then try again. The retry policy needs an error-class check, not just a counter.

```text
agent retried a 422 validation error 50 times against enrichment API
```

## Use this when
- a 4xx error gets retried in a loop
- the same payload fails identically dozens of times
- retry logs show no change between attempts

## Not for this skill when
- the API is down with 5xx (retry with backoff, different concern)
- you are designing the API's validation rules
- the payload is correct and the API is misbehaving (escalate)

## Steps
1. Classify the status code before retrying: retryable is 429, 500, 502, 503, 504, and timeouts. Verify: a test 422 returns not retryable from the classifier.
2. On 422, log the status, the request payload, and the full response body. Verify: the log contains the API's actual validation message.
3. Fix the payload based on the validation message (missing field, wrong type, bad format) and send exactly one corrected attempt. Verify: the corrected payload differs from the failed one.
4. If the corrected attempt still 422s, stop and surface it to a human instead of looping. Verify: total attempts stay under 5.
5. Add a circuit breaker: 10 consecutive failures of any kind pause the job. Verify: the job halts instead of burning quota.

### Tool/version compatibility
Any HTTP client. The pattern works for enrichment APIs, CRMs, and any REST service returning standard status codes.

## Why it happens
The agent's retry logic keys off request failed without reading the status code. A blanket retry policy treats a malformed request the same as a flaky server.

## Edge cases / pitfalls
- Some APIs return 400 for rate limiting instead of 429; check the response body for rate-limit hints before giving up.
- A 422 can also mean stale data (record changed upstream); re-fetch the input before assuming your code is wrong.
- Never put 4xx retries on a fast loop; even misconfigured, they should back off.

## Variant phrasings
### Agent hammered an API with the same bad request
Short version: retried 422 fifty times.
### Validation errors triggered endless retries
Short version: no error-class check in retry logic.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-fv46qs-EcsF8-cQ-e2TJw