“Uncertain” Is a State, Not an Error

A timeout says what the caller observed. It does not say what the provider did.

The request may have failed before leaving the executor. It may have reached the provider and been rejected. It may have committed successfully while the acknowledgement was lost. Collapsing all three situations into a generic error invites the most dangerous recovery instruction in transaction software: “try again.”

Evidence boundary: This article is part of Independent Product R&D and documents a Target Reference Architecture. It describes intended controls, not measured performance or operational assurance.

The target design makes uncertain a durable outcome state. While a transaction is uncertain, the system preserves its reservation, blocks blind re-execution, gathers provider evidence, and resolves the original action before authorizing another one.

Separate failure from missing knowledge

Use result states that express what is known:

• Denied: deterministic policy or the provider rejected the action; no permitted commit occurred.
• Failed before submission: the executor can establish that no external request crossed the boundary.
• Confirmed: provider evidence identifies a committed or definitively completed outcome.
• Uncertain: available evidence cannot establish whether the external effect occurred.
• Reconciled: later evidence resolves a previously uncertain outcome.

These are semantic states, not translations of transport status codes. A connection reset can map to failed-before-submission if the executor proves that no bytes were sent. The same reset after request transmission can map to uncertain. A successful HTTP response can still be non-final if the provider reports asynchronous processing.

HTTP semantics distinguishes idempotent operations and cautions against automatic retry of non-idempotent requests unless the client knows the original action was not applied or knows the operation is effectively idempotent. A transaction control plane should encode that caution in state transitions rather than leaving it to agent judgement.

Idempotency helps, but evidence still matters

An idempotency identity lets the provider or an adapter associate repeated submissions with one logical operation. It does not remove every ambiguity.

The provider may not support the identity. Its retention window may differ from the transaction lifetime. A request might reach an intermediary but not the system that owns the idempotency record. Reusing the same identity with changed parameters should be rejected, yet a weak adapter may not enforce that. A reconciliation path is still required.

The identity must originate before execution and remain stable through retries, status checks, receipts, and audit evidence. Generating a new value after every timeout defeats the control.

Outcome and reconciliation state model

Conceptual target design. This diagram communicates intended trust boundaries and control flows; it is not a deployment topology or claim of production operation.

The state machine should be monotonic about knowledge. Do not move from uncertain to failed merely because a timer elapsed. Time changes urgency, not historical fact. If evidence remains incomplete, keep the uncertainty visible and escalate according to policy.

Worked example

Consider a fictional procurement request. All names and values in this example are illustrative.

An agent is authorized to order replacement equipment for USD 940 from an approved supplier. The authorization boundary reserves the amount and creates one execution identity. The isolated executor sends the order with a stable idempotency identity. The network connection closes before an acknowledgement arrives.

The executor knows the request was transmitted but cannot tell whether the supplier accepted it. It records an uncertain result. The USD 940 reservation remains held so another request cannot spend the same capacity. The agent receives a status explanation but no authority to reorder.

Reconciliation first queries the supplier using the provider reference recovered from request metadata. No result is returned. It then checks an acknowledgement feed and later finds an accepted order with the matching identity and terms. The local transaction moves to reconciled success, records the order reference, and converts the reservation into a completed commitment.

If provider evidence had instead proven that no order existed and the original identity could not later commit, policy could decide whether a controlled resubmission remained valid. That is a new deterministic decision based on evidence, not a conversational guess.

Design the reconciliation contract

Each external action type needs an explicit evidence strategy before it is enabled. Useful evidence sources include:

• a status lookup by stable provider or idempotency reference;
• a provider event or acknowledgement stream;
• a receipt or confirmation artifact tied to the original terms;
• an independent inventory, balance, or order-state observation;
• an operator review with recorded provenance when automated evidence is insufficient.

Define which sources are authoritative, how conflicting evidence is handled, and which fields must match the authorized proposal. A provider record for the same amount but a different destination is not resolution of the original transaction.

Reconciliation should be safe to repeat. Multiple workers may inspect the same evidence, but they should converge on one recorded disposition. Conflicting terminal evidence should stop automated progression and create an explicit review state.

Preserve reservations while knowledge is incomplete

Releasing budget as soon as a timeout occurs creates room for duplicate spend. Converting the reservation to completed spend without evidence can block legitimate capacity indefinitely. The uncertain state needs its own accounting behavior.

Typical policy choices are to hold the full reservation, hold a risk-adjusted amount, or escalate after a defined review window. This article does not prescribe one financial rule. It does require that the rule be explicit, deterministic, and visible in the evidence record.

Expiry also needs care. Authorization expiry may prevent a new execution without erasing authority that was valid when the original request was sent. Reconciliation is observation of that original request, not a new transaction. The state model should distinguish permission to execute from permission to inspect outcome evidence.

Agent behavior during uncertainty

The agent should receive a constrained status response:

• the transaction is unresolved;
• a new execution is blocked;
• the reservation state and user-visible impact;
• the next reconciliation action or review path;
• the evidence currently available;
• whether the user must provide clarification.

The agent may explain the state and gather information. It should not transform uncertainty into success for a smoother conversation, nor transform it into failure to unlock another purchase. Terminal state changes remain deterministic.

This is also a user-experience requirement. “Something went wrong” encourages manual duplication. “The provider may have accepted the order; we are checking reference R-… and will not place another order meanwhile” communicates the safe next step without overstating the result.

Failure modes

Test the ambiguity, not only the happy path

Inject failures at precise points: before request serialization, after connection establishment, during request transmission, after provider commit, before acknowledgement storage, and during reconciliation. The expected state depends on what the executor can prove at each point.

Also test delayed and duplicated provider events, reused identities with altered terms, conflicting receipts, expired authorization during reconciliation, concurrent reconcilers, and operator correction. A test that merely mocks a timeout does not establish safe behavior unless it asserts the reservation, retry block, evidence record, and eventual resolution.

Implementation checklist

• Define denied, failed-before-submission, confirmed, uncertain, and reconciled semantics.
• Classify outcomes from evidence, not transport status alone.
• Create one stable idempotency identity before external execution.
• Reject reuse of that identity with changed transaction terms.
• Block blind re-execution while the original outcome is uncertain.
• Preserve budget or capacity under an explicit uncertainty policy.
• Specify authoritative evidence sources for every external action type.
• Make reconciliation repeatable and convergent under concurrent workers.
• Escalate conflicting or persistently incomplete evidence without inventing a terminal result.
• Test failures around every transmission, acknowledgement, and evidence boundary.

The previous article, Keeping Provider Credentials Outside the Agent, defines the execution boundary that reports these states. Next, Where Secure Agent Transactions Fit: A Use-Case Map applies the controls across several domains. The project overview and full case study connect uncertainty to the wider evidence chain. For a private-source discussion, request repository access.