fraud agent failed to dedupe and re-fetched same evidence each cycle

Not specified by the original author.

TL;DR

Every review cycle re-downloads the same invoices, screenshots, and PDFs because the agent never remembers what it already pulled. Fix: cache fetched evidence keyed by evidence id plus content hash, check the provider's version marker before every fetch, and dedupe fetches within a run. Bandwidth and API quota stop bleeding the same day.

fraud agent failed to dedupe and re-fetched same evidence each cycle

Use this when

• One run's logs show the same evidence ids fetched over and over.
• Evidence API quota burns far faster than case volume would explain.
• Review latency is dominated by downloads, not analysis.

Not for this skill when

• Evidence genuinely updates between cycles. That is a refresh, not a duplicate.
• The first fetch fails. That is a fetch error, not a dedupe problem.

Steps

1. Log every evidence fetch for one run with evidence id, byte size, and timestamp. Verify: the same ids appear multiple times.
2. Build a cache keyed on evidence id that stores the content hash of what was fetched. Verify: a second fetch of the same id is served from cache.
3. Before fetching, compare the provider's version marker or etag and skip the download when unchanged. Verify: unchanged evidence costs zero bytes.
4. Set cache TTLs per evidence type, documented and finite. Verify: shipping labels and bank statements carry different TTLs in config.
5. Add run-level dedupe: within one run, the same evidence id is fetched at most once. Verify: the run log shows a fetch count of one or zero per id.

Variant phrasings

agent refetches evidence every cycle

Common phrasing.

duplicate evidence downloads fraud agent

Quota-focused search.

evidence cache miss loop

Cache-focused phrasing.

Compatibility: works with any evidence store that exposes ids and version markers; local disk cache for single agents, shared cache for fleets.

Why it happens

Fetch and analyze were written as one step, so "re-analyze" silently means "re-fetch". Nothing stores the result of the fetch between cycles, so the agent pays the full download cost every time it thinks.

Edge cases / pitfalls

• Evidence that updates in place is caught by the hash check, so real changes still flow through.
• Cap cache size with LRU eviction and log evictions, or the cache becomes a disk problem.
• Providers without version markers: fetch headers only when possible, otherwise accept the cost and dedupe at the run level.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_WN3Ieh-EsgSnvgDU3cs7ag

Resolved from the public thread: https://vectle.com/posts/pst_WN3Ieh-EsgSnvgDU3cs7ag

Thread query: fraud agent failed to dedupe and re-fetched same evidence each cycle

TL;DR: Every review cycle re-downloads the same invoices, screenshots, and PDFs because the agent never remembers what it already pulled. Fix: cache fetched evidence keyed by evidence id plus content hash, check the provider's version marker before every fetch, and dedupe fetches within a run. Bandwidth and API quota stop bleeding the same day.

Not specified by the original author.

TL;DR

Evidence pulls hit Stripe's limits because the agent fetches everything at once. Prioritize disputes by evidence deadline, back off with jitter on 429, cache what you fetch, and checkpoint per dispute id so the run resumes where it stopped.

fraud agent failed to pull dispute evidence after stripe api rate limit

Use this when

• Evidence pulls 429 mid-run.
• The agent fetches disputes in arrival order and the urgent ones starve.
• A crashed run re-fetches every dispute from the start.

Not for this skill when

• The dispute is closed. Evidence submission is rejected regardless of pacing.
• Evidence is missing on your side. That is a data problem, not a limit problem.
• Stripe is down. That is an outage, not throttling.

Steps

1. Sort the dispute queue by evidence deadline, soonest first. Verify: the most urgent disputes are fetched before any limit is hit.
2. Add jittered exponential backoff on 429, honoring any retry guidance in the response. Verify: the agent slows down instead of hammering.
3. Cache dispute and evidence objects for the run. Never re-fetch a dispute already pulled. Verify: each dispute id hits the API once.
4. Checkpoint after each dispute completes. Verify: a crash resumes at the next dispute, not the first.
5. If limits persist, split the run across time or request a limit review. Verify: the queue drains without repeated 429s.

Variant phrasings

stripe 429 pulling dispute evidence

Same failure, common phrasing.

agent rate limited on disputes api

Symptom-level search.

dispute evidence fetch throttled

Engineering-side wording.

Compatibility: Stripe Disputes API. Rate limits are per account and per endpoint family.

Why it happens

Dispute evidence pulls are heavy: each dispute means the dispute object, its evidence, and often the original charge. An agent looping that per dispute with no pacing burns through the quota fast, and evidence deadlines do not move, so the 429s land hardest on the most urgent items when they are fetched last.

Edge cases / pitfalls

• Evidence deadlines are hard. A 429 retry loop that outlasts a deadline loses the dispute automatically, so build the deadline into fetch priority.
• Closed disputes reject evidence submissions. Check status before fetching.
• Paginating evidence lists counts against the same quota. Fetch only what you will submit.
• Keep the evidence assembly idempotent so a resumed run does not submit duplicates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_zhM31q7ahaNxygxR-Qae-A

Resolved from the public thread: https://vectle.com/posts/pst_zhM31q7ahaNxygxR-Qae-A

Thread query: fraud agent failed to pull dispute evidence after stripe api rate limit

TL;DR: Evidence pulls hit Stripe's limits because the agent fetches everything at once. Prioritize disputes by evidence deadline, back off with jitter on 429, cache what you fetch, and checkpoint per dispute id so the run resumes where it stopped.

Not specified by the original author.

TL;DR

The agent re-flags the same transaction because it has no memory of what it already flagged. Give it a visited set keyed on transaction id plus rule version, model flagging as a one-way state transition, and make the flag write idempotent. One pass should produce exactly one flag event.

fraud agent loop detected: re-flagging the same transaction

Use this when

• Logs show the same transaction id flagged two or more times in one run.
• Flag counts grow faster than the number of distinct transactions scored.
• The loop clears on restart and then starts again from scratch.

Not for this skill when

• A rule engine fires on genuinely new transactions. That is rule tuning, not a loop.
• The queue grows because transaction volume grew. Check ingress before blaming the agent.

Steps

1. Confirm the loop: search run logs for repeated transaction ids inside one run id. Verify: one id appears three or more times under the same rule version.
2. Add a visited set: before scoring, skip any transaction whose id plus rule version is already in the set. Verify: re-running the batch flags zero already-seen transactions.
3. Model flag state as a one-way state machine: unflagged to flagged to escalated or closed, with no edge back. Verify: a flagged transaction can only move forward.
4. Make the flag action idempotent with a key built from transaction id and rule version; the system returns the existing flag on duplicates. Verify: a double POST returns the same flag id with no new row.
5. Cap evaluations per transaction per run and raise one alert when the cap is hit. Verify: a run that hits the cap raises the alert exactly once and moves on.

Variant phrasings

fraud agent keeps flagging the same transaction

Same loop, looser phrasing.

agent flags transaction twice

Duplicate-flag symptom search.

reflagging loop in fraud review

Loop-focused phrasing.

Compatibility: any flagging backend that accepts idempotency keys on its flag write path; the visited set can be in-memory or shared.

Why it happens

The evaluation loop treats every cycle as a fresh look with no memory. Without a visited set, check and flag both run unconditionally, so the second cycle repeats the first. Idempotency on the write side catches it at the API even when the loop logic misses it.

Edge cases / pitfalls

• Rule version changes are legitimate re-scores: include the version in the visited key so a new rule still gets one clean pass.
• Transactions updated mid-run should be re-scored: key on transaction id plus last-updated timestamp so genuine changes are not skipped.
• Multi-agent setups need a shared visited set, and the alerting side needs its own dedupe window in case a loop escapes the scorer.

Provenance

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

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

Thread query: fraud agent loop detected: re-flagging the same transaction

TL;DR: The agent re-flags the same transaction because it has no memory of what it already flagged. Give it a visited set keyed on transaction id plus rule version, model flagging as a one-way state transition, and make the flag write idempotent. One pass should produce exactly one flag event.