fraud agent escalation loop detected between two review queues
Breaks escalation loops between two review queues with a hop counter on the escalation envelope and a supervisor fallback at max hops. Use when the same alert bounces between queues and ownership is ambiguous. Not for slow single queues or legitimate multi-stage pipelines.
TL;DR
Two queues keep handing the same alert back and forth because each queue's exit rule maps to the other queue. Break the loop with a hop counter on the escalation envelope: after two hops the alert goes to a supervisor queue and the loop is logged as an incident. Then fix the underlying routing ambiguity that made both queues refuse it.
fraud agent escalation loop detected between two review queuesUse this when
- The same alert id appears in queue A and queue B alternately in the logs.
- Escalation latency grows in stair-steps as alerts bounce.
- Both queues claim the other owns the alert type.
Not for this skill when
- One queue is just slow and retries look like bouncing. Check hop count, not age.
- The alert is correctly moving down a multi-stage pipeline. A pipeline has an exit; a loop does not.
Steps
- Stamp every escalation with a routing envelope: alert id, hop count, and a visited-queue list. Verify: logs show each bounce incrementing the hop count.
- Set a max-hop rule: at hop three the alert routes to a supervisor queue and fires a routing-ambiguity incident. Verify: a synthetic looping alert lands in the supervisor queue exactly once.
- Resolve the ambiguity: define ownership by alert class in one routing table both queues read. Verify: no alert class maps to more than one owner.
- Make bounce-back impossible in code: a queue cannot escalate an alert it already visited. Verify: the visited list rejects a re-entry with a logged error.
Variant phrasings
escalation bouncing between review queues
Queue-level phrasing.
alert keeps moving between fraud queues
Symptom phrasing.
circular escalation in fraud review
Pattern phrasing.
Compatibility: Applies to any multi-queue review setup. The hop counter travels with the alert so it survives queue restarts and redeploys.
Why it happens
Ownership rules were written per queue, never as one table, so two queues each define the same alert class as the other's job. The agent follows the rules faithfully and loops forever.
Edge cases / pitfalls
- Supervisor queues need their own SLA or loops just pool there.
- Merging two queues can be cheaper than perfecting the table. Consider it.
- Time-based re-escalation can look like a loop. Distinguish by cause, not by movement.
- Log the full visited path, not just the count, or you will refix the same ambiguity.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_4FFMdXLUSKgJEzcdZ2B6Og