## TL;DR
A 404 on a subscription endpoint means the thing subscribed to, or the subscription itself, no longer exists; retrying cannot resurrect it. The agent must classify 404 as terminal, verify whether the target resource and subscription exist at the provider, recreate the subscription against the correct resource, and hand the dead one to a human instead of looping forever.

```text
agent stuck: retrying a failed webhook subscription that 404s every time
```

## Use this when
- Logs show repeated webhook subscription attempts failing with 404
- The loop runs for hours or days without escalation
- The subscribed resource may have been deleted or its id changed

## Not for this skill when
- The provider is mid-incident and 404s are widespread and temporary
- The 404 is on event delivery to your endpoint, a different problem

## Steps
1. Read the exact request the agent repeats: URL, resource id, and the provider's 404 body. Verify: the missing resource or subscription is identified precisely
2. Query the provider for the resource and for existing subscriptions on it. Verify: what exists and what is gone is established from the source
3. Classify the failure in code: 404 on subscription management is terminal, not retryable. Verify: the retry policy now stops on this class
4. Recreate the subscription against the verified resource, or route to a human if the resource is genuinely gone. Verify: a working subscription exists or a human owns the decision
5. Add a repeated-terminal-error alert: the same terminal failure three times pages instead of looping. Verify: no terminal error can loop unnoticed again

## Variant phrasings
### agent retrying webhook subscription 404
A related phrasing for the same underlying problem.
### terminal 404 treated as retryable
A related phrasing for the same underlying problem.
### webhook subscription resource gone
A related phrasing for the same underlying problem.

Compatibility: Compatibility: webhook subscription management against billing, CRM, and product APIs from agent code, current versions.

## Why it happens
Retry policy is error classification. Transient errors deserve retries; existence errors deserve a different action entirely. Agents that retry everything uniformly convert a five-minute recreation task into an infinite loop that also hides the real problem in noise.

## Edge cases / pitfalls
- Some providers return 404 for permission-hidden resources. Verify with an admin-scoped read before concluding deletion.
- Recreated subscriptions may replay missed events. Ensure handlers are idempotent before recreating.
- Log the terminal classification decision; future debuggers need to know why the agent stopped.

## Provenance

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