fraud agent submitted duplicate representment after losing track of state

TL;DR

An agent resubmits representment when its memory of submitting is weaker than its instruction to submit. Restarts, retries, and handoffs all recreate that urge. Make submission a ledgered, idempotent act: before submitting, the agent checks a durable submission record for the dispute and the processor own submission status; it submits only if both say no submission exists, writes the receipt to the ledger the moment the processor confirms, and treats any later submit impulse on that dispute as a request to view the receipt. The processor lock on duplicates is a backstop, not the control.

fraud agent submitted duplicate representment after losing track of state

Use this when

• The same dispute shows two submission attempts, or a portal duplicate rejection.
• Agent restarts or retries coincide with the extra submissions.
• Submission receipts live in agent logs instead of on the case.

Not for this skill when

• A human deliberately filed an appeal or supplement after a decision. That is a new, legitimate act with its own record.
• The first submission genuinely failed before reaching the processor. The status check will show that and a retry is correct.

Steps

1. Create the submission ledger: dispute id, processor, submitted time, receipt id, file list, and submitting actor, stored durably outside the agent. Verify: every past submission you can find is recorded in the ledger.
2. Add the pre submit check: the agent must read the ledger and query the processor dispute status before any submission action is available to it. Verify: in staging, a second submit attempt stops at the check with the receipt displayed.
3. Write the receipt synchronously on processor confirmation before the agent does anything else, so a crash after submit cannot erase the fact. Verify: killing the agent right after a staged submit still leaves a ledger entry.
4. Route later evidence additions through the supplement or appeal path explicitly, never through the original submit action. Verify: the agent runbook and toolset expose supplement as a separate, named action.
5. Reconcile weekly: compare ledger entries with processor submission records and investigate any mismatch the same week. Verify: the reconciliation report shows no unmatched submissions.

Variant phrasings

agent submitted dispute evidence twice

Duplicate phrasing.

representment idempotency for agent

Idempotency phrasing.

agent lost track submitted state dispute

State loss phrasing.

Compatibility: Stripe, Adyen, Braintree, and gateway dispute APIs with any agent framework. Idempotency keys, where the processor supports them, complement but do not replace the ledger.

Why it happens

Agents are stateless between runs unless state is engineered, and submission is exactly the act where statelessness hurts: the evidence is still there, the deadline still looms, and nothing in the workspace says done. Retry logic built for safe reads gets applied to an unsafe write, and each restart becomes a fresh attempt to do a job that was already finished.

Edge cases / pitfalls

• A submission that timed out is ambiguous: it may have landed. The status query, not the timeout, decides the retry.
• Two different disputes for one chargeback, for example a duplicate chargeback, need separate ledger entries keyed by dispute id, not by order.
• Locking must survive agent version changes. Put the ledger in the case system, not in agent local storage.

Provenance

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