Context Debt: The Liability That Never Shows Up on Your Balance Sheet

Every engineering organisation understands technical debt. It has a vocabulary, a ritual, and a place to live. Somebody files the ticket, somebody argues that the refactor can wait one more quarter, and everybody understands that the argument is a trade rather than a denial. The debt is visible, and visible debt eventually gets serviced.

There is a second liability sitting beside it that almost nobody underwrites. Call it context debt: the accumulated gap between what your organisation actually means and what your organisation has actually written down. Every metric with three plausible definitions and none of them documented. Every join condition that only works because one analyst remembers which of the two customer tables is authoritative. Every exception to the refund policy that lives in a support lead's head because it was never worth the meeting to formalise. Every dashboard whose numbers are correct only if you know which filter was silently applied in 2023.

None of that shows up on a balance sheet, and until very recently none of it needed to. The interest was paid, quietly and continuously, by people. An analyst who had been in the company for six years absorbed the ambiguity before it reached a decision. A senior engineer read a request, understood what the requester actually wanted, and wrote the query the requester should have asked for. Human judgement was the shock absorber, and shock absorbers are invisible right up to the moment you remove them.

Agents remove them. Not by malice and not by incompetence, but by construction: an agent executes on the meaning it is given, at a volume no human reviewer can inspect, and it does so with a confidence that is indistinguishable from correctness in the output text. Which means the debt stops being absorbed and starts being expressed — as wrong answers, as expensive retries, as decisions somebody has to unwind three weeks later.

This is the argument underneath the whole framework this book is built on, and it is worth stating as plainly as possible. The constraint on enterprise AI is not model capability. It is the balance on a liability nobody has been tracking. Chapter 4 sets out why context is the first C rather than a supporting concern, and this essay is the accounting appendix to it.

Context debt is the cost you will eventually pay to make organisational meaning explicit, machine-readable, and current. Three qualifiers, all necessary.

Explicit, because meaning that exists only in a conversation is not an asset. It cannot be versioned, tested, granted, revoked, or handed to a system. Machine-readable, because a beautifully written policy document that no retrieval layer indexes and no tool contract references does not change agent behaviour at all — it merely relocates the debt into a wiki. Current, because context has a decay rate. A definition that was accurate two reorganisations ago is worse than no definition, since it is confidently wrong rather than usefully absent. Chapter 11 makes the case that context has to be treated as a living layer for exactly this reason.

Note what context debt is not. It is not a documentation problem, although documentation is one instrument for paying it down. It is not a data quality problem, although the two are correlated and often confused. Data quality asks whether the values in a column are trustworthy. Context debt asks whether anybody has written down what the column means, who is allowed to use it, which definition of the business concept it implements, and what happens at the edges. A column can be perfectly clean and completely ambiguous, and in most enterprises the ambiguous ones are the ones that end up in the board pack.

It is also not the same as technical debt, and the difference matters operationally. Technical debt is carried by systems, so it can be paid down by engineers working alone. Context debt is carried by the organisation, so paying it down requires somebody with the authority to decide what a word means. That is why it accumulates: the work is cheap, and the decision is political.

Context debt accrues on four separate ledgers, and treating them as one is why remediation programmes stall. Each has a different owner, a different instrument, and a different failure mode.

The first ledger is undefined metrics. Not missing metrics — contested ones. Revenue, active customer, churn, on-time delivery, gross margin: every one of them has a canonical definition somewhere in a finance model and three competing implementations in three warehouses. When a human analyst answers a question about churn, they choose a definition, usually correctly, based on who asked and why. An agent chooses whichever definition retrieval happened to surface. The failure mode is quiet disagreement between two systems that both look authoritative.

The second ledger is meaning held in heads. The unwritten rule that a certain region books revenue a week late. The exception process that has never been in the policy document. The knowledge that one source table has been unreliable since a migration. This is the most valuable material in the organisation and the least portable, and it walks out of the building at a predictable annual rate. Chapter 10 treats institutional memory as the real moat, which is the same observation stated as an asset rather than a liability.

The third ledger is stale documentation. This ledger is dangerous because it looks like an asset on inspection. A runbook exists, a data dictionary exists, an architecture diagram exists — all written eighteen months ago, none reviewed since, all now describing a system that has moved. Retrieval does not know the difference between current and expired truth. It ranks by similarity, not by freshness, unless you have deliberately taught it otherwise, which is a retrieval mechanics problem covered in Chapter 35.

The fourth ledger is platform-locked semantics. Meaning that has been made explicit and machine-readable, and then encoded in a form only one vendor can read. This is the ledger that feels like progress while it is being created. You did the work; you defined the metrics; you wrote the tool descriptions — and all of it now lives inside a console you would have to abandon to change platforms. Chapter 12 argues that portable context is the only kind worth accumulating, and Chapter 34 explains why lock-in migrated up the stack into precisely this layer.

For most of the analytics era, context debt behaved like an interest-free loan. The volume of questions was bounded by the number of humans asking them, and every question passed through a human who could detect an ambiguous answer before it mattered. The liability was real, but the interest rate was close to zero.

Agents change three variables at once, and each of them multiplies the other two.

Volume is the obvious one. A workflow that processed forty requests a day through two analysts now processes four thousand through an agent, which means an ambiguity that used to surface twice a week surfaces two hundred times a day. Nothing about the ambiguity changed. Its expression rate changed by two orders of magnitude.

Autonomy is the second. An analyst who is unsure asks a clarifying question, because being wrong in public is embarrassing. An agent, absent explicit instruction, resolves ambiguity silently and proceeds, because proceeding is what it was built to do. Every unresolved definition therefore becomes a coin flip executed at machine speed. Governing that behaviour — deciding where an agent must stop and ask — is the subject of Chapter 15.

Compounding is the third and the most expensive. Agent output becomes input. A summary written on a bad definition is retrieved next week as if it were a source. A memory entry recording a wrong resolution is treated as precedent. A downstream agent inherits the error with none of the provenance that would let anybody catch it. This is how a single undefined metric becomes an organisational belief in about a month, and it is why Chapter 36 treats compaction and token budgets as a correctness concern rather than a cost optimisation.

Put the three together and the cost curve stops being flat. In the human era the cost of undocumented meaning rose roughly with headcount. In the agent era it rises with agent volume, and agent volume is the number every executive in your company is currently trying to increase.

A liability nobody has quantified will always lose the argument to a cost nobody can deny, which is why compute invoices get scrutinised and context gaps do not. So quantify it. Four measurements, none of which require new tooling, all of which can be produced in a fortnight.

First, definition coverage. Take the twenty business terms that appear most often in agent traffic. For each, record whether a single canonical definition exists, whether it is machine-readable, whether it has a named owner, and when it was last reviewed. Coverage is the percentage that passes all four. Most organisations that run this honestly land between ten and thirty percent, and the result is usually the most persuasive slide in the programme.

Second, the ambiguity rate. Sample a hundred real agent interactions and classify how many contained a term with more than one defensible interpretation. Do not classify whether the answer was wrong; classify whether the question was answerable without a guess. This separates a context problem from a model problem, and the separation matters because the two have completely different remedies.

Third, the retrieval staleness rate. Of the documents your retrieval layer actually returned last month, what share were last modified more than twelve months ago, and what share describe systems or policies that have since changed? This is the only measurement on the list that tends to shock people, because stale context is invisible in every dashboard and obvious in every transcript.

Fourth, the concentration risk. For each critical workflow, how many people could reconstruct the necessary context if they were the only one available? A count of one is a single point of failure that your incident process does not currently model. Chapter 23 covers the organisational shape that reduces this number, and Chapter 26 covers who is accountable for keeping it low.

Report all four monthly, next to your agent volume and your cost per resolved task. The point is not the elegance of the metrics. The point is that a number moves an argument and an anecdote does not.

Context debt cannot be cleared in a programme, because it accrues continuously and because most of the balance is not worth paying. Pay down the part that is load-bearing, in order, and let the rest sit.

Quarter one: define the top twenty. Not the top two hundred. Take the twenty terms your agents encounter most, write one canonical definition for each, assign a named owner who has the authority to arbitrate, and record a review date. This is deliberately small, because the failure pattern for semantic work is an eighteen-month enterprise glossary project that ships nothing. Twenty definitions in ninety days changes agent behaviour measurably; two hundred definitions in two years changes nothing, because the programme is cancelled at month fourteen.

Quarter two: put those definitions into a semantic layer that both humans and agents read from. One source, referenced by the retrieval layer and by tool contracts, so an agent answering a question about churn resolves the term the same way the finance model does. If the definitions live in a document that no system queries, you have converted head-held debt into wiki-held debt at full cost and no benefit. Chapter 6 covers what this layer has to contain to be useful to a model rather than merely correct.

Quarter three: put evaluations on retrieval. Build a labelled set of real questions with known-correct answers, and measure whether your system retrieves the current definition rather than a plausible neighbour. This is the instrument that tells you whether quarter one and quarter two actually worked, and it is the same instrument that catches regression when a model changes underneath you. Chapter 29 treats evaluation as infrastructure for precisely this reason, and the economics of running it are covered in Chapters 18 and 21.

Quarter four: make it portable. Export the semantic layer, the memory schema, the tool contracts, and the evaluation suite into formats you own. Everything you built in the first three quarters is now an asset, and an asset you cannot carry across a platform boundary is an asset somebody else controls. Chapter 19 covers the cost side of that dependency and Chapter 12 covers the portability discipline itself.

Four quarters, four instruments, one principle: make meaning explicit, make it machine-readable, keep it current, and keep it yours.

The most common complaint about enterprise AI in 2026 is that the pilots were impressive and the production systems are disappointing. The usual explanation blames the model, which is convenient, because a model is somebody else's problem and a new one arrives every few months.

The context debt framing gives a less comfortable and more useful explanation. Pilots run on curated context. Somebody hand-picked the documents, the metrics were agreed in the room, the scope was narrow enough that ambiguity never surfaced. Production runs on your actual organisational meaning, unedited, with every undefined term and every stale runbook included. The model did not get worse between the demo and the deployment. The context did.

Which is why the next model release will not fix your programme, and also why that is good news. Capability is a commodity your competitors can buy on the same terms you can. The balance you carry on those four ledgers is specific to you, and so is the advantage you get from paying it down. Every definition you make explicit, every piece of meaning you move out of a head and into a layer your systems read, every stale document you retire, is a permanent improvement to the ceiling of what any model can do inside your company.

That is the whole thesis of this book stated as an accounting identity. The organisations that win the agentic era will not be the ones with the best model. They will be the ones with the smallest gap between what they know and what they have written down.