How it works
An unknown outcome occurs when execution evidence ends before the harness can establish the result of an action. The request may have reached the tool, and the tool may have committed its side effect, but the acknowledgement is missing or inconclusive. A timeout, worker crash, lost response, or interrupted connection can all create this state.
The important distinction is epistemic: the action is not necessarily unfinished or failed. The harness simply lacks enough evidence to classify it safely. A reliable control loop therefore treats uncertainty as a first-class state:
- Record the invocation identity, inputs, intended effect, and last confirmed event.
- Mark the outcome as unknown without changing it to success or failure.
- Stop dependent actions that require a confirmed result.
- Reconcile against an authoritative system, execution journal, or idempotency record.
- Retry only when the operation is proven idempotent or the first attempt is proven absent.
- Otherwise require a compensating action, bounded investigation, or operator decision.
The state must survive worker restarts. If it exists only in process memory, recovery code may interpret the missing result as a fresh task and repeat the action. The same applies to agent reasoning: a model should not infer completion from intent, tool-call emission, or an optimistic message. Completion requires durable evidence tied to the specific invocation.
Why it matters in an agent harness
Unknown outcomes are where ordinary retry logic becomes dangerous. A read can often be repeated safely. A write may create a second payment, publish duplicate content, send another message, overwrite newer state, or launch an additional job. Retrying because no response arrived confuses missing evidence with failed execution.
The harness needs to separate three facts that agent transcripts often collapse:
- The agent decided to invoke an action.
- The request was accepted or transmitted.
- The intended effect was confirmed.
Only the third fact supports a successful outcome. A trace showing a tool call is useful evidence about intent, but it is not proof that the external state changed. Conversely, an exception after transmission is not proof that nothing changed.
Making unknown outcomes explicit improves control and failure containment. Downstream steps can stop before acting on an unverified assumption. Recovery logic can select reconciliation instead of generic retry. Operators can see why a run is paused without reading raw logs. Evaluations can also test whether an agent and its harness preserve uncertainty under injected timeouts, crashes, and delayed responses.
This state shapes permission design as well. The larger the tool invocation's blast radius, the stronger its confirmation and reconciliation mechanisms should be. A reversible draft write may tolerate automatic recovery. An irreversible external action may require an idempotency key, an authoritative lookup, or approval before another attempt.
Unknown does not mean permanently unknowable. It means the current evidence cannot justify a terminal classification. The recovery contract should specify what evidence resolves the state, how long reconciliation continues, which actions remain blocked, and who may choose a manual disposition. If the system eventually gives up investigating, that is still not evidence of failure. It is a separate operational decision that should remain visible in the audit trail.
Unknown outcome vs failed execution
The distinction changes whether retrying is safe. A failed execution has affirmative evidence that the intended effect did not complete. An unknown outcome lacks enough evidence either way.
| Question | Unknown outcome | Failed execution |
|---|---|---|
| Did the side effect occur? | Possibly | Confirmed not to have completed as intended |
| Is automatic retry safe? | Only with proven retry safety or reconciliation | Often, but still subject to retry policy |
| What should happen next? | Inspect authoritative state and preserve uncertainty | Apply the defined failure or retry path |
| What must the record show? | The evidence gap and unresolved invocation | The failure evidence and terminal or retryable classification |
A harness that maps every timeout to failure erases this distinction. One that maps every accepted request to success makes the opposite mistake. Both produce confident state from incomplete evidence.
The Rifty take
We optimize for honest state over smooth-looking execution. An unknown outcome should interrupt unsupported progress, but it should not automatically escalate every ambiguity to a person. The harness should reconcile mechanically where it can and preserve a clear control boundary where it cannot.
Common failure modes
- Treating a timeout or disconnected transport as proof that the action failed.
- Retrying a side-effecting call without an idempotency key or authoritative reconciliation.
- Recording tool-call intent as proof of the external effect.
- Keeping the unknown state only in worker memory, then losing it during restart.
- Allowing dependent steps to proceed using an assumed result.
- Overwriting
unknownwith a generic terminal status to simplify reporting. - Reusing an invocation identifier across logically different actions.
- Escalating to an operator without providing inputs, timestamps, identifiers, and observed evidence.
- Leaving the recovery contract silent about who can resolve the state and on what proof.
Frequently asked questions
When should a harness mark an action as having an unknown outcome?
Use unknown outcome when a side-effecting request may have reached its target but the harness lacks conclusive evidence of completion or failure. Typical triggers include a timeout after transmission, a worker crash during acknowledgement handling, a lost response, or conflicting records that cannot yet establish the resulting state.
Can an agent automatically retry an unknown outcome?
Only when the harness can prove the retry is safe. That proof may come from an idempotency key, an authoritative check showing the first action did not occur, or operation semantics that tolerate repetition. Otherwise, the harness should reconcile, compensate, or request an explicitly authorized disposition.
How does an unknown outcome differ from a pending action?
A pending action is still progressing under an expected execution path, with a defined way to observe completion. An unknown outcome means that path has broken and the available evidence cannot establish what happened. Pending invites continued observation; unknown requires reconciliation before the harness can classify or repeat the action.
What information should be stored with an unknown outcome?
Store the invocation identifier, normalized inputs, target, intended effect, permission context, timestamps, last confirmed event, transport or worker error, and relevant external identifiers. The record should also name the reconciliation method and blocked dependants so recovery can proceed without reconstructing intent from an incomplete transcript.
How should unknown outcomes be tested?
Inject failures after request transmission but before acknowledgement is recorded. Verify that the harness persists an unknown state, blocks unsafe dependants, retains invocation evidence, and does not retry blindly after restart. Then exercise each reconciliation path, including confirmed success, confirmed absence, partial application, and unresolved escalation.