Reconcile Before Retry

The dangerous part of a timeout is not the error message. It is the missing fact. Did the operation fail before committing — or did it commit and lose the response? Treating those two states as the same can duplicate durable actions.

Blind retry reproduced the failure.

The first synthetic charge committed successfully, then deliberately raised a timeout before the caller received the response. The deterministic model then called the charge tool again without reconciling state.

The safe path makes UNKNOWN a real state.

Instead of mapping an error directly to retry, the recovery-aware trajectory maps the ambiguous result to UNKNOWN. That state has only one legal next step in this protocol: reconcile durable state.

Scenario A: the commit already happened.

The first call committed, then lost its response. The next tool call queried operation state and observed committed. The run stopped without issuing another charge.

Observed: one attempt, one commit, one reconcile, one final effect.

Scenario B: the commit never happened.

The first call timed out before commit. Recovery still did not assume failure. It reconciled first, observed absent, and only then issued one retry. The retry committed exactly once.

Observed: two attempts, one reconcile, one commit, one final effect.

What the SDK did — and did not do.

The pinned OpenAI Agents SDK tool loop faithfully executed all three deterministic trajectories using the upstream FakeModel. That is important because it separates framework capability from application policy.

The benchmark does not claim the SDK automatically enforces idempotency, reconciliation or retry safety. It demonstrates that an application can encode either an unsafe or safe recovery trajectory on top of the same framework primitives.

The engineering implication

For payments, orders, deployments, messages, access changes and resource creation, the application should not equate transport failure with state failure. A robust design can combine durable operation IDs, service-side idempotency, read-after-error reconciliation, explicit UNKNOWN states and evidence showing why a retry was permitted or blocked.

The next interesting failure is one layer deeper: what if reconciliation itself is ambiguous? A mature state machine should not collapse that condition back into blind retry. It should preserve uncertainty until stronger evidence arrives or a human takes over.

Interpretation boundary

This is an application-level recovery experiment using synthetic local side effects. It is not a payment-processor test, not a vulnerability claim, not evidence that every timeout requires this exact policy, and not a safety certification for applications built with the SDK.

Verdict: blind retry reproduced a duplicate side effect; reconciling durable state before deciding whether retry was legal preserved exactly one intended effect in both ambiguous branches.