Back to the reconciliation one last time, and this time to the first thing that happened rather than the interesting thing in the middle.
Before it read anything, the loop picked up a procedure: the close checklist — which accounts to check, in what order, what counts as tied, what to do when something is not. Your controller wrote it. It is not a clever prompt. It is the same document that has been governing your close for years.
Now the part worth noticing. Your organization has dozens of procedures like it — revenue recognition, tax provision, capital approvals, supplier onboarding, dispute handling, the lot. The loop picked up one of them. The others were never read, never considered, and never paid for.
That is progressive disclosure, and it is the difference between an agent that gets cheaper as you add procedures and one that gets more expensive.
What a skill actually is
A skill is a packaged procedure in its own file. It has two parts:
- a short cover card — a name, and a plain sentence saying when to use me
- a body — the full procedure, and links to whatever reference material it needs
Only the cover card is in front of the model by default. The body loads when the work matches the description.
Think of a shelf of binders in a controller's office. You read the spines. You pull one down. You do not read forty binders to find out you needed the close one — and neither should the system, because in this case reading is not free.
The single most common misunderstanding
A skill does not make the model smarter.
This is worth being blunt about, because a great deal of enthusiasm around "agent skills" quietly assumes the opposite. A skill packages and isolates a procedure you already trust. It carries no new reasoning ability. What it changes is which known-good procedure the system runs, and whether it runs the same one every time.
Which is precisely why finance is the strongest ground for this technology, and it is not the reason usually given. Finance functions have spent decades writing down how work is done. The procedure exists. It is reviewed. Someone owns it. Turning that into a skill is a packaging exercise, not an authoring one — and the alternative, which is to have a model reconstruct your close from general knowledge every time, is both more expensive and much worse.
The always-loaded tax
Here is the mistake that costs real money, and it is made for an entirely reasonable motive.
A team has a valuable procedure. They want the agent to always have it. So they put it into the material that loads on every single run — always available, always ready.
Now every routine question the agent handles carries that procedure. Not once: on every turn of every run, forever. A capital-approvals playbook used in two percent of the work is being paid for in one hundred percent of it, and because a loop takes many turns, that cost is multiplied again by the length of the run.
This is the always-loaded tax, and it is the single most common self-inflicted cost problem in agent design. It is invisible on any dashboard — nothing errors, nothing is slow enough to notice, and the bill simply comes in higher than the model made it look.
The description-plus-body split is what avoids it. You pay for spines. You pull the binder you need.
Our own reading of the field puts a number nearby: enterprise SaaS prices rose 17% year over year while unnecessary token consumption — an "LLM tax" nobody budgeted — adds uncontrolled operational spend on top. The conclusion we draw from it is direct: enterprises without agent context management will see AI ROI erode faster than projected. Context management is not a technical hygiene topic. It is the cost lever with the least resistance behind it.
Writing the description is the actual work
If only the description loads by default, then the description is the trigger. It is how the system decides, in the moment, that this piece of work is the one this procedure was written for.
Which makes the useful description a very specific artifact: it states the case in the words someone would actually use, not the words the procedure would use about itself.
- "Month-end close and reconciliation procedure. Use when balances need to tie, sub-ledgers need agreeing, or an intercompany difference needs resolving before a close date."
- Not: "Financial period-end operational framework."
The second is a title. The first is a trigger. Getting this wrong does not produce an error — it produces a skill that quietly never fires, while everyone assumes it is working because it exists.
Skill, specialist, or fixed pipeline?
The same capability can be packaged three ways, and picking the wrong one is a common and expensive mistake:
- A skill — a procedure loaded on demand when the description matches. Best when the procedure is known, written down, and reused across varied situations.
- A specialist — a separate instance you delegate to, with its own context and its own restricted tool list. Best when you want isolation and a clean handoff, and when the specialist should be unable to do most things.
- A fixed pipeline — the same steps, in code, every time. Best when you want an identical, auditable path and no runtime judgment at all.
The third deserves more respect than it gets in agent conversations. If the work has one correct sequence and no genuine decisions, then a fixed pipeline is cheaper, faster, more auditable and less likely to surprise you. Choosing an agent for something a pipeline handles is not sophistication. It is paying for judgment you did not need.
And a skill does not execute. It describes and dispatches. The running happens in a specialist or in a pipeline. Treating the three as interchangeable is how a design conversation runs for an hour without anyone establishing what will actually happen at runtime.
What this means for the close
Fold parts one, two and three together and the reconciliation reads as a design rather than an anecdote:
One loop that keeps going until the work is done. One skill, loaded because the work matched it. Three read contracts into systems it was permitted to see. One proposal, because posting was not its call. And a record of all of it, which is what makes the run priceable.
Next: the finance function's own library of these — what to name, how to group them, and how to fund a portfolio of loops rather than a pile of pilots.
The starter pack. The ten skills named in the catalog above — and the other thirty-seven in the finance registry — ship as real assets: SKILL.md files with the frontmatter this piece describes, finance-domain JSON schemas for the objects they read and write, and the tool contracts behind them with the approval posture of each. Two tiers, labelled: ten written as trigger metadata, thirty-seven derived from the registry and marked for rewriting. Browse or download it at Finance Agents → Skills pack (access code required).
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 skill library and every figure here are ours.