intermediate · Interactive lab
Belief and State
An agent's working state is a model of the world, not the world. Three things have to stay apart: what it believes, what the system knows, and what actually happened — and only the second one is authoritative.
By the end: Tell a tool result from an inference and from a read that has gone stale, whatever the belief sounds like.
Your challenge
Start here. This lab opens with the agent acting at every step, which is the wrong starting point and how an agent behaves by default: its own picture of the world is the only picture it has. Two of these steps are fine to act on, two need a fresh read first, two need the effect confirmed afterwards, and one should not happen at all.
See it happen
Belief, source, and what acting would do
- The agent → Where it came from
- Where it came from → The system
- Where it came from → What it changed
Three things that look the same
The agent holds a picture of the world. Where it came from is the only thing that separates a fact from a guess, and The system is the only place either can be settled.
Learn more
Why this pattern exists
An agent carries a working picture of the world, and that picture is made of three very different things wearing the same clothes. Some of it came back from a tool call and is as good as the system's own record. Some of it came back from a tool call twenty minutes ago and describes a record that has moved since. And some of it the agent worked out — reasonably, plausibly, and with nothing behind it at all. Read as text they are indistinguishable: "the customer wants a refund" looks exactly like "ORD-501 is unpaid". The difference only shows when something acts on them. This lesson is seven steps, each one asking the same question in a different disguise: is this good enough to act on, does it need re-reading first, does the effect need confirming afterwards, or should nothing happen at all?
An agent works through a customer-service queue. Each step shows what it believes, where that belief came from and how old it is, how fast the underlying record moves, and what acting on it would do. What the system would say if it were asked now is not shown until after the decision.
- Tell a tool result from an inference and from a read that has gone stale, whatever the belief sounds like.
- Weigh the age of a read against how fast the record it describes actually moves.
- Confirm an effect instead of reporting an intention, and know when re-reading is only latency.
The rule this lesson applies: Three sources, three different obligations. A fresh tool result is the system's own answer, and acting on it is ordinary engineering. A read has an age, and the age only matters against how fast the record moves: an address read fifteen minutes ago is still an address, while a payment status read twenty minutes ago is a guess. An inference is the agent's own conclusion — it may be right, it has no authority, and the moment it drives something with a side effect the system has been changed on the strength of a sentence nobody checked. There is a second half to this, which is what separates a careful agent from a slow one. Every re-read costs a call, and an agent that re-reads everything before every step is the one that exhausts the rate limit and takes four minutes to answer a question. Re-read what moves; act on what does not. And when a change has been made, the honest way to report it is to ask the system what happened rather than to describe what was attempted — especially after a call whose result never came back, where the agent's belief that "it was applied" is the least reliable thing in the system.