Your AI Agent Timed Out. Did the Action Actually Happen?

A timeout is not an outcome. After dispatch, the intended effect may have happened even when the response was lost.

Two materially different worlds

agent → tool → external service
                   ↓
               effect applied
                   ↓
             response lost

A. the effect never happened
B. the effect happened and only the response was lost

Blindly retrying world B can duplicate an issue, deployment, message, transaction or infrastructure change.

Authorization is necessary, but not sufficient

Before dispatch, RuleOak can answer whether the exact action was authorized. After dispatch, a separate question appears: what effect actually happened? A successful transport response is not always proof of the intended external-world effect, and a failed or lost response is not proof of no effect.

The Effect Boundary

intent
  ↓
exact authorization
  ↓
one-use ExecutionLease
  ↓
execute once
  ↓
EffectReceipt
  ↓
independent postcondition verification
  ↓
retry disposition

• do_not_retry when the effect is confirmed;
• a retry path only when no-effect is actually established and retry safety is explicit;
• verify/manual review when the world remains ambiguous.

The original one-use authority is never silently reusable.

Try the failure mode

npx @ruleoak/cli@0.50.0 demo effect-boundary

The demo performs a temporary local filesystem effect, deliberately loses the response, verifies the expected digest and refuses a duplicate retry when the postcondition is confirmed.

Why semantics matter

A tool named write_file does not automatically establish local-filesystem semantics. Trusted or explicitly reviewed Effect Profiles bind postcondition logic to the actual route and resource semantics.