In the reconciliation from part one, the loop hit an intercompany balance that would not tie and wrote a proposed accrual instead of forcing the match.
That was not politeness. It was the only thing it was allowed to do.
Watch the same moment again, one level down.
The loop has read three systems and found the break. The obvious repair is a correcting journal — post it, the accounts tie, the close moves on. The loop asks for exactly that. And the answer comes back: no.
Not "no" from a person who happened to be watching. No from the system, at the moment of asking, because the thing the loop reached for was never a capability it had. It was a promise someone wrote down about what may happen to the general ledger, and posting an unreviewed correcting entry to close a gap is on the wrong side of that promise.
So the loop takes the option it does have — write a proposal, attach the evidence, put it in front of a human — and carries on.
The refusal is the control. Everything a finance function actually governs about an agent lives in that one exchange.
A tool is not a feature the model has
The word "tool" does a lot of quiet damage here, because it sounds like something the model possesses — a capability that came in the box, like arithmetic or grammar.
It is the opposite. A tool is a bounded promise about a system you own. Someone at your company decided that this agent may ask this system for these records, under these conditions, and may do nothing else to it. The model did not bring the tool with it. Your organization issued it, the way it issues a key card.
That reframing has a practical consequence. If a tool were a model capability, "what can this agent do?" would be a question for the vendor. Because a tool is a contract, it is a question for you — answered in your systems, by your people, before any agent runs.
Read, propose, write — and the difference between them
Sort every tool an agent could hold onto one line and three bands appear.
Read. Look at something and change nothing. The sub-ledger, the bank feed, the contract, the control test, the filing calendar. A read tool that goes wrong wastes a turn. It does not create a fact.
Propose. Produce something for a human to act on: a case, a routed item, a recommendation, a decision packet. Nothing in a system of record has moved. Something in someone's queue has.
Write. Change a system of record. Post the entry. Update the master data. Record the value claim. Submit the filing.
Almost every design conversation about agent risk is really a conversation about where a specific piece of work sits on that line, and almost every disappointing agent pilot moved something one band left to be safe and then discovered it had built a very expensive read-only report.
The move that actually works is the one in the reconciliation: keep the write, and change who ends the sentence. The loop composed a complete correcting entry. It just did not get to post it.
Four things no amount ever unlocks
Most write tools can carry a materiality gate — under this amount, proceed; over it, ask. That is a sensible and familiar control, and it is how a finance function already runs.
Four kinds of action do not work that way, and the design says so explicitly:
- submitting a filing or regulated communication outside the enterprise
- changing master data
- changing an agent's own registry state — its release status, its autonomy level
- enforcing a governance decision — blocking, quarantining, containing an agent
Each of these needs a named human approval regardless of amount. There is no dollar figure that makes a regulatory filing routine, and an agent that can raise its own autonomy level or lift its own quarantine is not governed at all — it is supervised by something it controls.
That last one is worth sitting with. It is the finance-function version of a principle every controller already holds: nobody reconciles their own account.
Where the money actually goes
Tool calls are not a side effect of a loop. They are most of what a loop is, and therefore most of what it costs.
Each turn that reaches for a system pays twice: for the model tokens that decide to reach and interpret what comes back, and for the round trip itself — the query, the wait, and the payload that then sits in context for every subsequent turn. A loop that re-reads a system because it did not keep the first answer has made no mistake anyone will see. It has roughly doubled the cost of the run.
And an approval gate is a cost decision as much as a control decision. Routing to a human converts machine time into calendar time, and the item waits. That is often exactly the right trade. It is never a free one, and a portfolio of loops where everything is gated will produce a governance record nobody reads and a cycle time nobody accepts.
There is a sharper version of this. Our reading of the field finds that around 30% of workers spend half their day moving data between AI tools and the systems that hold the real records. Read that as a pricing statement rather than a productivity one: that is what the absence of a tool contract costs. When an agent cannot reach a system, the integration layer does not disappear. It becomes a person, paid by the hour, doing copy and paste — and the ROI timelines built on the assumption that it disappeared will slip.
What to ask for
You do not need to read a schema to govern this. Three questions do most of the work, and any team that cannot answer them has not designed the agent yet:
- What may it read, and from which systems?
- What may it change, and above what amount does a human decide?
- What may it never do without a name attached, whatever the amount?
Answer those and you have written the agent's contract. Everything else — which model, which vendor, which framework — sits downstream of it.
The next essay takes the other half: how the loop knows which procedure to run, and why loading only the one it needs is a cost control rather than a tidiness preference.
The framing of this series — a harness taken apart into six named parts, a single run traced from start to finish, and a catalog of named skills — is inspired by dadloop, an agent harness built and published by Swami Chandrasekaran, Partner and Global Head of AI & Data Labs at KPMG (LinkedIn · github.com/swamichandra/dadloop). The teaching devices are his; the finance domain, the tool contracts and every figure here are ours.