Skills Load Only When Needed

The essay described progressive disclosure and the always-loaded tax. This is the mechanism, the arithmetic behind the tax, the three packagings stated precisely, and what a finance function has to decide before writing a single skill.

Progressive disclosure, mechanically

A skill is a file with structured frontmatter over a body:

• frontmatter — a name and a description that says when to use it
• body — the full procedure, plus links to reference documents that may themselves be large

Only name and description sit in context by default. The body, and anything it links to, load on demand when the description matches the work.

The consequence is the design property that matters: a repository can hold three dozen skills, each a one-line description over a detailed playbook and links to substantial reference material, and a routine run pays only for the descriptions until a request matches one. The library grows without the baseline growing with it.

That is what makes a skill library the rare enterprise asset with a sublinear cost curve. Add a fortieth procedure and the baseline moves by one sentence.

The description is trigger metadata, not documentation

Because only the description loads, the description is what the model reads to decide whether to invoke. So it must state the use case in the exact phrases a person would actually say, not the phrases the procedure uses about itself.

This gets written backwards constantly, because the natural instinct when naming an internal document is to be formal and categorical. But a trigger is a matching surface, and formality removes exactly the vocabulary that matches.

The failure mode is the important part: a badly worded description throws no error, breaks no test and produces no log line. The skill simply never fires. Everyone assumes it is working, because it exists and is well written, and the model quietly reconstructs the procedure from general knowledge every time — more expensively, and differently on each run.

That last clause is the real damage. The reason to package a procedure at all is that the same work should be done the same way twice. A skill that never fires does not merely waste effort; it silently returns the function to an ungoverned path while presenting as governed.

The arithmetic of the always-loaded tax

Take a procedure of roughly two thousand tokens — a realistic size for a close checklist with its escalation rules.

Loaded on demand. It appears in the runs that need it. If that is one run in fifty, and each such run carries it across, say, twelve turns, the cost is two thousand tokens times twelve, once every fifty runs.

Always loaded. It appears in every turn of every run. Fifty runs at twelve turns is six hundred turns, each carrying two thousand tokens — against twelve turns in the on-demand case. The multiple is the reciprocal of the hit rate, and it applies to the whole portfolio at once, because every always-loaded procedure taxes every other procedure's runs.

Two consequences follow, and both are counter-intuitive.

First, the tax is worst for the procedures that feel most important. The instinct to always-load is strongest for high-stakes, rarely-used material — the capital-approvals playbook, the regulatory-filing checklist — and those are precisely the entries with the lowest hit rate and therefore the highest multiple.

Second, the tax scales with loop length rather than with request volume. A prompting-era assistant pays a bloated baseline once per question. A loop pays it once per turn. So the same design mistake that was mildly wasteful before agents becomes an order of magnitude more expensive after them — which is one concrete mechanism behind the inference paradox from part one. Nothing about the model got more expensive. The number of times per task you pay for your own context did.

The naming discipline

A skill catalog is only navigable if the names are.

Use kebab-case, verb-or-object-led, one job per skill — month-end-close, intercompany-matching, revenue-recognition-review. The naming test that works: if you cannot write a one-sentence "use me when…" without the word and, it is two skills.

The reason is mechanical rather than aesthetic. Matching happens against the description, so a skill covering two loosely-related jobs has a description that matches both weakly instead of one strongly. Splitting improves retrieval and shrinks what loads when either fires.

Skill, subagent, workflow — stated precisely

Two clarifications that resolve most confusion in the room.

A skill does not execute. It is knowledge plus a trigger; it describes and dispatches. The actual running happens in a subagent (model-driven) or a workflow (code-driven). A design discussion that never establishes which of those two is doing the work has not produced a design.

Subagent versus workflow is exactly the model-driven versus deterministic call — the same question part one's control-path ladder asks. It is not a scale question or a sophistication question. If the sequence is fixed and correct, the workflow wins on cost, latency, auditability and the number of ways it can surprise you.

And the subagent's value is specialization plus tool scoping plus context isolation — not raw power. A specialist that is handed every tool has surrendered two of those three.

What context management means as a discipline

"Agent context management" is the phrase our own analysis uses when it predicts ROI erosion, and it is worth unpacking into things a team can actually be held to.

• What loads by default, and why. Every entry in the always-loaded set should have a named reason it cannot be on-demand. The default answer is that it can be.
• What a tool returns. A read that returns a whole record rather than a projection is paid for on every subsequent turn (part two). Tool output shape is a context decision, not just a data decision.
• What survives across turns. Intermediate results that are no longer needed are still being carried. Something has to decide when they stop being carried.
• What is retrieved versus what is remembered. Retrieval costs tokens per run; a durable memory of a settled fact costs them once.

None of these is exotic. All four are the kind of thing that never appears on a roadmap, gets decided by default in the first fortnight, and then sets the unit economics of everything built afterwards.

Why "which skill loaded" belongs in the trace

Part one listed the skill loaded as a required field in any trace you intend to budget from. This is where that pays off.

A monthly model invoice is one number across every loop you run. It cannot be allocated, because nothing in it records what the spend was for. Record which skill fired on each run and the same spend decomposes into something a finance function already knows how to read: cost by procedure.

That single field turns three otherwise unanswerable questions into arithmetic:

• What does our close actually cost to run this way? Sum the runs where the close skill fired.
• Which procedures are worth packaging next? Rank by frequency times cost per run — and note that the answer is frequently not the procedure that feels most strategic.
• Is this skill earning its place? A skill with a high load rate and a low acceptance rate is a procedure that fires often and produces work someone redoes. That is the most expensive thing in the portfolio and it is invisible without both numbers.

The third is the one worth building the reporting for. A skill that never fires wastes the effort of writing it. A skill that fires constantly and is wrong wastes the effort of everyone downstream, at volume, and looks like adoption on every chart that counts invocations.

Where skills stop

Two boundaries keep the claim honest.

A skill does not confer permission. Loading a close procedure does not grant the ability to post a journal — that is a tool contract, and the two layers are deliberately separate. A skill that says "post the correcting entry" against a runtime with no such contract produces a loop that proposes and stops, which is the correct behavior and will look like a bug to whoever wrote the skill.

A skill does not make the model correct. It makes it consistent. Packaging a bad procedure produces the bad procedure, reliably, at scale — which is genuinely worse than an inconsistent human doing it, because inconsistency is at least occasionally noticed. Whatever review the procedure gets today, it needs more of once a machine will follow it exactly.

The honest position on effort

Everything above is cheap to say and real work to do. A finance function considering this should expect the first skill to be slow — not because the packaging is hard, but because writing down what is actually done, as opposed to what the policy document says is done, is the part organizations have been deferring for years.

That is also the strongest argument for starting. The artifact produced is useful whether or not an agent ever runs it, and it is the one input no vendor can supply.

⚠️ The SaaS pricing and token-consumption figures referenced here are 2026-08-18 readings. When they move, this page records the change and the date on which it changed.

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 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 six-part anatomy, the traced run and the named-skill catalog are his teaching devices; the finance domain, the skill library and every figure here are ours.