The Mathematics of AI Agents, laboratory reader ยท Chapter 17

State and Consequence

A lost reply does not say whether the effect happened. Four ideas turn that silence into a decision.

These four demonstrations follow the chapter's agent that sent a request and lost the reply. The first compares repeating a request with sending it once, across the chapter's safe, idempotent and neither classes and a key that is lost. The second turns silence into a belief and prices a retry, a decline and a perfect read. The third follows the recovery sequence and the four ways an undo fails. The fourth runs the repeat set over the chapter's six-step plan.

Every example in these readers is a constructed teaching example. The probabilities, utilities and cases are declared inputs chosen to make the mathematics visible. They are not measurements of any deployed agent, product or team.

Demonstration 1 of 4

Send it twice: what is different afterward?

For which kinds of request does a repeat leave the intended effect unchanged, and what happens when a key is lost?

A read requests no change, and setting a value or deleting a record land in the same place however often they repeat, so the equation holds for all three. A charge adds again each time, so it fails. A stored key lets the service count the charge once, which restores the equation for that request, but only while the service still recognizes the key: a lost key or one past its retention window lets the repeat be applied again. The service may keep a log line per request.

Equation (17.1), written in LaTeX: \operatorname{eff}_{I}(\operatorname{eff}(T,\operatorname{eff}(T,x))) = \operatorname{eff}_{I}(\operatorname{eff}(T,x)) \text{for every reachable } x .

Scroll sideways for the whole equation

T is the tool, x the state of the world, eff(T, x) the state after the tool runs, and eff with subscript I keeps only the coordinates the request asked about (here the record's value). The equation says running T twice gives the same intended coordinates as running it once. Log lines are outside that projection. A safe request is read-only by its defined semantics; a key is a token the service uses to recognize a repeated request.

Predict first. Pick the charge with no key. After three identical requests, will the record end at 150, 200 or 250?

Your prediction

Choose an example

Scroll sideways for the whole figure

Figure: Send it twice: what is different afterward?. Left: bars for the record value at the start and after each of 3 identical requests, ending at 150; the bars are flagged when they differ from the state after one request. Right: the service's log lines, one per request, 3 in all.
Kind of request (three identical requests are sent): Set the record to 150 (idempotent, PUT-like), Key for the charge (no effect on the other kinds): No key
Constructed example: values defined for this reader; effects are counted with the laboratory's effect ledger, whose default trace sends two identical requests with no key and whose changed trace stores the key.

Calculated values

Class (Figure 17.2)
idempotent
Record after one request
150
Record after 3 requests
150
Equation (17.1)
holds
Log lines written
3
Replies
same answer each time
Automatic retry after a lost reply
allowed: the intended effect is unchanged, subject to current authority and the service contract

Every request sets the record to 150, so the record after 3 requests minus the record after one is 150 - 150 = 0. Equation (17.1) holds here: one request and 3 requests leave the same intended effect. The service still wrote 3 log lines, which sit outside the intended-effect coordinate. A reply can differ without breaking the equation, because the equation compares effects, not replies.

Use the idea

Ask of every tool: if this is called twice with identical arguments, what is different afterward? Write the answer on the tool definition, because the agent cannot infer it from a name.

Where the conclusion applies

One tool at one state, with one record and constructed values (start 100, target 150, charge 50). The equation says nothing about sequences of tools, and a key only helps if the service really deduplicates under its contract: it must say what the key identifies, whether the arguments must match, who owns it and how long it is kept. Deduplication is not queryability. The service is also constructed to log every request and to reply as shown.

Common wrong turn: Idempotent means the reply is the same
The chapter says Equation (17.1) is about effects and not responses: a second DELETE can return a different status code and still leave the same intended absence. Choose Delete: the replies differ, and the equation still holds.
What this does not settle

RFC 9110 governs HTTP semantics and is not a specification for agent tools; every transfer in this chapter is an argument by analogy that the chapter states rather than assumes. Equation (17.1) covers one tool at one state and not sequences. The retry costs and the belief numbers are constructed for teaching. Chapter 22 takes up what a safety constraint on a measured cost can and cannot guarantee, including why it says little about state the cost does not register.

Chapter 17 source: "What this does not settle".

Check your understanding: A charge of 50 with a stored key is sent 4 times from a record of 100. Where does the record end?
The key makes the service count it once: 100 + 1 x 50 = 150. Without the key it would be 100 + 4 x 50 = 300, and with the key lost the same 300.

Chapter 17 source: section "The classification the specification actually uses". Demonstration C17-D01.

Demonstration 2 of 4

From silence to a decision: retry, decline or read

After no reply, how likely is it that the effect landed, and what does that belief make of a retry, a decline and a perfect read?

Bayes' rule weighs how likely silence is in each world by how likely each world was. If the likelihoods are equal they cancel and nothing changes; if silence is more likely when the effect landed, the belief rises. Equation (17.3) then prices a retry against a decline: a retry is right with chance 1 minus the belief and wrong with the belief's own chance, and the difference crosses zero at the missing cost divided by the missing cost plus the duplicate cost. A read that settles which world holds removes both losses, so it pays when the best action without it is dearer than the read. When a duplicate costs nothing, retrying is already as good as acting with the information and the read is worth nothing.

Equation (17.2), written in LaTeX: \mathbf{b}'(\text{applied}) = \frac{\operatorname{Obs}(\varnothing \mid \text{applied}) \Pr(\text{applied})}{\begin{gathered}\operatorname{Obs}(\varnothing \mid \text{applied}) \Pr(\text{applied}) \\{}+ \operatorname{Obs}(\varnothing \mid \text{not applied}) \Pr(\text{not applied})\end{gathered}}.

Equation (17.3), written in LaTeX: \operatorname{EU}(\text{retry}) - \operatorname{EU}(\text{decline}) = (1-\beta) c_{\text{miss}} - \beta c_{\text{dup}} .

Scroll sideways for the whole equation

Pr(applied) is the belief that the effect landed, before the silence is taken into account. Obs(silence | applied) is the probability of getting no reply when it did land, and Obs(silence | not applied) the probability of no reply when it did not (0.5 here). b'(applied) is the belief after the silence, written beta in the second equation. In the first equation the empty-set symbol stands for silence, the empty response. The cost written c with subscript miss is the cost of the action never happening (10) and c with subscript dup the cost of applying it twice. EU(retry) minus EU(decline) is how much better a retry is than leaving things alone. A perfect read reveals whether the effect landed, costs 1, creates no effect and finishes while the authorization is valid; after it the agent retries only if the effect is absent.

Predict first. With belief 0.30, a duplicate cost of 40 and a missing cost of 10, which action has the lowest expected cost when a perfect read costs 1?

Your prediction

Choose an example

Scroll sideways for the whole figure

Figure: From silence to a decision: retry, decline or read. Left: belief that the effect landed before silence, 0.300, and after, 0.300, as paired bars with the complementary belief. Right: expected cost of retrying 12.00, declining 7.00 and reading first 1.00; the lowest is Read first.
Belief before silence: 0.3, Chance of silence if the effect landed: 0.5, Cost of a duplicate effect: 40 (workbench IV.1)
Constructed example: the chapter's equal-likelihood baseline and its 0.99 prior; workbench problems IV.1 (belief 0.30, duplicate cost 40, missing cost 10) and IV.3 (a perfect read for 1, and the repeatable interface with duplicate cost 0); the other likelihoods and the duplicate cost 10 are defined for this reader. The duplicate term comes from the laboratory's retry pricing.

Calculated values

Belief before silence (prior)
0.300
Belief after silence (beta)
0.300
Expected cost of retrying
12.00
Expected cost of declining
7.00
Cost of reading first
1.00
EU(retry) minus EU(decline)
-5.00
Retry threshold
0.20
Lowest expected cost
Read first
Gross value of a perfect read
7.00
Net value of the read
6.00

Belief after = (0.5 x 0.30) / (0.5 x 0.30 + 0.5 x 0.70) = 0.150 / 0.500 = 0.300. The two likelihoods are equal, so they cancel and the belief stays at its prior: silence is an uninformative observation, the chapter's honest baseline. Retrying costs 0.3000 x 40 = 12.00 and declining costs (1 - 0.3000) x 10 = 7.00, so Equation (17.3) gives 7.00 - 12.00 = -5.00 (threshold 10 / (10 + 40) = 0.20). A perfect read costs 1: its gross value is the best cost without it, 7.00, and its net value is 7.00 - 1 = 6.00. The lowest expected cost is 1.00, from reading first.

Worked steps

  1. Weight if the effect landed: 0.5 x 0.30 = 0.150.
  2. Weight if it did not: 0.5 x 0.70 = 0.350.
  3. Belief after silence (beta): 0.150 / (0.150 + 0.350) = 0.300.
  4. Retry: beta x c_dup = 0.3000 x 40 = 12.00.
  5. Decline: (1 - beta) x c_miss = 0.7000 x 10 = 7.00.
  6. Equation (17.3): 7.00 - 12.00 = -5.00; threshold 0.20.
  7. Perfect read: gross value 7.00, net 7.00 - 1 = 6.00.

Use the idea

Do not turn a timeout into a probability by instinct, and do not leave the duplicate cost unpriced: a team that has never written it down has still decided, by leaving the choice to the retry library's default. Ask what the service does when the request lands and what it does when it does not, and what a status read would cost.

Where the conclusion applies

Two worlds only (applied, not applied), constructed likelihoods with silence 0.5 likely if the request did not apply, and the chapter's teaching construction: authorized attempts, preconditions hold, a retry certainly applies the effect, no other request costs, and the original attempt can no longer apply. The read is perfect and costs 1, as in workbench IV.3. A real transport symptom rarely supplies either likelihood, and an agent that writes its own status report is feeding its own belief. A request fee, expired authority or changed version would change the comparison. The laboratory's own retry price adds the request cost to belief times duplicate cost and compares that with a verification cost; this demonstration sets the request cost to 0 and follows Equation (17.3), so the notebook default (belief 0.8, retry cost 0.2, duplicate cost 10) is a different frame from the states shown.

Common wrong turn: A 99 percent success rate means the effect landed
The chapter warns that a 99 percent success rate among requests that reach a server does not by itself supply either likelihood of silence. Choose the prior 0.99 with equal silence likelihoods: the belief stays at 0.99, and it moves only when the two likelihoods differ, which the rate does not say.
Check your understanding: Prior belief 0.2 with silence 0.9 likely if applied and 0.5 if not, a missing cost of 10 and a duplicate cost of 10. What is the belief after silence, and does a retry beat a decline?
Belief = (0.9 x 0.2) / (0.9 x 0.2 + 0.5 x 0.8) = 0.18 / 0.58 = 0.310. Retry costs 0.310 x 10 = 3.10 and decline costs 0.690 x 10 = 6.90, so retry wins; the threshold is 10 / (10 + 10) = 0.50.

Chapter 17 source: section "Stage three: the retry decision, priced". Demonstration C17-D02.

Demonstration 3 of 4

Recovery before a repeat: how an undo can fail

When does a recovery tool count as Restored, and how can it fail to?

Restored is a conclusion about a finished sequence, not about a tool. Reading the ledger shows what happened; the undo is another call with its own ways to fail: it may be absent or expired, so it cannot run; it may be partial, restoring some consequences and not others; or it may itself be lost, which repeats the retry question one level down. Only the last stage, verification of every relevant consequence, can make Restored true, and the repeat is then eligible only if Ready also holds.

Equation (17.4), written in LaTeX: \operatorname{Rep}(x) = \{ T : \operatorname{Ready}(T,x) \land [\text{(17.1) holds for this request} \lor \operatorname{Absent}(T,x) \lor \operatorname{Restored}(T,x)] \}.

Scroll sideways for the whole equation

Restored(T, x) is one of the three routes inside the braces of the equation: recovery has already succeeded and verified restoration of every relevant precondition and consequence required for another attempt. Here the relevant consequences are the four in the figure, taken from the chapter's refund example. The stages follow the chapter: observe what happened, perform an authorized repair, then verify and check the fresh attempt's preconditions.

Predict first. Choose the partial undo and move to stage 3. Is Restored true once the money is back?

Your prediction

Choose an example

Scroll sideways for the whole figure

Figure: Recovery before a repeat: how an undo can fail. Four rows for the consequences of the charge, each colored by status at stage 1 (undo works), and a bottom row stating that Restored is false with 0 of 4 verified.
Stage of the recovery sequence: 1. Observe: read what happened, How the undo goes: The undo works and is verified
Constructed example: the chapter's refund, confirmation email, downstream webhook and partner ledger entry, and its four ways an undo fails; the notebook's transfer trace (a request with a lost reply, then a read) supplies the ledger entry in stage 1 through the laboratory's effect ledger.

Calculated values

Stage
1. Observe: read what happened
Undo outcome
undo works
Charge entries on the ledger (at the stage 1 read)
1
Coordinates verified restored
0 of 4
Restored(T, x)
false
Route 3 of Equation (17.4)
does not hold

Verified restored = 0 + 0 + 0 + 0 = 0 of 4, and Restored needs 4 of 4, so Restored(T, x) is false. A read of the ledger finds 1 charge entry and confirms it, so the original request is applied and complete; none of its consequences is undone yet. Do not send another charge: the read shows it landed. Any repeat needs a recovery that is run and verified.

Worked steps

  1. The original request landed but its reply was lost.
  2. A read of the ledger shows 1 charge entry and confirms it: applied and complete.
  3. Coordinates verified restored: 0 + 0 + 0 + 0 = 0 of 4.
  4. Do not repeat the charge; start recovery only if the charge is not wanted.

Use the idea

Treat membership by the recovery route as a claim that needs evidence, like the observation route. Give the recovery path its own retry and escalation limits, so that an agent cannot spend its whole budget trying to clean up.

Where the conclusion applies

The four consequences and their statuses are constructed from the chapter's refund example; a real recovery has its own list. Absent and expired are shown together because both mean no undo can run; the chapter distinguishes them (none exists, or its window closed). Verification is taken to be a reliable read; in the lost-undo outcome no verifying read has been made yet, so nothing counts as verified, and once the read is made that outcome becomes one of the other three. Outstanding attempts must also be resolved or fenced against delayed effects, which this figure does not draw.

Common wrong turn: An undo tool restores the earlier state
The chapter says an undo is not a mathematical inverse: a refund is not the absence of a charge but a second transaction that leaves two ledger entries, takes days and can itself fail. Merely having an undo tool does not establish Restored, which denotes completed, verified recovery.
Check your understanding: A refund returns the money and retracts the email, but the downstream webhook and the partner's ledger entry stay. How many of the four consequences are verified restored, and is Restored true?
1 + 1 + 0 + 0 = 2 of 4, and Restored needs 4 of 4, so it is false.

Chapter 17 source: section "The four ways an undo fails". Demonstration C17-D03.

Demonstration 4 of 4

Which repeats are eligible: the six-step plan

For each step of the duplicate-record plan, does a lost reply leave a repeat eligible?

Equation (17.4) is a logical gate: the request must be Ready and at least one route must hold, either idempotent semantics for this request, proof of terminal non-application, or verified restoration. Steps 3 and 4 have plausible idempotent semantics, so they pass when authority is current; steps 5 and 6 do not, so they need a read that proves the original never applied. An expired authority removes every step whatever the evidence.

Equation (17.4), written in LaTeX: \operatorname{Rep}(x) = \{ T : \operatorname{Ready}(T,x) \land [\text{(17.1) holds for this request} \lor \operatorname{Absent}(T,x) \lor \operatorname{Restored}(T,x)] \}.

Scroll sideways for the whole equation

Rep(x) is the set of tools T whose repeat attempt is eligible at state x. Ready(T, x) means authority, preconditions and retry limits hold now. Absent(T, x) means authoritative proof the original never applied and cannot apply later. Restored(T, x) means recovery succeeded and was verified; none has run here. The plan is the chapter's: search, read both, write a merged record, delete the older one, notify the customer, log to an audit system.

Predict first. With authority current and no extra evidence, is a repeat of the customer notification (step 5) eligible?

Your prediction

Choose an example

Scroll sideways for the whole figure

Figure: Which repeats are eligible: the six-step plan. Six condition bars for step 3: write the merged record: Ready is true, routes held 1 of 3, and the request is in the repeat set.
Step whose reply was lost: Step 3: write the merged record, Evidence in hand: No extra evidence
Constructed example: the chapter's six-step plan and its classification of each step; the evidence cases are defined for this reader from the chapter's own routes.

Calculated values

Step
Step 3: write the merged record
Ready
true
Routes that hold
1 of 3
Membership
in Rep(x)

Writing a specified merged record can be idempotent with respect to that content, if identifiers are stable and the write carries a version condition. Routes held = 1 + 0 + 0 = 1. Ready x routes held = 1 x 1 = 1, and any positive result is membership. The request is in Rep(x): a repeat is eligible, though eligible does not mean free, harmless or required.

Worked steps

  1. Step 3: write the merged record: idempotent for this request? yes, so route 1 is 1.
  2. Evidence: no extra evidence; route 2 (Absent) is 0, route 3 (Restored) is 0.
  3. Routes held = 1 + 0 + 0 = 1.
  4. Ready = 1; Ready x routes held = 1 x 1 = 1.
  5. In Rep(x).

Use the idea

Before a retry leaves, run the gate on that request, not on the plan. If it fails, the next step may be a read, a recovery, a deliberate risk decision or a person. A posterior near zero is a risk estimate, not proof of absence.

Where the conclusion applies

The set is the chapter's conservative construction, not a rule from the HTTP standard. Steps 3 and 4 are idempotent only with stable identifiers and appropriate concurrency conditions; a record version may change between reading and writing. Steps 1 and 2 (search and read) have read-only semantics and are left out. If a read shows a request applied and complete, nothing here is repeated. Evidence goes stale: authority can expire and a version check can become out of date.

Common wrong turn: Idempotent steps make an idempotent plan
The chapter says a sequence of idempotent operations is not idempotent in general, because reapplying a sequence from the middle can interleave with what the first pass already did, and that there is no general rule that sorting operations by membership in Rep(x) produces a valid plan. Equation (17.1) is about one tool at one state.
Check your understanding: A read proves a non-idempotent charge was applied and complete. Is the charge in Rep(x)?
No. Applied is not Absent, the charge is not idempotent and nothing was restored, so 0 + 0 + 0 = 0 routes hold. The request is already done, so stop.

Chapter 17 source: section "A trajectory, classified". Demonstration C17-D04.