## TL;DR

The deploy failed deterministically, and the agent retried the exact same command five times. Each retry consumed quota, and the rate limit is now the second problem. Stop retrying, fix the underlying deploy error once, and give the agent a retry policy: retry only on transient errors, with backoff, and a hard cap.

## The query

```text
agent retried the failed deploy 5 times unchanged, burned the remaining rate limit
```

## Use this when

- The log shows identical deploy commands failing identically.
- The run ends in rate-limit errors.
- Nothing changed between attempts.

## Not for

- Retries with a fix between attempts (legitimate iteration).
- Transient failures that succeed on retry (correct use).
- A single failed deploy with no retries (just fix the error).

## Steps

### Step 1: Stop the agent and read the FIRST failure

The first deploy failure contains the real error. Everything after is noise.

Expected result: the underlying error is identified (validation, auth, size, whatever it is). That is the only thing to fix.

### Step 2: Wait out the rate limit

Check how long the limit lasts and pause deploy attempts until it clears.

Expected result: quota restored. Further attempts will not be auto-rejected.

### Step 3: Fix the underlying error

Address the first failure properly.

Expected result: the deploy would now succeed on the next attempt. Verify with a dry run first.

### Step 4: Give the agent a retry policy

Retries allowed only when the error is classified transient (network timeout, 5xx from the API, rate limit itself with backoff). Deterministic errors (validation, auth, config) fail the run immediately with the error surfaced.

Expected result: the agent can no longer burn quota on hopeless retries. The policy is in the runbook, not in the agent's judgment.

### Step 5: Deploy once, verify, done

Expected result: one deploy, one success, verified via the deployments list. The run ends instead of looping.

## Why it happens

'Try again' is the agent's default response to failure, and nothing told it otherwise. Deterministic failures do not become transient on repetition, but the agent has no classifier distinguishing the two. The rate limit is the bill for the missing classifier.

## Edge cases

- Some errors look transient but are deterministic (auth failures during an outage). Classify by error code and message, not by hope.
- Backoff on 429 must respect the retry-after signal, not a fixed sleep.
- The burned quota may affect other agents or teammates sharing the account. Note the shared impact in the incident log.
- Dry runs do not consume deploy quota the same way. Use them to validate fixes before the real attempt.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l49RFbOqVKbazzVaHKGtrA