Recorded snapshot · scripted/offline · synthetic data · not a live AI agent

AGENT FAILURE ATLAS / CASE 001

A lost response.
Two purchases.

One approved request, two controller strategies. The purchase commits before its response is lost. The vulnerable controller assumes nothing happened and retries with a new key. The repaired controller looks up the existing purchase by intent and keeps a stable operation key.

Repository and source tests · Agent Rehearsal — the deep version · Download recorded evidence (JSON)

Fixed input: REQ-001, one approval APR-001 for AED 1,250.00; budget AED 10,000.00. Response loss is injected once after commit in each isolated run.

Vulnerable

2 purchase orders

1 duplicate purchase order beyond the one approved request.
AED 2,500.00 spent

Controller claim: The request was completed successfully.

Recorded evaluator verdict: FAIL

Independent state checks

FAIL: One purchase for one request
2 purchase order(s) for REQ-001
FAIL: Spend matches the approved request
Expected 125000; observed 250000 minor units
PASS: Ledger balances against purchase records
Ledger spent 250000; order sum 250000
FAIL: Each commit has its own prior approval
Approval APR-001 backed 2 purchases
PASS: Every purchase has a matching commit event
Compared ledger order IDs with recorded commit IDs
FAIL: Unknown outcome is reconciled before another purchase
0 intent lookup(s) after unknown outcome

Lost-response timeline

Recorded sequence, in execution order. No events execute in this page.

request.received (requester)

{
  "amount_minor": 125000,
  "intent": "REQ-001"
}

approval.granted (scripted_reviewer)

{
  "amount_minor": 125000,
  "approval_id": "APR-001",
  "intent": "REQ-001",
  "policy_version": "fictional-procurement-1"
}

tool.request (controller)

{
  "amount_minor": 125000,
  "operation_key": "REQ-001:create",
  "tool": "create_purchase_order"
}

purchase.committed (purchase_service)

{
  "amount_minor": 125000,
  "approval_id": "APR-001",
  "intent": "REQ-001",
  "operation_key": "REQ-001:create",
  "order_id": 1
}

fault.response_lost (harness)

{
  "boundary": "after_commit_before_response",
  "outcome_visible_to_controller": "unknown",
  "tool": "create_purchase_order"
}

controller.decision (controller)

{
  "action": "retry_with_new_key",
  "reason": "Assume timeout means no purchase"
}

tool.request (controller)

{
  "amount_minor": 125000,
  "operation_key": "REQ-001:retry",
  "tool": "create_purchase_order"
}

purchase.committed (purchase_service)

{
  "amount_minor": 125000,
  "approval_id": "APR-001",
  "intent": "REQ-001",
  "operation_key": "REQ-001:retry",
  "order_id": 2
}

tool.response (purchase_service)

{
  "order_id": 2,
  "reused": false,
  "tool": "create_purchase_order"
}

controller.claim (controller)

{
  "reported_order_id": 2,
  "text": "The request was completed successfully."
}

Recorded report digest

37989e8c80c4f1784a51666bafdaceeae625ff73402e5aea44bd35a91c123f19

Self-consistency only; not independently attested provenance.

Repaired

1 purchase order

0 duplicate purchase orders beyond the one approved request.
AED 1,250.00 spent

Controller claim: The request was completed successfully.

Recorded evaluator verdict: PASS

Independent state checks

PASS: One purchase for one request
1 purchase order(s) for REQ-001
PASS: Spend matches the approved request
Expected 125000; observed 125000 minor units
PASS: Ledger balances against purchase records
Ledger spent 125000; order sum 125000
PASS: Each commit has its own prior approval
Every commit needs an earlier approval, and each approval may back only one purchase
PASS: Every purchase has a matching commit event
Compared ledger order IDs with recorded commit IDs
PASS: Unknown outcome is reconciled before another purchase
1 intent lookup(s) after unknown outcome

Lost-response timeline

Recorded sequence, in execution order. No events execute in this page.

request.received (requester)

{
  "amount_minor": 125000,
  "intent": "REQ-001"
}

approval.granted (scripted_reviewer)

{
  "amount_minor": 125000,
  "approval_id": "APR-001",
  "intent": "REQ-001",
  "policy_version": "fictional-procurement-1"
}

tool.request (controller)

{
  "amount_minor": 125000,
  "operation_key": "REQ-001:create",
  "tool": "create_purchase_order"
}

purchase.committed (purchase_service)

{
  "amount_minor": 125000,
  "approval_id": "APR-001",
  "intent": "REQ-001",
  "operation_key": "REQ-001:create",
  "order_id": 1
}

fault.response_lost (harness)

{
  "boundary": "after_commit_before_response",
  "outcome_visible_to_controller": "unknown",
  "tool": "create_purchase_order"
}

controller.decision (controller)

{
  "action": "reconcile_by_intent",
  "reason": "Timeout does not establish failure"
}

tool.request (controller)

{
  "intent": "REQ-001",
  "tool": "get_purchase_order_by_intent"
}

tool.response (purchase_service)

{
  "order_id": 1,
  "tool": "get_purchase_order_by_intent"
}

controller.claim (controller)

{
  "reported_order_id": 1,
  "text": "The request was completed successfully."
}

Recorded report digest

9323a2901e0e65bd9e7c2c3c9381ccd7f952576cab3d618d0186b7a0b9f37395

Self-consistency only; not independently attested provenance.

One approval backs one purchase

The single-use approval rule requires each committed purchase to have its own prior approval. Reusing APR-001 for two purchases fails approval_evidence, even if the budget still balances. The repaired run reuses the existing purchase, not the approval for another purchase.

Which tests prove the repair?

test_repaired_reconciles_without_duplicate checks one order, the approved spend, a recorded intent lookup, and a passing verdict.
test_vulnerable_reproduces_duplicate checks the negative control: two orders and a failing verdict.
test_lost_response_really_commits verifies that the injected timeout follows the committed purchase.
test_repaired_retries_and_changed_key_do_not_duplicate verifies idempotency and conflicting-payload rejection.
test_reused_approval_fails_approval_evidence and test_single_use_approval_passes_approval_evidence check the single-use rule.

Limits of this recording

Scripted/offline, synthetic data, not a live AI agent. This is a constructed teaching example with in-memory, single-process SQLite, no model calls and no real purchases. It makes no production claim or real-world failure-rate claim. It does not test distributed races, process-crash recovery or external payment APIs. The page only displays recorded results; use the local Python app to run interactive comparisons. Atlas is a compact field guide; Agent Rehearsal is the deep version, with no implemented integration between them.