Context Management: The Complete Guide
- Every decision runs on two things: the facts, and a judgement about everything the facts do not settle.
- Your enterprise facts are not looked up, they are decided. Nobody can check what counts as an active customer; somebody had to choose.
- A person reading a wrong number argues with it. That correction was free, invisible and load-bearing, and an agent supplies none of it.
- Authoritative context is a small slice of your data carrying most of the weight.
Context management is the discipline of deciding what an AI system is allowed to treat as true about an organization, and keeping that true as the business changes. The word is already overloaded in your stack, where Kubernetes context switches cluster configurations, CRM context is the record on an account, and ITSM context is the history on a ticket: those three track state, while this one decides what the business stands behind.
If you are putting agents anywhere near enterprise data, you have already met the failure that definition describes. Retrieval works. The citations resolve. The answer is wrong, and the postmortem cannot separate a reasoning failure from a definition nobody ever agreed to. Prompt engineering does not close that gap and neither does a better model, because the defect sits upstream of generation.
Underneath the definition is something simpler than the architecture conversation usually allows.
What does any decision actually require?
Two things. The facts, and a judgement about everything the facts do not settle.
Think about deciding whether to drive somewhere tonight. The facts are ordinary and checkable: the distance, the state of the road, how much fuel is in the tank, the time you need to arrive. Then come the judgements, and they are just as concrete: an hour is too long for this particular errand, the forecast is probably wrong, arriving late does not matter tonight.
Notice what each is. A fact is settled: you can point at it, and someone else looking at the same thing gets the same answer. A judgement is a call made on something not settled, by a person who accepted the consequences of making it. Both are required. Facts with no judgement gets you a system that knows the distance and cannot tell you whether to go. Judgement on bad facts gets you a decision made well about a situation that does not exist.
That is not a metaphor for enterprise decisions. It is the same structure, at a different scale.
What does that look like inside a company?
The enterprise word for a fact is ground truth, and the two are not quite the same thing. A fact about the world is checkable by anyone. A ground truth is a fact your organization settled for itself: which legal entities are one customer, what counts as an active account, when revenue is recognized, which products belong to which family. Nobody can look those up. They are positions the business took, other companies took different ones, and yours is a fact inside your walls because somebody with standing decided it.
The judgements are everything people call on top of them. Whether this customer's request is an exception worth making. Whether a contract's terms are close enough to standard to approve. Whether a discount clears the threshold that matters here.
Most organizations hold far more of the second than the first, and that is the interesting part. Judgements are abundant, distributed and largely unrecorded: they live with the people who have been doing the work long enough to know how it goes. Ground truth is scarcer, and scarce in a specific way. Not missing, but unsettled. Four people know what an active customer is. They know slightly different things, nobody has been asked to decide between them, so what should be a ground truth is still four judgements wearing its clothes.
That was survivable for as long as the people holding the judgement were also the ones making the decisions.
Why do agents change the stakes?
Because they are enormous consumers and producers of decisions, and they have no judgement of their own to fall back on.
A person reading a wrong number argues with it. They know the quarter closed late, or that the regional rollup double-counts, or that nobody has trusted that field since the migration. They apply judgement the report never gave them, and the wrong number gets caught. That correction was infrastructure. It was free, it was invisible, and it was load-bearing.
An agent receives the number and acts. Then it acts again. A system that answers a few hundred questions a day is making a few hundred decisions a day, and it makes each of them at the same confidence regardless of whether the underlying ground truth was settled, contested or estimated. Volume is what turns a tolerable ambiguity into an operational problem: one person working from an unratified definition produces an inconsistency, and a system working from the same definition produces a few thousand of them, all formatted identically to correct ones.
This is why "we cannot assess the model's judgement until its truths are solid" is the practical statement of the problem rather than a philosophical one. If you do not know which of your facts were agreed and which were inferred, you cannot tell a reasoning failure from a foundation failure, and you will spend the quarter tuning prompts against a definition problem.
What does decision-grade mean?
Decision-grade is the bar context has to clear before a system should be allowed to act on it without a person in the loop. Four properties, and all four are required.
| Property | What it requires | What it looks like when it fails |
|---|---|---|
| Accurate | Reflects what the business actually decided, not what the data suggests. | A confidently wrong answer that matches the data and contradicts the decision. |
| Repeatable | The same question returns the same answer next week, and where it changed, the change is visible and attributable. | Two teams get different answers and neither can show why. |
| Efficient | Resolves fast enough and cheap enough that the calling system can absorb it. | Systems route around the governed definition under load, leaving it technically correct and practically unused. |
| Safe | Access policy travels with the context rather than being enforced alongside it. | A correct answer reaches someone who should not have it, and nothing about the output looks wrong. |
Efficient is the one teams underestimate. A system that routes around your governed definitions is an ungoverned system with extra steps. Safe is the one that costs most, because its failure produces no visible defect at all.
Most enterprise context clears one or two of these. A glossary is often accurate and rarely repeatable, because the definition lives in a document last edited by someone who left. A pipeline is repeatable and frequently inaccurate. Clearing all four is the hard part, and it is the specification rather than a scorecard to mark yourself generously against.
How does context split?
Along exactly the same line the decision does.
The facts become authoritative context. Ground truths that have been settled by someone with the standing to settle them, recorded where systems can reach them. Not merely accurate context. Ratified context. Ratification is what creates accountability: someone owns it, someone approved the change, someone can be asked why.
The judgements become runtime context. Calls about things nobody has settled, made at the moment they are needed by whatever is doing the calling: a person working from experience, or a system working from column names, query patterns and the statistical shape of how a field has been used. Frequently right. Never binding, because nobody ratified it and there is nothing to appeal to when two teams disagree.
Governance is how a judgement becomes a fact. Not a filing system for definitions. It is the moment of decision, captured. Someone with standing looks at a judgement the organization has been running on informally, decides it, and records the decision. The judgement stops being a call and starts being a ground truth.
That conversion is the whole engine, and it runs one direction only. Inference produces judgements at enormous volume and no amount of it produces a fact. The scarce resource was never derivation. It is ratification.
What are the four types of authoritative context?
Four, and an organization needs all of them. Context is the set of things people, and now agents, reason over, and it divides along four questions.
| Type | Question it answers | What it is | Expressed as | What breaks without it |
|---|---|---|---|---|
| References | What are the core things? | The concepts the business runs on, each with one canonical identifier, so the same thing means the same thing everywhere. | Taxonomies, reference data, glossaries | The same customer counts as three, and every number they appear in is quietly wrong. |
| Ontologies | How do they connect? | How those concepts relate, modelled the way the business thinks rather than the way a database was normalized. | Conceptual models, RDF, OWL | A system answers a different question than the one asked, because it walked the wrong path. |
| Rules | What is allowed? | Validation, access and compliance constraints, held in the data rather than reimplemented per application. | Policy-as-code, SHACL | Nothing can explain why an answer was blocked, so the system is observable but not auditable. |
| Processes | How does work get done? | A machine-understandable map of how work flows, so a system can reason about sequence and state, not only facts. | Process models, workflows, lineage | An agent cannot tell whether something was approved, only that an approval exists somewhere. |
Two of those deserve their concrete version, because the abstraction hides the work. On References: when a customer has eleven subsidiaries, three billing separately and one still running its own ERP after the acquisition, no lookup tells you which of them count toward a revenue number. Someone decides, and every report that customer appears in inherits the decision. On Processes: an agent asked whether a discount is approved needs to know what approval means in this company, which steps have completed, and whose sign-off ends the path.
A context graph is what the four look like when they travel together as one structure.
Here is the part worth sitting with, and it comes from our own field work rather than from a study. What we see in TopQuadrant customer engagements: the authoritative slice is consistently under 5% of all data. It is a small fraction carrying disproportionate weight: the terms, identifiers and rules that other answers are built out of, so an error in them does not stay local. Get a definition of "active customer" wrong and it is wrong in the dashboard, the forecast, the eligibility check and the board pack, simultaneously, with no single place to catch it.
That concentration is good news. Governing 5% of your data deliberately is a project. Governing all of it is not.
Partial coverage is the common state, and it feels like progress. Most organizations that invested in data governance have References and some of the Ontologies: a master data programme produced entity resolution, a modelling effort produced a hierarchy. Rules and Processes rarely made it, because they were never data problems. They lived in policy documents, approval workflows, and the working memory of the person who has been there nine years. An agent asked whether a price can be quoted to a customer needs all four in one answer, and three out of four produces a confident answer that is wrong in a way the output does not reveal.
What is runtime context good for?
More than the framing so far suggests.
Runtime context is where the candidates come from. Point inference at your warehouses, your content systems, wherever the data actually is, and it will propose concepts, surface the relationships it can observe and, most usefully, find the contradictions that need deciding. That last one is the real contribution. The reason nobody ratified "active customer" is usually not disagreement, it is that nobody noticed there was anything to disagree about.
It also gets sharply better when it has ground truth underneath it. Inference anchored to ratified references and ontologies is constrained inference: it resolves against things that are already settled instead of estimating them, which makes it more accurate and more predictable than the same technique applied to raw material. This is the argument for grounding a model in enterprise data rather than in a document store, and it is why retrieval architecture and governance are not separate conversations. It is also most of why GraphRAG outperforms flat retrieval when it does: the graph it traverses is only as good as the entity resolution someone ratified underneath it.
The mistake is treating inference as a substitute for ratification rather than the supply line into it. A definition a system worked out is a proposal. It can be excellent and bind nobody, which is why it cannot settle an argument between two teams no matter how good it is.
So what is context management?
It is the discipline that governs that split: deciding which context has to be ratified, ratifying it, wiring it where systems ask questions, and keeping it true as the business changes.
It is a category rather than a feature because none of the existing categories does this. A catalog records what exists. A lineage graph records what happened: which table came from which job, on what schedule. Neither records what the business decided, which is why lineage can be complete and correct for both of two conflicting numbers and settle nothing. Whether that makes it genuinely new is a fair question and it has an honest answer: the modelling underneath is decades old, and the obligation is new, because the consumer stopped being a person who could apply judgement to a wrong answer.
Where to begin
Start with your truths, and start narrow.
Pick one definition people already argue about. A term that has caused two meetings this quarter is worth an hour of somebody's authority, and it proves the whole path, decide then record then consume, on something the business can feel. Beginning with a comprehensive inventory instead is how these programmes reach month four with a thorough spreadsheet and nothing in production.
Then get the subject-matter experts who actually hold the judgement into the loop, because they are the scarce resource and their time is the real budget. Let inference do the first pass so they are reviewing a draft rather than facing a blank page. Their job is the decision, not the transcription.
Then put it where the questions get asked, which means resolvable at query time by the systems doing the asking, not in a portal someone visits. A definition an agent cannot reach mid-request is a document, and the agent will fall back to inference without telling you.
Then keep it true, because a ratified definition decays the moment the business reorganizes, acquires or re-forecasts, and a stale definition fails silently. The answers keep coming, in the same format, with the same confidence.
Then do it again. The set that needs this treatment is small, it is knowable, and it is where the cost of getting it wrong concentrates. Whether a single agreed version is achievable at all is the question most people arrive with, and the answer is narrower and more achievable than the one they were sold.
