## TL;DR
An agent that waits only for a Signifyd callback has no defense against the one callback that never comes, and its case, and the customer order, wait forever. Build the wait as a bounded state: record when the case was submitted and the expected decision window, poll Signifyd for the case outcome on an interval after that window, and at the hard limit escalate to a human with the case id, submission time, and poll history attached. Most cases resolve by poll, because the outcome usually exists in Signifyd and only the notification was lost.

```text
fraud agent stalled waiting for signifyd sla callback that never came
```

## Use this when
- Agent cases sit in a waiting on Signifyd state far beyond normal decision times.
- Signifyd console shows a decision the agent never acted on.
- Orders are late because an agent run never resumed.

## Not for this skill when
- The case is inside Signifyd normal investigation window. Polling early adds noise, not speed.
- Signifyd shows the case still open with no decision. Escalate the case with Signifyd, not just the agent wait.

## Steps
1. Add wait metadata to every submitted case: submitted time, expected window, and poll schedule, stored on the case rather than in agent memory. Verify: a waiting case shows its age and next poll time in the queue.
2. Implement polling after the expected window: fetch the case from Signifyd and act on any final guarantee or review outcome found. Verify: a staged case with a suppressed callback completes by poll.
3. Set a hard wait limit, for example twice the normal SLA, at which the agent stops waiting and escalates with full context instead of polling forever. Verify: a staged never resolving case escalates at the limit with its history attached.
4. Reconcile daily: list every agent case waiting past the window and compare with Signifyd outcomes, clearing any stragglers the poller missed. Verify: the daily report shows zero unexplained aged waits.
5. Track callback arrival rate as a health metric so a rising miss rate triggers webhook investigation before cases pile up. Verify: the metric exists and an artificial dip alerts the team.

## Variant phrasings
### agent waiting signifyd decision never came
Missing decision phrasing.
### signifyd callback lost agent stuck
Lost callback phrasing.
### poll signifyd case outcome agent timeout
Polling solution phrasing.

Compatibility: Signifyd case API and webhooks with any agent orchestration framework that supports scheduled wakeups or durable timers. Poll intervals should respect Signifyd API rate limits.

## Why it happens
Callback only designs assume webhook delivery is guaranteed, and it is not: endpoints fail, signatures break, queues drop events. Human teams notice a stale case because a customer complains; an agent in a wait state has no impatience, so the failure mode is silent and indefinite unless the wait itself is engineered with a deadline and a second path to the answer.

## Edge cases / pitfalls
- Polling too aggressively burns API quota and can slow the very system you are waiting on. Poll on a widening interval.
- A case decided while the agent was stalled may have a stale order behind it, cancelled or already shipped. Revalidate the order before acting on a late decision.
- Keep the escalation human readable: case id, order id, wait duration, and last known Signifyd status, not a raw agent trace.

## Provenance

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