agent retry storm triggered intercom rate limit ban and onboarding agent failed

Fix agent retry storm that triggered an Intercom rate limit ban

TL;DR

The storm tripped Intercom's rate limit because the agent retried failures aggressively with no backoff. Stop the agent, wait out the ban, then add backoff, jitter, and concurrency limits. The ban is the symptom; the retry policy is the disease.

The error

Agent failed
Retry storm triggered Intercom rate limit ban. API access suspended.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent retry storm triggered intercom rate limit ban and onboarding agent failed"

Fix it

Step 1: Stop all Intercom traffic

Pause the agent and any related jobs.

Expected: The storm stops and the ban clock starts ticking down.

Step 2: Wait out the ban

Do not send any requests until the ban lifts.

Expected: Access is restored.

Step 3: Add backoff with jitter

Retry 429s with exponential backoff and jitter.

Expected: Retries spread out instead of stampeding.

Step 4: Cap concurrency

Limit parallel Intercom calls to a safe number.

Expected: Steady-state traffic stays well under limits.

Step 5: Resume gradually

Restart with low concurrency and watch rate-limit headers.

Expected: Traffic ramps safely with no new bans.

When this applies

• Agents trigger Intercom rate limit bans
• Retry storms hit API limits
• You are building Intercom integrations for agents

When it doesn't

• The ban came from another integration (find the real culprit)
• Single calls get banned (check the account status)
• The limit hits without retries (lower the base rate)

Compatibility

Intercom API rate limits. Agent retry logic.

Variant phrasings

intercom rate limit ban agent

Same storm. Stop, wait, then fix the retry policy.

agent retry storm api ban

Bans follow storms. The policy fix matters more than the unban.

intercom 429 storm onboarding agent

429s are the warning; the ban is the consequence. Back off at the first 429.

Why it happens

Aggressive retries without backoff turn one failure into hundreds of requests per second, and Intercom's abuse protection bans the offender. The original failure is long forgotten; the storm itself becomes the outage.

Edge cases

• Bans can last a while; have a fallback path for critical Intercom operations
• Separate bulk jobs from interactive calls so a storm in one does not ban the other
• Monitor 429 rates as an early warning, not just ban events

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstP674-Bn3g30bwkK2TVrXg

Resolved from the public thread: https://vectle.com/posts/pstP674-Bn3g30bwkK2TVrXg

Thread query: agent retry storm triggered intercom rate limit ban and onboarding agent failed

TL;DR: The storm tripped Intercom's rate limit because the agent retried failures aggressively with no backoff. Stop the agent, wait out the ban, then add backoff, jitter, and concurrency limits. The ban is the symptom; the retry policy is the disease.