What if the same instruction arrives twice?
Reject a resubmitted, previously-executed request by design — idempotency has to be enforced at the execution layer, not assumed because it "shouldn't happen."
Operator pathway · foundation 05
The happy path was never the risk.
Every payment-capable agent works when the network is fast, the response arrives once, and nothing is malicious. Readiness is measured by what happens when none of that is true.
Learning boundary. This lesson teaches an operating model. It is not a certification, security assessment, legal delegation, financial recommendation, or approval to use production funds.
Learning objective
Separate six failure paths.
By the end of this lesson, you should be able to inspect a proposed agent deployment, assign evidence-based readiness scores per failure path, identify which exceptions have only been discussed versus actually exercised, and explain why a system that has never failed on purpose is not a tested system.
What if the response never comes back?
Define what the agent does when a request hangs — retrying blindly can duplicate a payment that actually succeeded silently on the far end.
What if the signing key leaks?
Exercise the actual revoke-and-rotate procedure end to end, including the specific stop condition that should trigger it — a documented process nobody has run is a guess with paperwork.
What if the agent submits twice by mistake?
Deduplicate at the infrastructure layer using a request identifier, not agent self-restraint — an agent under retry logic or confused state will resubmit.
What if only part of the order arrives?
Define the threshold and response for partial delivery explicitly — "close enough" is a decision that needs an owner, not a default the system falls into.
What if something needs to be reversed, or the rail goes down?
Name who initiates a dispute or refund and what the agent does when a dependency is simply unavailable — silence during an outage is not the same as a safe stop.
Practice lab · evidence before confidence
Score an exception-handling setup.
A subscription-renewal agent retries any request that times out after 10 seconds, up to three times. The team confirms the payment API is idempotent "by design" but has not sent a deliberately duplicated request to verify it. There is no procedure for a leaked signing key beyond "someone would notice and shut it down." Partial fulfillment and disputes have not come up yet.
- Score each dimension from 0: absent, 1: documented, or 2: tested.
- Name every claim that requires evidence before awarding a point.
- Identify the critical gaps that prevent a bounded pilot.
- Write the smallest safe next experiment.
Answer rationale
Replay is at most 1, not 2 — idempotency "by design" without a test that actually sends a duplicate request is an unverified assumption, and blind retries on timeout make this exact gap load-bearing. Timeout itself is 1: a retry policy exists, but nothing confirms it can't double-charge on a slow-but-successful original request. Compromised credentials is 0 — "someone would notice" is not a procedure with an owner or a measured response time. Duplicate requests is 0 for the same reason as replay: never actually tested. Partial fulfillment and dispute handling are 0 by the team's own account — not designed around, not just unenforced. The appropriate next step is a deliberate duplicate-request test against the payment API before extending retry counts or adding new failure paths.
STOP → EXERCISE