## TL;DR
A triage agent that dies on a 429 mid-run loses all its progress: the fix is to expect the limit. Read the rate-limit headers, back off with the recommended wait, checkpoint progress continuously, and resume from the checkpoint instead of restarting. A rate-limited run should pause and continue, never fail and restart.

## The query

```text
triage agent hit zendesk rate limit mid-run: queue and resume
```

## Use this when

- Triage agents hit 429s mid-run
- Long jobs die on rate limits
- You are building resilient agent runs
- Auditing agent reliability

## Not for

- Learning the Zendesk API
- Designing triage classification logic
- Upgrading API rate limit tiers
- Webhook versus polling choice

## Steps

### 1. Read the rate-limit headers on every response

Track remaining calls and the reset time from the response headers. An agent that watches its budget can slow down before hitting the wall instead of crashing into it. The headers are the early warning system.

Expected output: budget tracking from response headers.

### 2. Back off on 429 with the recommended wait

When the 429 arrives, honor the retry-after: pause, then resume. Do not retry hot, do not spin. Hot retries extend the penalty and can cascade into longer blocks. The pause is the protocol.

Expected output: compliant backoff on every 429.

### 3. Checkpoint progress after every ticket

Record the last completed ticket (or page cursor) durably after each unit of work. A checkpointed run resumes from where it stopped; an uncheckpointed run restarts from zero and re-hits the limit re-doing work.

Expected output: per-ticket durable checkpoints.

### 4. Resume from the checkpoint, never restart

On startup or after backoff, read the checkpoint and continue after it. Restarting from the beginning wastes the budget on already-triaged tickets and guarantees the limit hits again sooner.

Expected output: resume-from-checkpoint on every run start.

### 5. Pace the run under the limit deliberately

Do not run at max speed and hope: insert small delays to stay comfortably under the ceiling, sized from the header data. A paced run finishes; a max-speed run 429s, backs off, and finishes later.

Expected output: deliberate pacing under the rate ceiling.

## Template: the checklist

```text
Rate-limit-resilient triage:
[ ] Rate-limit headers tracked per response
[ ] Retry-after honored on every 429
[ ] Durable checkpoint after each ticket
[ ] Resume-from-checkpoint on start
[ ] Deliberate pacing under the ceiling
```

## Variant phrasings

### zendesk 429 triage agent

Steps 1 and 2. Watch headers, honor backoff.

### agent died on rate limit mid run

Steps 3 and 4. Checkpoint, resume.

### long zendesk job rate limited

Steps 3 through 5. Checkpoint, resume, pace.

## Why it happens

Agents get built against small test datasets where the rate limit never binds, then pointed at production queues with thousands of tickets. The limit that was theoretical in testing becomes the binding constraint at 2am. Rate limits are not edge cases for production agents; they are the normal operating condition the design must assume.

## Edge cases

- Shared API budget: other integrations consume the same limit. Coordinate or allocate budgets across consumers.
- Bursty limits versus sustained: some limits allow bursts. Size pacing for the sustained rate, the stricter one.
- Checkpoints during backoff: the checkpoint must be written before the pause, or the pause loses the last unit of work.
- Limit changes: plans and tiers change ceilings. Read headers dynamically; do not hardcode the limit.

## Provenance

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