Session 5. A deterministic mini-agent — Fri 18 Sep

Quick quiz (ungraded)

A model would be too slow for a two-hour session
Speed is not the issue. FakeLLM answers instantly and still could not be made to spin on demand.
A scripted plan makes every exit reachable on purpose, so the loop is testable
Correct. You cannot write a test that says 'and now the model repeats itself'. With a plan, the repetition and budget exits are reachable every run.
Because a real agent does not need a model
It needs one for the decide beat. The plan stands in for that one beat so the other three can be tested.

Two steps recorded, and the third call never reached the tool
Correct. The budget is checked before the call, so the call you were not allowed to make is never paid for.
Four steps recorded, with the last two marked over budget
That records four calls, which means four calls ran. The budget is a cap on spending, not a label applied afterwards.
Two steps recorded, and the third call ran but was discarded
The result was discarded; the latency and the cost were not. Check before the call.

The budget would eventually stop it too, so either exit is fine
It would stop it after paying for the whole budget, and the receipt would then blame a budget that was never the problem.
Repetition names the fault; a budget stop sends the reader to raise a limit that was fine
Correct. Two exits, two diagnoses. The receipt has to say what actually went wrong.
Repeated calls are always a model bug, and budgets are always an app bug
Both are the app's to handle. The distinction is what the receipt tells the person reading it.

It re-raises, so the caller sees the real error
The caller sees a traceback and loses the two steps that succeeded. A raised error is not a receipt.
stopped_because='tool_error', the two earlier steps, and a refusal naming the tool
Correct. The successful work survives, and whoever reads the receipt knows which tool went away.
stopped_because='budget' with answer set to the error message
That reports the wrong exit and puts a failure where an answer belongs. Only an answer step sets answer.

So a caller can read stopped_because without branching first
Correct. A shape that changes with the outcome forces a branch on every read, and the forgotten branch is the one that mattered.
Because JSON requires a fixed schema
It does not. This is a design choice about the contract, not a serialization constraint.
To keep the receipt the same length in every run
steps varies with the run. It is the keys that stay fixed, not the size.