CORE GUIDE
Model claim vs runtime fact
A model can describe what it thinks happened; only the runtime and external systems can establish what actually happened.
Mental model
Model text is an observation or hypothesis. Runtime state, tool responses, databases and external side effects are the evidence layer.
Why it matters
Many production failures begin when a model statement is promoted into system truth. An agent may say a payment failed, a file was saved or a tool completed even when the runtime has ambiguous or contradictory evidence. The system must distinguish narrated state from verified state.
01
Two truth layers
The model sees a serialized view of the world: prompts, tool outputs and prior messages. The runtime owns execution state and can inspect durable records. When a tool times out or returns partial information, the model may infer a result, but that inference must not silently become the source of truth.
02
Example: a timed-out refund
A refund request times out. The model says 'the refund failed' and retries. Minutes later both requests settle, creating a duplicate refund. The correct system first treats the timeout as unknown, then reconciles against the payment provider before deciding whether to retry.
Common failure modes
- Storing assistant narration as authoritative workflow state.
- Assuming missing tool output means the side effect did not occur.
- Letting generated summaries overwrite stronger source-of-truth data.
Engineering heuristics
- Persist execution facts separately from conversational text.
- Represent ambiguous outcomes explicitly as UNKNOWN or PENDING.
- Reconcile side effects using authoritative external identifiers.
Takeaways
- 01A model can explain state without owning state.
- 02Unknown is a valid runtime outcome and often safer than guessed success or failure.
- 03Authoritative facts should flow into the model, not be invented by it.