The enterprise AI context layer conversation has a blind spot that is becoming more visible as production deployments mature.
Almost all of the investment - in knowledge graphs, in document retrieval, in semantic layers, in data catalogues - is directed at one type of enterprise knowledge: institutional knowledge. The policies, procedures, historical decisions, organisational rules, and accumulated expertise that define how the enterprise understands itself and how it makes decisions.
This investment is correct and necessary. Institutional knowledge is genuinely hard to structure and retrieve, and the progress being made on knowledge graphs and semantic retrieval is real and valuable.
But institutional knowledge is not the only type of context that enterprise AI agents need. It is not even the type they fail on most frequently in production. The type they fail on most frequently is operational data - the current, dynamic, system-state information that tells an agent what is true right now, as distinct from what the enterprise knows or believes in general.
Conflating these two types of context - treating operational data and institutional knowledge as the same problem requiring the same solution - is the specific architectural error that produces agents with sophisticated institutional reasoning and unreliable operational facts. Understanding why they are different problems, requiring different infrastructure, is the insight that resolves the gap.
Institutional knowledge: what it is and what it requires
Institutional knowledge is the accumulated understanding that an enterprise has built over time. It is relatively stable - changing when policies are updated, when procedures are revised, when organisational structures shift, but not changing continuously or in real time.
Examples of institutional knowledge in a financial services context:
The lending policy specifying income verification requirements for different borrower segments
The claims procedure defining the documentation required for a health insurance claim
The risk framework categorising borrower segments by risk tier
Historical underwriting decisions and their outcomes
Regulatory guidance and compliance requirements
Product terms and coverage specifications
This type of knowledge lives in documents, policy repositories, decision logs, and knowledge bases. It is well-suited to knowledge graph representation - entities, relationships, definitions, and rules that can be structured, indexed, and retrieved semantically. The infrastructure investments being made in data catalogues, knowledge graphs, and RAG pipelines are appropriate for institutional knowledge.
The key characteristic: institutional knowledge is true in general and changes slowly. When an agent needs to know what the lending policy says, the answer is the same today as it was yesterday and as it will be tomorrow, unless the policy has been updated. The knowledge can be indexed and retrieved without real-time connectivity to the system that originally produced it.
Operational data: what it is and what it requires
Operational data is the current state of the enterprise's systems - information that changes continuously and must be accurate as of the moment it is used, not as of the moment it was last indexed.
Examples of operational data in a financial services context:
Whether a specific applicant is currently employed, at which employer, at what salary
Whether a specific employee is currently covered under a group insurance policy
What a specific customer's current account balance and transaction history looks like
Whether a specific loan application is within the currently active product parameters
What a specific employee earned in the current payroll cycle
Whether a specific borrower's contact details are current and reachable
This type of data lives in operational systems - HRMS, CRM, ERP, payroll platforms, banking systems, insurance enrollment systems. It is not well-suited to knowledge graph representation because its defining characteristic is dynamism - it changes continuously, sometimes in ways that are consequential to a financial decision made minutes later.
"An AI agent that knows the lending policy perfectly but does not know the applicant's current employment status is like a doctor who knows the treatment protocol but has not examined the patient. The institutional knowledge is sound. The operational picture is missing."
Operational data cannot be indexed and retrieved semantically without becoming stale. It must be accessed in real time - through live API connections to the source systems that maintain it as a matter of operational necessity. The infrastructure required is fundamentally different from the infrastructure required for institutional knowledge.
Why conflating them produces specific failure patterns
When operational data is treated as a type of institutional knowledge - indexed into the knowledge base, retrieved through semantic search, cached in the context layer - it produces a specific and consistent failure pattern.
The agent's institutional reasoning is correct. It applies the policy, follows the procedure, and produces output that is logically coherent with the enterprise's documented knowledge.
But it applies that correct reasoning to an operational picture that is no longer accurate. The policy says income above $X qualifies for product Y.
The agent retrieves the policy correctly. It retrieves the applicant's income from the knowledge base - which was indexed three days ago when the applicant was employed. The applicant resigned two days ago.
The agent approves a product for an applicant who no longer meets the operational criterion.
The failure is invisible until the outcome surfaces it. The agent's reasoning was correct. The policy retrieval was correct. The operational data retrieval was wrong - not because the retrieval failed but because the infrastructure was not designed to provide current operational data.
This specific failure pattern - correct institutional reasoning, incorrect operational input - is the diagnostic signature of an enterprise context layer that has not separated the two context problems. The knowledge graph is solid. The operational data feed is missing.
The infrastructure each requires
Separating the two context problems makes the infrastructure requirements clear for each.
Institutional knowledge infrastructure:
Knowledge graph for entity and relationship representation
Document index with semantic retrieval capability
Metadata layer with ownership, validation status, and freshness signals
Version control for policy and procedure documents
Access policy enforcement at the knowledge layer level
Operational data infrastructure:
Real-time API connections to operational source systems - HRMS, CRM, ERP, payroll
Unified API layer that normalises data across the diversity of source systems
Pass-through architecture that retrieves current state at the moment of the agent request
Consent management for operational data access where personal data is involved
Provenance records that log what operational data was accessed, when, from which source, under what authorisation
These are not competing infrastructure investments. They are complementary - each solving a different half of the enterprise AI context problem. The knowledge graph and the real-time operational data feed are the two legs that the context layer stands on. Without both, the agent is not standing. It is leaning on the half it has and falling on the half it does not.
How they work together
In a complete enterprise context layer, institutional knowledge and operational data work together in the agent's reasoning process in a specific and complementary way.
The institutional knowledge layer tells the agent how the enterprise thinks about the world - what rules apply, what the policy says, what the historical pattern has been. The operational data layer tells the agent what is actually true right now about the specific situation it is handling.
For an underwriting agent: the institutional knowledge layer provides the credit policy, the risk framework, and the historical patterns of the relevant borrower segment. The operational data layer provides the applicant's current employment status, current salary, and current tenure - retrieved live from the employer's HRMS at the moment of the application. The agent combines both to produce a credit recommendation that is both policy-aligned and grounded in current operational reality.
Neither half of this reasoning is possible without both infrastructure components. The policy-aligned reasoning requires the institutional knowledge layer. The current-reality grounding requires the operational data feed. An agent with only the institutional knowledge layer applies the right rules to possibly wrong facts. An agent with only the operational data feed knows the current facts but does not know how to reason about them in the enterprise's policy context.
This is the complete context layer. This is what enterprise AI agents in consequential production deployments actually need. And this is the architectural clarity that separating the two context problems - rather than treating them as one - makes possible.
The investment in knowledge graphs and semantic retrieval infrastructure is valuable and necessary. It solves half the enterprise AI context problem. The operational data infrastructure - the real-time, governed, provenance-tracked feed from the source systems that hold current operational state - solves the other half. Both halves need to be built. The enterprises that build both will run AI that knows what it should know and knows what is actually true. That combination is what reliable enterprise AI looks like.
