Skip to main content
    All shows

    Sunday, October 11 · 12 min

    KokoAI Loops and KokoAI Skills

    0:00-:--
    Speed

    Transcript

    Koko: A major professional services firm has already deployed agents with executive-manager-level autonomy in accounting. Not piloting. Not in a sandbox. Running. And the firms beating their cautious peers are not the ones who moved fast and governed later — they are the ones whose controls are inside the loop itself.

    Sam: Which cuts against basically every governance conversation I have ever sat through, where the sequence is: deploy, then figure out the guardrails.

    Koko: Exactly. And that inversion is the entire thesis of this piece. The advantage is going to the firms where the control is a design decision made before the first run — not a committee that meets after the fact.

    Sam: So the argument is that governance is not the brake. It is what makes the acceleration possible.

    Koko: That is the argument. And it is built on a very specific structure, which is what today's piece actually dissects.

    Koko: So the piece we are going deep on today is KokoAI Loops and KokoAI Skills. The subtitle calls it the finance function's own named library — one loop per unit of work, one skill per procedure. And I think the first thing worth flagging is what the piece says it actually is right now.

    Sam: Yes, and it is unusually blunt about this. It calls itself a designed portfolio. Contracts, tool plans, tests, value pools, with a handful of entries nominated to be made executable first. It is not a fleet of running agents.

    Koko: And they say that the gap between designed and running is where most agent programs actually live. So naming that gap honestly is what makes the rest of the analysis usable.

    Sam: Which is a credibility move as much as an accuracy one. You trust the numbers more because they told you the uncomfortable part upfront.

    Koko: Right. And the structure underneath the library is what KokoAI Loops and KokoAI Skills is really about. Four roles, seven process codes, a readiness computation, and an anti-double-count mechanism. Each one is doing real work.

    Sam: Let us take those apart.

    Koko: Start with the four roles, because the piece is emphatic that these are not seniority labels. You have the specialist — one unit of work, end to end. The orchestrator — holds an end-to-end process, dispatches to specialists, and is the only role that holds the delegation contract. The decision agent — sits across domains by design, handles judgment calls like revenue recognition or contract leakage. And the sentinel.

    Sam: The sentinel is the interesting one. It watches. Continuous controls testing, governance assurance. And here is the critical constraint: it must not be able to repair what it judges.

    Koko: Because a controls-testing loop that could also remediate what it found is marking its own work.

    Sam: Which is where separation of duties lands in an agent portfolio. And the piece makes it structural, not aspirational — there is a named approval gate on registry writes and governance enforcement, regardless of the amount involved.

    Koko: Regardless of amount is doing a lot of work there. That is not a materiality threshold. That is a categorical rule.

    Sam: Now the process taxonomy. Standard finance transformation material gives you five end-to-end domains — record to report, lead to cash, source to pay, forecast to fulfill, plan to perform. This library has seven codes.

    Koko: And the two extras are the interesting part. Cross-process — which covers master data, value realization, and agent governance — work that belongs to no single stream and, if you force it into one, gives an owner with no authority over the others. And tax, carried alongside record to report rather than inside it, because it has its own calendar, its own authorities, its own filing obligations.

    Sam: And the external-submit contract — the one action that actually leaves the enterprise entirely — lives predominantly in the tax code.

    Koko: Which is exactly the kind of thing you want to be able to locate precisely in a taxonomy rather than have it scattered.

    Sam: Now, the double-count mechanism. Because this is where the value conversation gets either rigorous or fictional.

    Koko: The piece names seventeen value pools underneath five levers — revenue, margin, working capital, productivity, risk. Seventeen against five is not redundancy. It is the level at which a benefit can actually be attributed to one loop rather than three.

    Sam: And the failure case they describe is so specific and so recognizable. 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.

    Koko: Summed, they describe a balance sheet that does not exist.

    Sam: And then the discovery of that fact retroactively discredits every number the program has produced.

    Koko: So the fix is a protected key on the value-recording contract. The ledger rejects a duplicate benefit claim against the same key. Not a policy. A mechanism.

    Sam: A rule saying do not double count is advice. A key the ledger refuses twice is a control. I want that on a wall somewhere.

    Koko: Here is where I want to push on something, because I think the readiness computation is both the most useful structural decision in the library and the most uncomfortable finding.

    Sam: Go ahead.

    Koko: The rule is: if a loop holds any write contract, or any read against a system the company operates — the ERP, the contract lifecycle management system, the GRC platform, the tax system, any of them — it is classified as requiring private data. Full stop. No matter how complete the public evidence is.

    Sam: Because a filing cannot evidence a duplicate invoice or a journal anomaly.

    Koko: Exactly. And the consequence, which the piece calls uncomfortable and correct, is that most of a real finance portfolio reads as needing your systems. It should.

    Sam: Which is the direct counter to every vendor demo you have ever seen, where the agent runs beautifully on synthetic data and the implicit promise is that yours will be basically the same.

    Koko: The piece says that a loop touching a private contract that reports itself as demonstrable on public data alone — that is the exact shape every over-promising agent demonstration takes.

    Sam: That is a fairly pointed observation. I respect it.

    Koko: And then there is the agent count issue, which the piece handles by saying do not quote one.

    Sam: Tell me more, because this is either honest or evasive and I have not decided which.

    Koko: Their own codebase has the count recorded in several places that do not agree. A generated file's header prose says one number, four modules say another, a naive text search returns a third. All plausible. One of them counts a type declaration.

    Sam: Oh, that is a very specific and very familiar kind of pain.

    Koko: The rule they adopted: counts are derived, never asserted. Read them off the data at the moment you need them. Treat any count written into prose as decoration.

    Sam: And for the CFO in the room — 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.

    Koko: Which is where I want to push back slightly. I think for a board conversation, some count is useful as a signal of program maturity. You cannot govern what you cannot enumerate.

    Sam: Fair, but I think the piece's point is that a headcount of agents is as useful as a headcount of spreadsheets. What matters is the value contract attached to each one, not the number of instances.

    Koko: Okay, I will give you that. The value card structure is where this gets concrete.

    Sam: Five things. The lever. The baseline — measured, not recalled. The attribution key, which is the double-count key. The unit cost, with acceptance defined by whoever signs the work. And the fifth, which the piece says is the one usually missing —

    Koko: The retirement condition. What would have to be true for this loop to be switched off.

    Sam: Without that, every loop is permanent from the day it launches. The estate only grows. And you end up with the always-loaded overhead of managing an inventory nobody is allowed to prune.

    Koko: I have seen that in software estates and it is not a fun place to be.

    Koko: So what does a smart, busy executive actually do with this?

    Sam: Three things, I think. First: if you are evaluating an agent vendor or an internal program, ask where the controls are. Not whether they exist — where. Are they inside the loop, in the tool contract, in the approval gate, in the trace? Or are they in a governance committee that reviews outputs quarterly?

    Koko: Because one of those is a control and one is a review.

    Sam: Second: the readiness honesty test. Any agent that claims it can demonstrate its finance use case on public data alone — ask what private contracts it actually needs to touch. If the answer is none, it is probably not doing the interesting work.

    Koko: And third: the value card. Before you scale fund anything, check for that fifth element. The retirement condition. If nobody has written it down, the loop has no definition of done, which means it also has no definition of success.

    Sam: The piece's thesis is that the firms already capturing advantage are not moving recklessly — they are moving with embedded controls. The counterintuitive read is that rigorous design is the fast path, not the slow one.

    Koko: Control is the mechanism that makes speed affordable. That is the line.

    Sam: And it is a design decision made before the first run. Cheap then. Expensive to retrofit.

    Koko: The question I keep coming back to is this: if the sentinel role — the one that watches but cannot repair — is the right model for AI governance inside the loop, what does that imply for the humans sitting outside it? Are they the committee that meets after the fact, or are they something more structurally equivalent to the sentinel?

    Sam: That is the uncomfortable question, because the honest answer is probably that a lot of human oversight today is structured more like a review than a control.

    Koko: Which the piece would argue is the expensive retrofitting problem. Get the structure right first.

    Sam: And that structure is laid out in full, with every figure source-verified and dated, in KokoAI Loops and KokoAI Skills on Koko Knows. The full piece is worth the read — not because it tells you everything is under control, but because it tells you exactly what is not yet and why that honesty is the point.

    Koko: That is where we will leave it. Find KokoAI Loops and KokoAI Skills on Koko Knows, read the source chain, and come back with the uncomfortable questions. That is what the piece is designed for.