Tools Are Contracts, Not Capabilities

Koko: Here is a sentence that should stop any executive cold: an agent's tool documentation is not evidence of its tool permissions. They are not the same thing. They can diverge, they have diverged, and when they do, you have a system that promises a control that does not exist at runtime.

Sam: And it is not hypothetical. There is a date on this. July thirty-first, twenty-twenty-six, in the codebase the piece is drawing from.

Koko: Right. The documentation was generated from one table. The runtime hardcoded seven tools. Everything outside those seven — thirty-three steps — was documented and never registered.

Sam: Thirty-three. And two of them were the highest-risk verbs in the whole set. External submit. Master-data write.

Koko: A system that promised a materiality gate, over a runtime that had no such tool.

Sam: So the gate was in the spec. Not in the code. And nobody caught it, because counting passes — seven registered looks fine, thirty-three documented looks fine, and neither number flags anything wrong on its own.

Koko: That is the opening move of the piece we are in for the next several minutes. It is called Tools Are Contracts, Not Capabilities, and the argument it is making is both more precise and more uncomfortable than it first sounds.

Sam: So let us make the thesis crisp, because I think people will hear the title and think they already agree with it — and then miss what it is actually claiming.

Koko: Go ahead.

Sam: The instinct most people bring to AI tooling is: here is a thing the agent can do. Capability framing. The piece is saying that is the wrong mental model entirely. A tool is a declared, bounded interface with a name, a mode, a permission class, a flag for whether it writes, and a flag for whether it always requires a human, regardless of amount.

Koko: The dotted contract ID is the tell. The piece is insistent on this. E-R-P dot read and E-R-P dot write are the same system and completely different risks. If your naming scheme collapses that to just 'the ERP tool,' you have made the difference unavailable to anyone reviewing the design.

Sam: Which sounds like a naming convention argument until you realize what it is actually a governance argument.

Koko: Exactly. And the reason this matters now — the piece lays this out pretty directly — is that agentic systems are crossing real authority boundaries, and the question of what they may reach, what they may change, and what they must ask permission for is not a product decision. It is a contract. Hence the title.

Sam: Tools Are Contracts, Not Capabilities. And once you have that framing, a lot of things follow that do not follow from the capability framing.

Koko: Let us walk through the architecture, because the piece is doing real work here. Six modes. Eight permission classes. And the modes are what the caller is doing — read, calculate, compose, notify, propose, write. That is a vocabulary for describing the nature of an action, not just its target.

Sam: And the permission classes bind what the host is authorizing. The piece highlights two as especially worth reading closely. Private read and case propose.

Koko: Private read is the line between public evidence and your actual systems. A market price is public read. Your sub-ledger, your contracts, your tax position — private read. And the piece makes a point that I think lands hard for anyone who has sat through an AI vendor demo: that boundary is why most of a real finance portfolio honestly cannot be demonstrated on public data at all.

Sam: Which is a polite way of saying a lot of demos are not showing you the thing you would actually use.

Koko: A very polite way. Case propose is the other one. The piece describes it as what makes 'propose, don't post' a mechanism rather than a promise. Everything in that class produces something a human acts on and moves nothing in a system of record.

Sam: And then there are four contracts where no amount ever opens the gate. External submit. Master-data write. Registry write. Governance enforce. No threshold. The approval requirement never reads the amount.

Koko: The last two are where the piece gets genuinely sharp. Registry write and governance enforce. An agent that can write its own registry state can raise its own autonomy. An agent that can enforce governance can lift its own containment. The piece calls it a separation-of-duties argument in disguise.

Sam: And then there is a detail about negative numbers that I want to make sure we do not breeze past.

Koko: The absolute value point.

Sam: A gate written as a plain greater-than lets a large negative — a credit memo, a reversal — through as though it were nothing. Because negative large is not greater than the threshold. It is a one-line implementation error that turns your materiality gate into a one-directional materiality gate.

Koko: And the workforce number the piece cites puts a cost on all of this. About thirty percent of workers spend roughly half their day moving data between AI tools and other systems. The piece reads that as the tool-contract gap with a price on it — work does not stop crossing the boundary because no contract exists. A person crosses it instead, by hand, repeatedly.

Sam: And the piece is careful about that figure — it tags it with a date, August eighteenth twenty-twenty-six, and notes explicitly that when it moves, the page will record the change and when.

Koko: Which is the piece practicing what it preaches about source hygiene.

Sam: Here is where I want to push back a little, or at least surface a tension the piece does not fully resolve. The cost model section argues pretty forcefully against making every agent read-only for safety. The line is: read-only is not the absence of risk, it is the relocation of the work to the most expensive available integration layer.

Koko: The human doing it by hand.

Sam: Right. But earlier in the same piece, we have a validator who gets read and search and explicitly no write — because you verify, the author fixes. And that is held up as a correct design.

Koko: I do not think those actually contradict each other. The piece is distinguishing between an agent that is read-only as a blanket policy — which it is calling expensive and naive — and an agent that is read-only because its role in the workflow is verification. Those are different things.

Sam: So read-only by role is fine. Read-only by default because we are nervous is what the piece is pushing against.

Koko: And the piece makes the cost argument explicitly: gate everything and the portfolio produces an audit trail nobody reads at a cycle time nobody accepts. The approval gate is not just a control — it converts machine time into calendar time, and calendar time is where working capital lives.

Sam: Okay, that framing I had not put together before and I think it is right. Approvals are not free. They are queued. And queues have a cost that almost never shows up in the token-level accounting.

Koko: The piece's unit of measure is cost per accepted outcome. A loop that reads four systems, proposes once and gets signed is cheaper than one that reads two, posts directly and gets reversed — and no token count will show you that.

Sam: Which is a genuinely different way of scoring agentic work than most teams are currently using.

Koko: And there is the MCP point, which I think is going to land differently for different listeners. The piece is clear that MCP is the agent-to-tool layer. The open standard for exposing a described, bounded interface. It is not the coordination layer. And vendor material blurs those routinely.

Sam: The piece's exact phrase is that the blur is expensive rather than merely imprecise. Concluding 'we have MCP, so our agents are governed' mistakes a tool boundary — where authority is bound — for a coordination boundary, where responsibility is transferred. Those are not the same thing.

Koko: And you cannot govern what you cannot locate in the stack.

Sam: So what does a smart executive actually do with this? Not the architecture team. The person who is being asked to sign off on a deployment.

Koko: The piece gives you a very specific audit question: ask what generates the documentation and what generates the runtime, and whether anything compares them. If the answer is 'they come from different places and nothing cross-checks them,' you have the thirty-three-step problem waiting to happen.

Sam: The fix the piece describes is structural — a single compiler that renders both the documentation and the tool plan, so they cannot disagree because there is only one source. A new step type is a compile error, not a silent omission. That is the architecture that closes the gap.

Koko: Second thing: look at the least-privilege distribution per specialist. The piece is very specific about which roles should have write access and which should not. A checker that can edit what it judges has ended separation of duties. A worker that can spawn its own workers has ended the hierarchy. Both of those are shortcuts that never look like governance decisions at the moment they are taken.

Sam: That is the convenience failure mode. And it accumulates quietly.

Koko: Third: the four contracts with no threshold. If someone on your team tells you the materiality gate handles external submit or master-data write — go check whether the gate actually reads the amount or whether it is hardcoded to always require approval. Those should be hardcoded. The piece is explicit that 'a very high threshold' is the wrong implementation. No threshold is the correct one.

Sam: And check your negatives. Seriously. Check whether the gate is written on the absolute value or the signed value. That is the kind of thing that gets caught in a reversal, not in a review.

Koko: And finally — the read-only instinct. If your current AI governance posture is 'make everything read-only until we are comfortable,' the piece is asking you to be honest about what that actually costs. Thirty percent of workers spending about half their day on manual data movement is not free. It is just not on the AI budget line.

Sam: The thing I keep coming back to is the framing of the two non-tools. N-L-P extract and rules validate — things the agent does over material already in context, no boundary crossed. The piece says declaring them beats omitting them, because an omission is indistinguishable from an oversight. A lookup that quietly returns nothing looks exactly like a contract someone forgot to write.

Koko: The absence of a tool is not self-documenting. Which is, in miniature, the whole argument of the piece.

Sam: Tools Are Contracts, Not Capabilities. You have to write the contract down, you have to enforce it at runtime, and you have to verify that those two things match. Everything else is a promise.

Koko: The forward-looking question I would leave with any executive listening: as your organization moves from single-agent experiments to multi-agent workflows — and you are moving there — who owns the cross-artifact comparison? Who is checking that what the system says it can do and what it actually does at runtime are the same document?

Sam: Because if nobody owns it, the answer is nobody.

Koko: The full, source-verified piece — every figure dated, every claim traceable — is Tools Are Contracts, Not Capabilities, on Koko Knows. Worth reading end to end, especially the table of the four contracts where no amount ever opens the gate. That section in particular reads differently after you have had to explain a control failure.

Sam: Most things do.