The third ledger: Knowledge debt in the age of AI agents

In my previous post, I described two ledgers. Technical debt lives in code and architecture, and our industry has learned to measure it, gate it and negotiate time to pay it down. Operational debt lives between systems, in the reminders, spreadsheets and manual corrections that keep an organisation working, eventually. I closed with the idea that operational debt is often technical debt that was never written down, paid in instalments by people instead of being repaid once by a system.

I would like to pull on that thread, because “never written down” is about to become one of the most expensive phrases in our profession. For decades, the knowledge nobody recorded was held safely enough by the colleagues who carried it. We are now handing more and more of the work to AI agents, and agents have no colleague to turn to.

What the hero actually carries

When we picture the person who keeps an eventually working organisation converging, we tend to picture effort: late evenings, an extra reminder, a correction applied by hand. Google’s SRE practice gave the visible part of that effort a name, toil, and a budget. The effort is real, but it is not the scarce resource. What is scarce is what these people know.

They know that a rule in the procedure was relaxed two years ago for one customer segment, and why. They know which of the three pages describing the reconciliation is still accurate. They know that the batch can be relaunched safely before six in the morning, but not after. They know the decision taken in a meeting with no minutes, and the workaround that compliance tacitly accepted. Michael Polanyi summed this up in 1966: we can know more than we can tell.

This is the third ledger. Knowledge debt is the gap between what an organisation acts on and what it has actually written down and agreed to be true. It is the principal on which operational debt pays its interest. Every heroic intervention is, at heart, a lookup into a knowledge base that exists in one person’s memory.

For a long time, this arrangement was costly but survivable, for one simple reason: a person who does not know something usually notices. They hesitate, they ask around, they call the colleague who knows. The organisation converges slowly, but it converges towards what the hero knows to be right.

Agents cannot ask Brent

Readers of The Phoenix Project will remember Brent, the engineer every escalation eventually reaches. Now put an AI agent in a seat where the answer used to come from Brent.

The agent does not hesitate. When knowledge is missing, a language model does not stop; it produces the most plausible continuation. Plausibility is a property of text, not of truth, and an organisation’s unwritten exceptions are precisely the things a model cannot find plausible, because they appear nowhere it could have learned them.

Three things change at once.

• Scale. A human hero improvises a few times a week. Agents improvise in every session, in parallel, across every team that uses them.
• Direction. The eventually working organisation still converged, because the hero knew the right answer. An agent with missing context does not converge. It drifts, confidently, and it may drift differently from one session to the next.
• Recursion. What an agent produces, whether code, a summary, a runbook or a design note, lands in the very repositories and wikis that the next agent will read. Unverified output becomes tomorrow’s context. Without a gate, knowledge debt compounds at machine speed.

Underneath these lies a structural shift. In agentic engineering, the marginal cost of producing code collapses, and the constraints move elsewhere: to the quality and freshness of the context we give agents, and to our capacity to verify what they produce. We have spent twenty years industrialising verification, with tests, reviews, pipelines and quality gates. Almost nothing industrialises context. That asymmetry is where the third ledger will hurt most.

It is also why I no longer accept “the agent got it wrong” as a root cause. It is a symptom. The root cause is missing context, stale context or a missing evaluation, and two of those three are knowledge debt.

Plausible is not true

The instinctive response is to index everything. Point a retrieval pipeline at the wiki, the shared drives, the ticketing system and the chat history, and let semantic search find the relevant passage. For discovery, this is a reasonable reflex and a useful one. Retrieval-augmented generation, as Lewis and colleagues introduced it in 2020, was designed for open-domain, knowledge-intensive questions, where the closest passage is usually good enough. For anything normative, it is the wrong tool, and it is worth being precise about why.

Similarity retrieval returns the passage nearest to the question, not the passage that is true. A fluent, well-linked page describing the old procedure is often closer to the question than the terse amendment that superseded it. Most intranets hold several versions of the same rule, and the retriever has no way of knowing that one of them was revoked. It can find the nearest text; it cannot find the most authoritative, because authority is not a property of text. It is a property of a decision someone took.

Similarity retrieval is not reproducible either. Change the embedding model, rebuild the index, adjust the chunking or simply add documents, and the same question may receive a different answer next week. For a general assistant, that is tolerable. For an agent applying a credit policy, a retention rule or a security standard, it is not. You cannot defend a decision whose basis you are unable to reproduce, and “the retriever ranked a different chunk on Tuesday” is not an explanation any auditor will accept.

Both have their place. The mistake is to let the first serve the purpose of the second.

Ratified content: deciding what is true before anyone asks

Ratified content is knowledge that a named, accountable person has reviewed and accepted as authoritative, for a defined scope and a defined period. In practice, every knowledge object carries five properties.

1. An owner. A steward who answers for it. Knowledge without an owner is a rumour with good formatting.
2. A type. Not every claim is the same kind of claim. I find four types indispensable: a regulatory obligation, an interpretation of that obligation, an internal convention, and an empirical assertion about how a system behaves. Each changes for a different reason, whether a new regulation, a legal opinion, an architecture decision or a production observation, so each needs its own revalidation trigger.
3. Provenance. Where the claim comes from, which sources support it and which decision record created it.
4. A shelf life. A date after which the object is no longer served until someone revalidates it. Freshness is not a refinement: derived knowledge fails silently when it goes stale.
5. A ratification event. Recorded and ideally signed, binding the steward to the exact content they approved.

The property that matters most is the one teams resist: unratified knowledge is not retrievable. Quarantine means invisible to agents, not merely labelled as a draft. A draft label is a hint that a model will happily ignore; absence from the corpus is a guarantee.

None of this requires exotic technology. The knowledge lives in Git as Markdown with structured frontmatter, is reviewed through merge requests and is released as versioned packs, just as we release code. Formats are emerging to support it. Google Cloud’s Open Knowledge Format packages organisational knowledge as linked Markdown files with YAML frontmatter, and its second version adds provenance, lifecycle and trust signals. A format is only a container, though. The ratification discipline on top of it is ours to build.

There is an epistemological point here that I find helps teams accept the discipline. Saying the Earth is round is not wrong; it is a simplification. Saying it is an oblate spheroid is more precise, and saying it is flat is simply false. A simplified document is a sphere: good enough at its resolution. An outdated document is a flat Earth. But knowledge about our own systems has a property the Earth does not. Whether we call the Earth round or flat, its orbit stays the same. Whether we call our information system right or wrong, it does not follow the same trajectory. Agents act on what we tell them, and what we ratify becomes what we build.

Deterministic retrieval: the same question, the same answer

Once the corpus is ratified, retrieval can change its nature. Instead of asking which text is most similar, the agent asks which knowledge object governs this case, and at which version. The answer is resolved by identity rather than by ranking. I describe the resulting contract as exact content or nothing.

• Search finds, identity serves. Search may help an agent locate candidates, but the content it receives is resolved by identifier and version, and served verbatim with its owner, provenance and ratification.
• Reproducible by construction. The same question against the same knowledge pack version returns the same answer, today and in two years’ time, when someone asks why the agent acted as it did.
• Fail-closed. When an object is stale, quarantined or revoked, the gateway refuses with an explicit reason. It does not fall back to a paraphrase, a neighbouring document or a cached copy.
• Absence is an answer. When no ratified knowledge exists, the system says so. “There is no ratified rule for this case” may be the most valuable sentence an agent can receive, because it turns an improvisation into an escalation to a person.
• Quoted, not recalled. When an agent relies on normative knowledge, it quotes it, and the quotation can be checked against the source.

For code, the code itself remains the source of truth, and a plain text search over the repository is already deterministic and always current. The ratified corpus is for what code cannot tell you: intent, obligations, conventions, decisions and the reasons behind the exceptions. In other words, exactly the knowledge the hero used to carry.

This is fail-closed design applied to knowledge, and it will feel restrictive at first. An agent that declines more often looks less impressive in a demonstration. In production, and especially in a regulated environment, it is the only kind of agent that is honest about the limits of what the organisation actually knows.

Closing the loop: where operational debt finally gets written down

Ratification without a feedback loop quickly turns into another documentation sprint, out of date by the following quarter. The loop that keeps the corpus alive is the same one that measures operational debt.

Incidents, post-mortems, manual corrections and break-glass accesses all signal that reality has diverged from what was written down. It either revokes an object that has been proven wrong, or it produces a candidate for ratification. The candidate enters quarantine, a steward reviews it, and only then does it become available to agents.

This is how the hero’s workaround finally leaves their head. It ends up in one of two places: as a ratified procedure an agent can apply, or as a missing feature in the technical debt backlog. Either way, it has been written down, and the third ledger has been repaid once rather than in instalments.

What it asks of people

This is not primarily a tooling program. It changes roles, and it is worth saying so plainly.

• Heroes become stewards. The people who carry knowledge today are the right people to ratify it tomorrow. That should be recognised as a responsibility in its own right, with a few per cent of protected time, rather than added to their evenings.
• Architects become knowledge producers. Reviewing diagrams after the fact gives way to owning the normative corpus, with a service level for keeping it fresh. Decisions are recorded as part of deciding, not afterwards. ADR, or it did not happen.
• Some habits stop. Stop indexing the entire intranet for agents and index the ratified corpus instead. Stop maintaining parallel pages for the same fact; choose one home and redirect the rest.
• Telemetry stays about knowledge, never about people. Records of which knowledge objects agents consume are precious signals of quality and gaps. They must never become a measure of individual performance, both as a written commitment and through access control. Trust in the whole system depends on it.

Where to start

The first steps are deliberately small.

1. Choose one domain where agents already work and where mistakes are costly.
2. List the questions agents ask, or would ask, in that domain, and the people who answer them today.
3. Ratify the twenty or so objects that answer most of those questions, each with an owner, a type and a shelf life.
4. Serve them by identity, fail closed, and record every absence.
5. Treat each absence and each incident as a candidate for ratification.

Within a few weeks, the list of absences becomes the most honest map of knowledge debt the organisation has ever had.

What changes

The question an agent cannot ask

A person who does not know says “let me check”. An agent says something. That difference is the whole argument of this post. Our organisations ran for years on knowledge nobody wrote down, because the people who held it were also the ones who noticed when it was missing. Agents do not notice; they carry on.

So the work has moved. Our job is to make sure that what an agent says is something we have agreed to be true, or nothing at all. That is not documentation overhead. It is the context our systems now run on, and, perhaps for the first time, a concrete way to recognise the people who carried that knowledge all along.