Enterprise AI programs everywhere are discovering the same thing: models are only as good as the context they are given. So, the investment has shifted. Teams are building knowledge graphs, enterprise ontologies, semantic layers, and retrieval pipelines, all to make LLMs and agents more accurate.
The investments are paying off. Answers are sharper, and agents are making fewer mistakes. But the question no one seems to be asking, but should be, is: Who governs the context?
The industry spent a decade learning, often painfully, that data without governance becomes a liability. It is about to relearn that lesson with context, at higher speed and with higher stakes.
This article makes the case for context governance, lays out a framework, and shows how it plays out in the two settings we most often encounter in our consulting engagements: regulated enterprises and large enterprises with scattered agent pilots.
Context is not just more data
It is tempting to treat context as another data asset and fold it into existing data governance. These three differences make context a distinct governance problem.
Context behaves like policy. Whatever sits in an agent's context becomes its working version of the truth and, often, its instructions. An ungoverned table produces a wrong number in a report.
⚠️ Ungoverned context produces a wrong action, taken autonomously and repeated at scale.
Its consumer does not push back. A person reading a stale wiki page applies judgment: this looks old, let me check. An agent treats retrieved context as authoritative and returns a fluent, confident answer.
⚠️ Bad context rarely produces visibly bad output. It produces well-formatted wrong output, which is the hardest kind to catch.
Ontologies encode meaning, not values. A data quality error is typically local to a specific record or attribute, though it may propagate operationally when bad values are copied downstream.
⚠️ A semantic error, such as a wrong definition, relationship, or hierarchy, changes the interpretation itself, affecting every interface built on top of it.
The cost of not governing context
The costs of ungoverned context do not appear on day one. They build quietly, then surface all at once, usually in front of a regulator, an auditor, or a board.
Silent semantic drift. "Active customer" is defined three ways across three context stores. Each agent is right by its own context and inconsistent with the others. Executives get contradictory answers, and trust in the whole program erodes.
Amplified blast radius. One wrong relationship in a shared knowledge graph is inherited by every agent that uses it. The more successful the context program, the further a single error travels.
Stale truth. Policies change, organizations restructure, products are renamed. Context without an owner leaves agents acting on last quarter’s reality, and nobody is looking at it the way they would look at a dashboard.
Entitlement bypass and inference leakage. Retrieval often runs with broader privileges than the person asking. Ontologies add a subtler risk: linked facts can reveal what no single record does.
Unexplainable decisions. If you cannot reconstruct what context an agent had when it acted, you cannot answer a customer complaint, an auditor, or a regulator.
Context poisoning. Anyone who can edit a wiki page or a ticket can now steer an agent. Most of the knowledge estate was never secured with that in mind, because until recently it only had human readers.
Semantic debt. Every team builds its own ontology because it is faster. Reconciling them later costs far more than aligning early, and the debt compounds as agents are built on each version.
Accuracy gains from context are fragile without governance. Governance is not a tax on the accuracy program. It is what makes the gains last.
A framework: Seven principles that hold everywhere
The principles of context governance should not change from one organization to the next. What changes is how they are applied.
These seven are the constant core for context governance.
1. Accountable ownership | Every context asset, whether a definition, an ontology branch, or a retrieval corpus, has a named semantic owner who answers for its meaning. A technical steward alone may not be enough. |
|---|---|
2. Provenance and versioning | You can reconstruct exactly what context an agent had when it decided or acted. |
3. Declared fitness and freshness | Context carries a validity window and a review cadence. Nothing is true forever. |
4. Entitlement-aware assembly | Assembled context inherits the access rights of both its sources and the person asking, including controls on what can be inferred by joining sources. |
5. Change control proportional to blast radius | Changing a concept used by 40 agents deserves more scrutiny than editing one team's FAQ. |
6. Risk-tiered rigor | Governance intensity scales with the consequences of the agent's action. Context that informs a person needs less than the context that drives an autonomous decision. |
7. Closed feedback loop | Agent failures, human overrides, and complaints trace back to the context that caused them, and that context gets fixed. |
The sixth principle does the most work. It is what lets one framework look heavy in a bank and light in an early pilot without becoming two different frameworks.
Setting one: The regulated enterprise
In banks, insurers, and healthcare organizations, leadership focuses on the question, "Can we defend what the agent did?" Not "Is the agent accurate?"
That makes defensibility the driver of context governance here.
Regulated firms already have mature model risk management, with independent validation, change approval, and ongoing monitoring. Most of them draw the model boundary around the weights and the prompt. That boundary is now too narrow.
If a revised ontology definition changes how an agent classifies a high-risk customer, the agent's behavior has changed as surely as if the model had been retrained. A material context change is functionally a model change, and it should be treated as one.
This is also the most practical way in. Regulated firms do not need a new governance function for context. They need to extend the control structures they already have, and regulators are moving in the same direction – from the EU AI Act to sector guidance such as the RBI's AI framework in India.
Provenance comes first: The first question an auditor, ombudsman, or regulator will ask is what the system knew when it decided. Of the seven principles, regulated firms can least afford to defer versioned, reconstructable context. Without it, every other control is unprovable.
Regulatory definitions already have owners; leverage them: Terms such as politically exposed person, vulnerable customer, or material-adverse event are defined by compliance and legal, often by reference to regulation. An enterprise ontology must defer to those definitions, not re-derive them. In practice, the ontology's most sensitive concepts should be owned by the same functions that own the regulatory interpretation.
The trap is over-governance: The instinct in a regulated firm is to treat every document in the retrieval estate as a controlled artifact. That slows delivery to a crawl, and teams respond by building shadow agents outside the control environment, which is the worst outcome.
The distinction that resolves this is between context that informs and context that decides.
Context feeding a research assistant for an analyst needs light-touch controls. Context shaping a credit, claims, or clinical decision needs full model-risk treatment. Drawing that line clearly is the most valuable design decision in a regulated context program.
Setting two: The large enterprise with scattered pilots
The second setting is more common and, in some ways, harder. A large enterprise has a dozen agent pilots across functions. Each team has built its own retrieval pipeline and, often, its own ontology. Nobody has a complete list of what exists.
The driver here is the cost of fragmentation, which shows up the first time two agents give a senior leader two different answers to the same question.
You cannot govern what you cannot see: The starting point is visibility: which context assets exist, which agents consume them, and who built them. This sounds basic, and it is. But in most large enterprises, no one can answer it, and every later decision depends on it.
Govern the core tightly and the edges loosely: Start by tightly governing the small set of shared concepts that appear in cross-functional data products, like the definitions behind the measures and entities used by multiple teams. Agree on those key concepts (e.g., Customer, Product, Revenue, and Employee) for the data products in scope and let each domain extend them as needed, as in federated governance for data products.
The platform is the enforcement mechanism: In a fragmented landscape, the policies teams must follow voluntarily don't survive delivery pressure. Governance succeeds when it is the paved road: if the enterprise platform enforces entitlements, captures lineage, and versions context by default, teams get compliance without asking for it. Build the principles into the platform, and the platform does the governing.
The trap is premature centralization: The tempting response to fragmentation is a central ontology team that owns everything. It quickly becomes a bottleneck, and teams route around it, producing exactly the shadow context it was meant to prevent. The central team should own the shared core and the platform guardrails, and little else.
When agents call agents
In enterprises with scattered pilots, agents built by different teams may interact with each other. At that point, context no longer sits in a store. It moves between agents and is summarized, reinterpreted, and passed on at every hop.
Three risks appear at the handoff
Context laundering: An agent summarizes a low-trust source, and the next agent receives it as a clean, confident input with no trace of its origin.
Entitlement escalation: A downstream agent runs with its own broad permissions and returns information the original user was never entitled to see. Every individual check passes, but the chain leaks.
Semantic mismatch: Two agents built on different definitions of the same concept exchange answers that are correct by each one’s own ontology and wrong for the purpose at hand.
The seven principles still apply. Each needs a form that survives the handoff. Lineage and sensitivity labels travel with the context, and can only become more restrictive downstream, never less. Downstream agents act on behalf of the original user, with the intersection of rights rather than the union. Agents communicate through the shared semantic core, under declared interface contracts. A chain's risk tier is set by its most consequential step, not by the agent that happens to be speaking.
The layer agents use to call one another is the natural place to enforce all of this, alongside an agent registry that records each agent's owner, its context dependencies, and the agents it calls. In multi-agent systems, governance moves from the store to the handoff.
Same principles, different levers
Set side by side, the two settings share every principle but pull three different levers:
The driver that funds governance
The enforcement mechanism that gives it teeth
The sequencing of what comes first
Levers | Regulated enterprise | Enterprise with scattered pilots |
|---|---|---|
Driver | Defensibility of decisions | Cost of fragmentation |
Enforcement | Model risk and existing control frameworks | Platform guardrails (the paved road) |
Sequence | Provenance and versioning | Inventory, then a shared semantic core used in data products |
Principle under most pressure | Change control proportional to blast radius | Accountable ownership |
Classic failure | Over-governance that drives shadow agents | Premature centralization that becomes a bottleneck |
Most failed governance programs get the principles right and one of these levers wrong. They pick a driver leadership does not feel, an enforcement mechanism with no teeth, or a starting point that delays visible value.
Conclusion: Anchor governance where authority already exists
The pattern across both settings is simple. Context governance works when it attaches to a mechanism that already has authority: model risk in a regulated firm, the platform in a large enterprise. Standalone context governance programs, with their own committees and their own policy documents, tend to become documentation exercises.
The context layer is fast becoming part of every enterprise’s control environment. Since it shapes decisions, it deserves the rigor given to anything else that shapes decisions: clear ownership, controlled change, enforced access, and a record we can audit.
The organizations that build that discipline now will keep the accuracy gains they are celebrating today. The rest will find out what their context was worth the first time they cannot explain an agent’s decision.
How can we help
Fractal helps enterprises make context governance real, starting from where they are rather than from a blank page.
Assess the current state. Map the context assets, ontologies, and retrieval pipelines already in use, the agents that depend on them, and where ownership and controls are missing.
Tailor the framework. Apply the seven principles to the organization’s setting, calibrating risk-tiered rigor to the decisions its agents influence.
Anchor governance in existing mechanisms. In regulated firms, extend model risk management and control frameworks to cover context. In large enterprises, build governance into the agent platform as the default path.
Establish the operating model. Define semantic ownership, a shared core of enterprise concepts, and a change process proportional to blast radius.
Close the loop. Define a process to link agent monitoring, human overrides, and incident RCA findings back to the exact context inputs, so the context layer continually improves over time.
