## TL;DR
The agent re-alerts because it has no memory of what it already reported. Fix it with an entity-level dedupe key: one alert per fraud ring per time window, keyed on the shared identifiers like device fingerprint, email domain pattern, and BIN range. Repeat sightings increment a counter on the existing alert instead of spawning new ones.

```text
fraud agent sent duplicate alerts for the same fraud ring
```

## Use this when
- Analysts get five alerts for one ring and learn to ignore all of them.
- The same entity triggers a fresh alert on every transaction.
- Alert volume spikes are driven by one cluster, not many incidents.

## Not for this skill when
- Duplicates come from replayed webhooks. That is a webhook idempotency fix.
- Each alert really is a distinct incident. Check the shared identifiers first.

## Steps
1. Define the dedupe key from ring-level signals: device fingerprint, IP block, email pattern, BIN range, not the transaction id. Verify: two transactions from one ring produce the same key.
2. Keep an active-alert registry keyed on the dedupe key with a time window. Verify: a repeat within the window attaches to the open alert instead of creating one.
3. Let repeats escalate severity instead of multiplying alerts: five sightings in an hour bumps the tier. Verify: the alert shows sighting count and last-seen time.
4. Close the loop: when the ring is resolved, the registry entry clears and a summary notes total sightings. Verify: a new ring with the same pattern creates a fresh alert, not a reopen.

## Variant phrasings
### duplicate fraud ring alerts agent
Entity phrasing.
### same fraud cluster alerted repeatedly
Cluster phrasing.
### fraud agent re-alerting same case
Behavior phrasing.

Compatibility: Works with any alerting store that supports keyed lookups with TTL. The dedupe key is computed from fields the scorer already emits.

## Why it happens
The agent's unit of work is the transaction, so every transaction in a ring looks like a new incident. Without an entity-level key, correlation never happens and analysts drown in repeats.

## Edge cases / pitfalls
- Keys that are too broad merge distinct rings. Validate the key against labeled rings.
- Keys that are too narrow never dedupe. Start broad and tighten on analyst feedback.
- Window length matters: too short re-alerts, too long hides new rings. Tune per class.
- Log every dedupe decision so a suppressed alert is auditable.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zf-xkPQ5_6kA1ARBvBiQqA