Here is a piece of work most finance functions will recognize. It is Tuesday. The close lands Thursday, and three reconciliations are still open.
Now watch a system handle it.
It picks up the procedure it uses for a close — the one your controller wrote, the one that says which accounts to check and in what order. It reads three things: the sub-ledger, the bank feed, and the journal entries posted since Friday. Two reconciliations clear.
The third does not. An intercompany balance will not tie, and the counterparty's ledger closed yesterday, so there is nothing left to reconcile against.
At that point the system does something worth pausing on. It does not stop and wait to be asked what to do. It also does not force the match to make the number go away. It writes a proposed accrual, attaches the evidence, and routes it to a human — then reports back: two cleared, one escalated, still inside the close calendar.
The plan broke. The process didn't.
That is a loop. Everything else in this series is a consequence of it.
What a loop is, in one sentence
A loop is a system that keeps going until the work is done, deciding its own next step along the way.
The contrast that makes it concrete is the thing most people have already used. When you type a question into a chat box, you get an answer. If the answer is wrong, you notice, you revise, and you send it again. You are running the retry loop. That is prompting, and there is nothing wrong with it — it is the right tool for a great many jobs.
A loop moves that work inside the system. It plans, it acts, it checks what happened, it compares that against the goal, and it goes again — without waiting for you to tell it the next step. It stops on a condition someone decided in advance, not on a feeling that it is finished.
The difference is who runs the loop. That is the whole distinction, and it is worth holding onto, because almost every consequence in this series falls out of it.
Why this lands on the CFO's desk and not only the CIO's
Here is the part that surprises people, and it is the reason a piece about agent design belongs in a finance publication at all.
The price of a model call is collapsing. Gartner projects token costs falling 95% by 2030. At the same time it projects the cost of running agents rising fivefold over two years. Those two facts sound contradictory. They are not, and the reason is the loop.
A prompt buys one call. A loop buys a call per turn, until it stops. Cheaper units do not make the bill smaller if the thing you just bought consumes many more units per piece of work. Our own analysis of the corpus has been saying this for a week, at high confidence: enterprises face rising total AI spend even as inference costs fall, because adoption scales faster than efficiency gains. Separately, from an independent set of evidence: AI bills are tripling while per-token costs decline.
So the CFO question is not "which model is cheapest." Every competitor is buying from the same menu. The question is how many turns your loops take, what they reach for on each turn, and whether anyone can see it.
Which produces the sentence this whole series is built around:
An unobservable loop is an unbudgetable one.
That is not a governance nicety. Our reading of the field says enterprises cannot calculate a return on AI because they do not have a complete cost picture. You cannot forecast what you cannot count, and a loop that leaves no trace is uncountable by construction.
What a loop is not
This one sentence will save you a procurement cycle.
None of these is a loop by itself: a prompt, an API account, a catalog of tools, or a fixed workflow.
Each is a real thing and each is useful. But a prompt is one turn. An API account is a way to pay for turns. A tool catalog is a list of what could be reached, not a system that reaches. And a fixed workflow decides its path in advance — which is often exactly right, and is also the opposite of a loop, because the code chose the steps rather than the model.
Buy any of the four and you have bought something worth having. You have not bought the thing that keeps going until the close is done.
The six parts, named plainly
Take the reconciliation apart and every piece of a working loop is visible in it.
- The loop — it kept going, and it stopped on purpose.
- Tools — it read the sub-ledger, the bank feed, the journals. Three reaches into real systems.
- Skills — it loaded the close procedure, and only that one.
- Governance — it proposed the accrual instead of posting it. Something decided that was not its call to make.
- Memory and state — it knew which two had cleared when it got to the third.
- Observability — we can say all of the above, which is why the run can be priced and reviewed.
Four of those six are where a finance function has actual leverage, and the next three essays take the two with the most: what a tool is allowed to touch, and how a skill stays out of the way until it is needed. Then we name the CFO's own set of them.
One honest caveat before we go. The productivity gains being claimed for this technology are, on our own reading of the evidence, accruing to a small vanguard rather than the median employee. This series is not an argument that loops are easy. It is an argument that they are budgetable — and that the organizations already embedding control into them are, on the evidence, moving faster than the ones waiting for the framework to arrive.
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). He explained a harness through Dad. We are explaining one through the close. The teaching devices are his; the finance domain, the loop library and every figure here are ours.