The essay described a portfolio. This is the structure underneath it — the roles, the process taxonomy, how readiness is established rather than claimed, the anti-double-count mechanism, and what the library honestly is today.
Four roles, and why the distinction is load-bearing
Every entry in the library carries a role, and the roles are not seniority labels:
| Role | What it does | The rule that goes with it |
|---|---|---|
| Specialist | One unit of work, end to end within its scope | The default. Most of the library. |
| Orchestrator | Holds an end-to-end process, dispatches to specialists | Only this role holds the delegation contract |
| Decision agent | Resolves a judgment that spans process boundaries — revenue recognition, contract leakage, sourcing trade-offs | Sits across domains by design |
| Sentinel | Watches — continuous controls testing, agent governance assurance | Reads widely; must not be able to repair what it judges |
The sentinel row is where separation of duties lands in an agent portfolio. A controls-testing loop that could remediate what it found would be marking its own work, and a governance-assurance loop that could alter another loop's registry state would be a control plane the controlled things can reach. Part two's registry.write and governance.enforce gate — named approval regardless of amount — is what makes that structural rather than aspirational.
The process taxonomy is seven codes, not five
Finance transformation material almost always names five end-to-end domains: record to report, lead to cash, source to pay, forecast to fulfill, plan to perform. The library carries seven codes, and the two extra ones are the interesting part.
CROSS_PROCESS— master data, value realization, agent governance. Work that belongs to no single stream and, if forced into one, acquires an owner with no authority over the others. Master data is the clearest case: it re-bases numbers in every stream simultaneously, which is exactly why its write contract is approval-gated regardless of amount.TAX— carried alongside record to report rather than inside it. Tax has its own calendar, its own authorities and its own filing obligations, andexternal.submit— the one contract that leaves the enterprise entirely — lives predominantly here.
An entry can carry more than one code. Continuous controls testing spans record-to-report, source-to-pay and lead-to-cash; revenue recognition spans record-to-report and lead-to-cash. Forcing every loop into exactly one stream would misdescribe precisely the loops whose value comes from spanning.
Do not quote an agent count
A practical warning, learned the expensive way in our own repository.
The number of agents in this library is recorded in several places that do not agree — a generated file's header prose says one number, four modules say another, and a naive text search returns a third. All three are plausible and one of them counts a type declaration.
The rule the codebase adopted is worth generalizing: counts are derived, never asserted. Read them off the data at the moment you need them, and treat any count written into prose as decoration. For a CFO audience there is a stronger version of the same point — the size of an agent estate is not a metric. It measures the number of things you have bought, which is the input, not the outcome.
Readiness is computed, never claimed
The single most useful structural decision in this library is that an agent's data readiness is derived from its tool plan, not asserted by whoever wrote it up.
The rule: if a loop holds any write contract, or any read against a system the company operates — erp.read, clm.read, grc.read, tax.read, ppm.read, catalog.read, registry.read — it is classified as requiring private data, no matter how complete the public evidence is. A filing cannot evidence a duplicate invoice or a journal anomaly, and no amount of public corpus changes that.
The consequence is uncomfortable and correct: most of a real finance portfolio reads as "needs your systems." It should. The test that must never pass is that any loop touching a private contract reports itself as demonstrable on public data alone — which is the shape every over-promising agent demonstration takes.
Two further pieces of honesty in the same design:
- Relevance never renders as a bare number. A score without its reasons is a claim wearing a decimal point.
- A maturity level nobody can verify is unreachable by construction. The library's vocabulary includes a state meaning "at least one provider adapter passes conformance tests" — and because no conformance runner exists here, nothing in the data is permitted to claim it. Entries sit at design-ready (a logical contract and tests exist) or lighthouse (nominated to be made executable first). The absence of the third state is the honest reporting, and building the state before the runner would have been the easy alternative.
Value pools, and the double-count key
The five value levers — revenue, margin, working capital, productivity, risk — are the right vocabulary for a board conversation. The library carries a finer set underneath them: revenue growth, revenue assurance, revenue integrity, margin, working capital, cash flow, liquidity, capital efficiency, close speed, controls, reporting confidence, data trust, decision speed, tax risk, resilience, agent trust, enterprise value.
Seventeen pools against five levers is not redundancy. It is the level at which a benefit can actually be attributed to one loop rather than three, and it is what makes the anti-double-count control possible.
That control is a protected key on the value-recording contract. Writing a validated value claim requires a baseline identifier and a double-count key, and the ledger rejects a duplicate benefit claim against the same key. The mechanism matters more than the policy: a rule saying "do not double count" is advice, and a key the ledger refuses twice is a control.
The failure it prevents is specific and common. Collections prioritization and receivables forecasting will both, honestly and in good faith, claim days of working capital released. So will a disputes loop and a cash-application loop. Each business case is defensible alone. Summed, they describe a balance sheet that does not exist, and the discovery of that fact retroactively discredits every number the program has produced.
What "no value card, no scale funding" actually requires
A value card that survives scrutiny carries five things, and the fifth is the one usually missing:
- The lever — which of the five, named, singular.
- The baseline — what the figure was before this loop existed, measured rather than recalled.
- The attribution key — the double-count key above.
- The unit — cost per accepted outcome, with acceptance defined by whoever signs the work.
- The retirement condition — what would have to be true for this loop to be switched off.
The fifth converts a portfolio into something that can shrink. Without it, every loop is permanent from the day it launches, the estate only ever grows, and the always-loaded tax from part three compounds across an inventory nobody is allowed to prune.
What this library is today, stated plainly
It is a designed portfolio: contracts, tool plans, tests and value pools, with a handful of entries nominated to be made executable first. It is not a fleet of running agents, and nothing here should be read as claiming operating history. Where our own surfaces render agent traces, they are explicitly deterministic simulations grounded in authored steps — not observations of production systems.
That distinction is worth holding onto, because the gap between "designed" and "running" is where most agent programs actually live, and describing it accurately is what makes the rest of the analysis usable.
The counterweight, and why it is the thesis
Almost every finding in this series points one way: costs rising, governance lagging, liability unpriced, productivity accruing to a vanguard. A series that only stacked those would read as "be careful, wait."
Our own analysis says the evidence supports the opposite conclusion. A major professional services firm has deployed agents with executive-manager-level autonomy in accounting, which contradicts the common narrative that agentic AI adoption requires waiting for governance frameworks to mature — early movers with embedded control layers are already capturing productivity and margin advantage over cautious peers.
The operative phrase is embedded control layers. The advantage is not going to firms that moved fast and governed later; it is going to firms whose controls are inside the loop — the tool contract, the approval gate, the trace, the value card — rather than in a committee that meets after the fact.
Which is why this series took the loop apart in the order it did. Every one of those four things is a design decision made before the first run, and each is cheap then and expensive to retrofit. Control is the mechanism that makes speed affordable.
⚠️ Every figure and finding cited across this series is a 2026-08-18 reading. When one moves, this page records the change and the date on which it changed.
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 with an orchestrating layer above it are his teaching devices; the finance domain, the loop library and every figure here are ours.