Where you are. Module 1 introduced the treasury desk: the people who decide each afternoon how much cash to leave overnight, what to park in bills, and what to keep liquid for tomorrow’s payments. Everything this module has built makes those decisions executable at any hour, in seconds.
So the obvious thing happens. The decisions become rules, the rules become code, and the code runs without anybody watching.
The obvious thing is also how a treasury loses a great deal of money very quickly, which is why the interesting part of this lesson is not the agent.
The idea in one paragraph
A treasury desk’s routine decisions are mostly conditional rules already: sweep idle cash into bills overnight, pull it back before payroll, keep a buffer against the day’s expected payments. Rails that settle in seconds at any hour make those rules executable by software, which removes the cut-off times that shaped the job. What makes that safe is not the quality of the agent but the cage around it: a per-period spending limit, a list of destinations it may pay, and a switch that stops it. Those constraints are enforced in code between the agent and the rails, so the agent’s correctness is not what the design depends on.
Wider than the screen; scroll it sideways.
The cage does the work
The exercise writes the rules and then tries to break them.
The rules themselves are unremarkable and deliberately so: sweep idle cash into bills after six in the evening, and pull it back when payroll is due tomorrow. Payroll wins over yield every time, which is the sort of ordering a treasurer would state as obvious and a program needs told.
Then the runaway. An agent stuck in a loop proposes fifty payments of a hundred thousand each. Five go through. The hourly cap stops the sixth, and the remaining forty-four never reach the rails.
| attempt | outcome |
|---|---|
| allowed destination, inside the cap | passes |
| a destination not on the list | refused |
| fifty payments in a loop | 5 pass, 45 refused |
n = 3 trials · a caged agent under three conditions
What this does not automate
The rules an agent can run are the ones a treasurer could already state in a sentence, and that is a narrower set than the job.
Deciding the buffer’s size against an uncertain week, judging whether a counterparty is worth the extra yield, noticing that this month’s payment pattern is unusual and asking why: none of those is a rule, and writing one that pretends otherwise produces an agent confidently doing the wrong thing on schedule. The desk’s routine has been automated. The desk’s judgement has not, and the design’s honesty is in the cage, which is an admission that the agent will sometimes be wrong.
Why the cage is code and not policy
One detail separates this from how the same controls usually exist.
A treasury policy document says the desk may not pay more than a limit to destinations off an approved list. That control is real and it is enforced by people following it. An agent operating at machine speed makes that enforcement impossible: nobody reviews four hundred payments an hour, and a control that depends on review is a control that has stopped existing.
So the same rules move into the path. Not a policy the agent should follow, a function it cannot get past. That is the same move lesson 15 of module 6 made with a security’s transfer restrictions and lesson 6 made with the mint invariant, and it is the module’s most transferable idea: when the actor gets fast enough, a rule survives only if it is a condition of the action.
Check yourself
1. Why can a treasury desk’s routine be written as rules?
Because most of it already is conditional: sweep idle cash overnight, pull it back before payroll, hold a buffer for expected payments. What changed is that rails settling in seconds at any hour removed the cut-off times that made those decisions daily rather than continuous.
2. What makes the arrangement safe, and what does it not depend on?
The cage: a spending limit, an allowlist of destinations and a kill switch, enforced in code between the agent and the rails. It does not depend on the agent being correct, which is the point, because an agent that is wrong is wrong immediately and repeatedly.
3. What must be true of the kill switch?
That a human can operate it without the agent’s cooperation. A switch the agent can reach, or one that needs the agent to be responsive to honour, is not one. In the exercise it is checked before every other rule and cannot be cleared from inside.
4. What part of a treasury desk is not automated by this?
The judgement: sizing a buffer against an uncertain week, weighing a counterparty’s yield against its risk, noticing that a payment pattern is odd and asking why. Those are not rules, and writing one that pretends they are produces an agent doing the wrong thing reliably.
Do this
Cage the agent and let it run away.
python3 code/treasury_agent.pyThe starter provides the sweep rules and leaves you authorise: refuse when the kill switch is on, when the destination is not allowlisted, or when the payment would breach the period’s cap; otherwise record the spend and allow it. The assertions check that an allowed payment passes, that a second one breaching the cap does not, that a stranger never passes, that a fifty-payment loop is stopped after five, and that the kill switch outranks everything.
The completed version is in solutions/treasury_agent.py.
What you can now do. You can write a treasury rule set, cage it so that being wrong is survivable, and say which part of the desk’s work the cage is an admission about. The next lesson asks who would buy any of this.