Context Management: The Complete Guide

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. It is not the Kubernetes sense of context, switching between cluster configurations; not the CRM sense, the record a system keeps about a customer; and not the ITSM sense, the history attached to a ticket. Those three manage where you are pointed, what you know about an account, and what happened to a request, and none of them decides what an organization stands behind.

The distinction stopped being academic when software started acting on answers instead of displaying them. A person who reads a wrong number on a dashboard 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 dashboard never gave them, and the wrong number gets caught.

An agent has none of that. It receives a number, treats it as true, and does the next thing. Then the next. Judgement was the control, and it has been removed from the loop.

Why is context management a category rather than a feature?

There is a prevailing answer to this, and it is worth stating fairly because it is not stupid. On that account, context management means routing the governance assets you already own (catalog, glossary, lineage, access policy) to agents at query time. You have spent a decade describing your data. Pipe the descriptions to the model and the model stops guessing. Metadata, delivered well.

That gets you a more fluent agent. It does not get you an accountable one.

Here is the gap. A catalog records what exists. A lineage graph records what happened: this table was built from those three, on that schedule, by that job. Neither records what the business decided. When finance and sales report different customer counts, the lineage is complete and correct for both numbers, and it settles nothing, because the disagreement was never about provenance. It was about what counts as a customer.

Most of your context is inferred. It is a guess with good grammar, assembled from column names, query patterns, sample values, and the statistical shape of how people have used a field. Inference of that quality is genuinely useful and often right. What it cannot do is settle an argument, because nobody agreed to it and nobody can be held to it.

Context becomes authoritative through one mechanism, and only one: a human with the standing to decide has decided, and the decision is recorded where systems can reach it. That is a different kind of asset from a catalog entry, it is produced by a different process, and the work of producing and maintaining it does not belong to any existing category. Which is why it needs one.

The practical question this leaves you with is worth stating in its own right, because it is the one that governs every design decision downstream: which context can be inferred or reasoned through, and where is it non-negotiable? Most of it can be inferred. The part that cannot is small, and getting it wrong is expensive in a way that averages cannot absorb.

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. It divides along four questions.

References: what are the core things? The concepts the business runs on, each carrying one canonical identifier, so that the same thing means the same thing everywhere it appears. Taxonomies, reference data and glossaries live here. The work is rarely discovering the concepts; it is deciding which records resolve to the same one. When Acme Corp has eleven subsidiaries, three of which bill separately and one of which still runs its own ERP after the acquisition, no lookup tells you which of them are Acme for the purpose of a revenue number. Someone decides, and every report Acme appears in inherits that decision.

Relationships: how do they connect? A customer places an order. A supplier ships a product. Modelled properly, those connections capture how the business actually thinks rather than how a particular database happened to be normalized. This is the ontology layer, expressed through conceptual models and open standards like RDF and OWL, and it is what a semantic layer is built from. Get it right and an agent can traverse from a contract to the entity to the entitlement without being told the path. Get it wrong and it answers a different question than the one asked.

Rules: what's allowed? Validation, access and compliance constraints, enforced in the data itself rather than reimplemented in each application that touches it. Policy-as-code and SHACL are how this gets expressed. The point of putting them in the data is that the AI stays governed and stays explainable: the constraint that blocked an answer can be named, which is the difference between a system you can audit and one you can only observe.

Processes: how does work get done? A machine-understandable map of how work flows, so a system can reason about sequences, states and decisions rather than just facts. Process models, workflows and lineage. 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.

Every one of these exists in your organization right now. The question is whether it exists as a decision a system can act on, or as something four people know and disagree about slightly.

Partial coverage is the common state, and it is worth naming because it feels like progress. Most organizations that have invested in data governance have References and some Relationships: a master data programme produced entity resolution, and a modelling effort produced a hierarchy. Rules and Processes almost never 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.

That split matters for agents specifically. An agent asked "can I quote this price to this customer" needs all four in one answer: which customer this is, what they are entitled to under the parent agreement, what the discount rule permits, and whether the exception has cleared approval. Three out of four produces a confident answer that is wrong in a way nobody can see from the output.

Why does autogenerated context fail?

It fails on authority, not on accuracy. This is the part most easily misread, so it is worth being precise: automated inference is often correct. Modern tooling reads a schema and produces a description of a field that a domain expert would broadly endorse. That is a real capability and it is getting better.

But a description no one has signed is a reading of the evidence. It can be excellent and still bind nobody. Run the test again. Two teams disagree, which artifact settles it? An inferred definition does not, because the response is always available and always reasonable: that is not how we use that field. The inference has no standing to argue back.

A worked version of the same point. An inference engine reads your order tables and concludes that a customer is any party with at least one completed transaction. That is a defensible reading and it matches the data. Support has been working from a different one for years: a customer is any party with an active entitlement, including the several hundred who are entitled through a parent agreement and have never transacted directly. Both definitions are correct about something. Neither can overrule the other, because neither was ever ratified. The argument resumes every quarter, and an agent wired to either one will answer confidently and be wrong for half the people asking.

Human validation is what converts a good reading into an authority. Not because humans are more accurate than the inference, which they frequently are not, but because agreement creates accountability, and accountability is what an agent is missing when it acts. Someone owns the definition. Someone approved the change. Someone can be asked why.

This also sets the realistic division of labour, and the rule is narrower than it first sounds: explicit where it counts, inferred everywhere else. Inference should do the first pass, proposing, clustering, and surfacing the contradictions that need deciding. That work is tedious and machines are better at it. The deciding is the part that cannot be delegated, and the volume of decisions that actually need making is far smaller than the volume of metadata, because most fields are not contested by anyone.

What makes this tractable is that the states are a path rather than a binary. Context is inferred, then promoted to authoritative once someone with standing signs it, then consumed by whatever asks. Managing that promotion path (who asserted it, when, and what changed) is most of the operational work.

What does decision-grade mean?

Decision-grade is the bar context has to clear before a system should be allowed to act on it. Four properties, and all four are required.

Accurate. It reflects what the business actually decided, not what the data suggests.

Repeatable. The same question returns the same answer next week, and if it changed, the change is visible and attributable.

Efficient. It resolves at the speed and cost that the calling system can absorb, because context nobody can afford to consult is context nobody consults.

Safe. Access policy travels with the context rather than being enforced somewhere alongside it, so answering correctly never means answering someone who should not have asked.

Most context in most organizations clears one or two of these. A glossary is often accurate and rarely repeatable, because the definition lives in a document that was last edited by someone who left. A pipeline is repeatable and frequently inaccurate. The four-way conjunction is the hard part, and it is the specification, not a scorecard to grade your current state against generously.

The order is not decorative either. Accuracy without repeatability is an anecdote. Repeatability without accuracy is an error you have industrialized. Efficiency matters only once the first two hold, and safety is last in the list and first in consequence, because the failure mode is not a wrong answer but a correct answer delivered to the wrong person.

How do you actually do context management?

Three stages, and they are a loop rather than a project with an end date. The shortest statement of how the authority gets created is this: AI drafts it, and your experts make it official.

Capture. Point at the data you already have and let inference produce a first draft, the concepts, the connections it can observe, the constraints implied by how the data behaves. That takes minutes rather than the quarter it used to take, and it is the right use of the technology. Then the draft goes to the people with standing to decide, who review it and sign off. That review step is the whole ballgame; it is what converts a good reading into something the organization is committed to. Start with the definitions people already argue about, because a term that has caused two meetings this year is a term worth an hour of somebody's authority. Starting with a comprehensive inventory instead is how these programmes stall in month four with a beautiful spreadsheet and nothing in production.

Activate. Wire the agreed context into the agents and applications that ask the questions, so it serves every one of them rather than being reimplemented per project. That means query time in the systems doing the asking, not a portal a human visits. This is the stage that separates context management from documentation. If a definition is authoritative but an agent cannot resolve against it mid-request, the agent will fall back to inference, and you have a governance artifact rather than a governed system.

Concretely, activation means three things. The context is reachable programmatically, over an interface a retrieval layer or an agent framework can call without a human in the loop. It resolves fast enough that calling it is cheaper than reasoning around it, because a system under latency pressure will route around anything slow. And the access policy attached to the context is enforced at the point of resolution, so the same query from two different callers can correctly return two different answers. Most programmes get the first, underestimate the second, and discover the third in an incident review.

Evolve. Keep it true, governed and current, and do as much of that automatically as the problem allows. The second half of the definition sentence is the half that gets ignored. Businesses reorganize, acquire, launch, deprecate and re-forecast, and every one of those events invalidates context that was correct when it was agreed. The failure here is silent. A stale definition produces answers that are confidently wrong and formatted exactly like answers that are right, so nothing surfaces until someone notices a number they recognize as impossible. Evolution means change detection at the source, a route from the change to the person who owns that definition, and a record of what changed and when. Automation carries the detection and the routing. The sign-off stays human for the same reason it was human the first time.

The scale of the problem is not in dispute. In a Dun & Bradstreet survey of 10,000 businesses across 32 countries, 97% of organizations reported active AI initiatives while only 5% said their data was ready to support them. The gap between those two numbers is not a tooling gap. Most of it is the work described above, which nobody had a name for while the consumers of enterprise data were still people.