UNKNOWN Must Stay UNKNOWN

Recovery becomes harder when the check that should resolve uncertainty is itself uncertain. A status endpoint can time out. A read replica can be stale. A queue may be delayed. If an agent interprets “I still do not know” as “the action probably did not happen,” it can manufacture a duplicate from missing evidence.

The unsafe shortcut duplicated the effect.

The first synthetic charge committed, then deliberately lost its response. The status check also timed out. The unsafe trajectory converted that second UNKNOWN directly into another charge.

The state machine needs a real uncertainty state.

The recovery rule from Report #003 becomes stricter here. Reconciliation is not automatically truth. The system must also classify the quality of the evidence returned by reconciliation.

Timeout during reconciliation

The safe path experienced the same hidden commit and the same failed status check as the unsafe path. The difference was one transition: it refused to map the failed read to ABSENT.

Observed: one charge attempt, one hidden commit, one inconclusive reconciliation, one final effect, no retry.

Stale evidence is not negative evidence.

A second safe scenario returned a deliberately stale snapshot with status=unknown. The protocol preserved uncertainty because freshness is part of evidence quality. A stale record cannot authorize a destructive or duplicative transition merely because it lacks the new state.

Observed: one attempt, one effect, stale UNKNOWN, retry blocked.

Uncertainty can resolve without action.

In the fourth trajectory the first status request timed out, but a second reconciliation returned a fresh committed state. The operation completed with one effect and no second charge call.

This is an important pattern for agent systems: sometimes the correct recovery action is not another side effect. It is another observation.

Four distinctions worth keeping

These look almost trivial when written down. In production state machines they are exactly the distinctions that disappear under pressure to “just retry.” The result is duplicated payments, repeated messages, double provisioning, repeated deployments or conflicting state transitions.

What the SDK did — and did not do.

The pinned OpenAI Agents SDK tool loop faithfully executed all four deterministic trajectories using the upstream FakeModel. As in Report #003, the framework provides the execution machinery; the recovery semantics are an application protocol.

This report does not claim that OpenAI Agents SDK automatically keeps UNKNOWN states, blocks retries, verifies freshness or provides service-side idempotency.

Interpretation boundary

This is a synthetic application-level experiment. It is not a real payment test, a vulnerability claim, a live-model evaluation, a test of every reconciliation source, or a safety certification for applications built with the SDK.

Verdict: an inconclusive reconciliation result must preserve uncertainty. Turning UNKNOWN into retry reproduced a duplicate; keeping UNKNOWN prevented it across timeout, stale-read and eventual-resolution trajectories.