## TL;DR
A retry loop on a failed release usually means the agent never reads the action result: the API returns an error, perhaps the message state changed or the id is stale, and the agent schedules the same action forever. Read the response, classify the error, and stop after a small number of attempts with an escalation to a human queue. An action that cannot succeed is a case to surface, not a task to repeat.

```text
the agent kept re-quarantining the same message after its release action failed; loop detected in the retry logic
```

## Use this when
- The same message id appears in quarantine actions every run.
- Release attempts report failure in the API log but the agent retries unchanged.

## Not for this skill when
- The message is re-delivered by new mail each time, so repeated quarantine is correct. Confirm by message identity, not subject.
- The API is down for all actions. That is a platform outage, not a per-message loop.

## Steps
1. Pull the API responses for the repeated action and identify the exact error and its meaning. Verify: the failure reason is known, not inferred.
2. Check the message current state in quarantine; it may already be released, expired or re-identified, making the action impossible by design. Verify: state explains the error, or a real fault remains.
3. Add result handling: success closes the task, a permanent error escalates it, and a transient error retries with backoff up to a small cap. Verify: each class has a defined path.
4. Add a cross-run attempt counter per message and action so loops are detected even when each run thinks it is the first. Verify: the counter survives restarts.
5. Run the agent twice over the problem set. Verify: the message is actioned once or escalated, and no silent loop remains.

## Variant phrasings
### agent retry loop release action failed quarantine
The release loop variant.
### quarantine action error handling escalation agent
The escalation variant.

Compatibility: Quarantine APIs in Defender and gateways, agent task retry frameworks.

## Why it happens
Retries assume the world will change. A state error, where the target no longer exists in the expected form, never heals with repetition, and an agent without error classification converts one stale record into infinite work.

## Edge cases / pitfalls
- Idempotency keys on actions prevent duplicate effects when a success response is lost in transit.
- Escalation queues need an owner and a review cadence, or they become the new silent loop.
- Log the action, the target state and the response together; debugging loops needs all three.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_whn-S3-V4B-7-5wXZeCG7g