UNKNOWN Is an Operational State, Not a Model Feeling

No response does not imply no commit. Safe continuation begins when uncertainty constrains the next action and preserves a route back to external evidence.

No response is not no commit

A Tool call times out. The model says it is uncertain. The process disappears. The tempting implementation marks the attempt failed and retries.

If the backend already committed, that retry can duplicate money movement, publication, deployment, resource consumption, or any other non-idempotent Effect. The missing response is not merely a feeling inside the model. It is an unresolved relationship between an intended operation and external reality.

UNKNOWN is operational state when it is bound to a stable operation identity and a method for reconciling reality.

The five required invariants

stable identityexplicit UNKNOWNbackend correlationreconciliationno blind redispatch

Without identity, a later process cannot know which operation to query. Without correlation, it cannot connect the intended Effect to a Provider request, Runtime Job, receipt, or ledger row. Without reconciliation, uncertainty never resolves. Without a redispatch prohibition, the state does not protect reality.

UNKNOWN is not failure

Core Work System Round 1 injected a lost response after a non-idempotent backend had committed. The plain Tool path retried under a new request identity and produced a duplicate Effect. Idempotency plus audit, durable Activity, and the Ordivon path all preserved the original identity and observed the existing commit.

The correct state machine is not:

request
→ response or failure

It is:

intended operation
→ dispatch
→ confirmed success | confirmed failure | UNKNOWN
→ reconcile external reality
→ admit next action

UNKNOWN is not model sentiment

A model can say “I am not sure” even when the system has a complete receipt. It can sound confident while using stale evidence. Operational uncertainty must be computed from authoritative state, not inferred from tone.

The model may propose a reconciliation method or interpret the resulting evidence. The owning layer decides whether the operation remains unresolved and which actions are forbidden until it is resolved.

Where the state belongs

Runtime owns UNKNOWN when the unresolved fact is a local Job or process Effect.
World may own UNKNOWN when path, identity, Provider action, and response delivery must be correlated.
Host owns what the unresolved operation means for the Task and whether continuation is admissible.
Provider-native systems should retain idempotency and receipt lookup when they already provide it.

This does not require one universal Effect database. It requires the stable intended identity and unresolved status to survive wherever the physical boundary lives.

Waiting can be the correct action

Explicit UNKNOWN connects to calibrated non-action. The Agent may need to observe, wait for a receipt, request a decision, or refuse a new dispatch. Always acting is not capability when action can multiply an unresolved consequence.

The cost of waiting also matters. A receipt can expire, a strategic window can close, or a resource can become unavailable. Future experiments must compare acting too early with abstaining too long under real deadlines and consequences.

Uncertainty becomes useful when it constrains the next action and carries a path back to evidence.

Evidence