May 11, 2026

The Company Ontology: What the Context Layer Looks Like When It's Built Right

In March, Andreessen Horowitz published a piece called Your Data Agents Need Context. The diagnosis is correct: agents deployed on enterprise data fail not because the models are bad, but because the models have no structured access to how the company actually works. The authors map the problem clearly. They trace the arc from the modern data stack through the agent frenzy to the wall most organizations are now hitting.

We agree with the diagnosis. We think the treatment being proposed by most vendors is still too narrow.

The context layer is being defined as a data problem. It is a knowledge architecture problem.

The a16z article frames the context layer primarily around data systems — semantic layers, metric definitions, canonical entities, table lineage. These are real gaps. But they are the visible surface of a deeper problem.

What agents actually lack is not better data definitions. It is structured access to how the company thinks — the decisions made, the reasoning behind them, the exceptions carved out, the tribal knowledge that lives in no document and no database. The example in the article makes this exact point without quite saying it: the revenue definition failed not because there was no semantic layer, but because "a data team member left last year" and no one updated it. The knowledge was never captured in a form that survives personnel changes.

This is not a schema problem. It is an organizational memory problem.

A data context layer that ties together warehouses and pipelines is necessary infrastructure. It is not sufficient for agents that need to act on behalf of a company — to draft a contract, make a procurement decision, escalate an incident, or represent a position in a negotiation. For those workflows, agents need access to a different kind of knowledge: structured, queryable, and owned by the company itself.

That is what an ontology provides. Not a list of metric definitions. A typed graph of entities, relationships, and decisions — with provenance, with history, and with access controls that reflect how sensitive the knowledge actually is.

Why semantic layers and RAG are architecturally insufficient

Semantic layers were designed for business intelligence. They are good at defining what "revenue" means in the context of a specific BI tool. They are not designed to capture the why behind a decision, the organizational relationships that affect how that decision should be applied, or the history of how the definition evolved.

RAG retrieves. It does not structure. A retrieval system can surface a document that mentions the relevant policy, but it cannot tell an agent that the policy has an exception for customers in a specific tier, that the exception was added after a specific incident, or that only agents operating at clearance level 3 or above should be aware of the exception exists. RAG gives agents text. An ontology gives agents context they can reason over.

The difference is not theoretical. It shows up in production. An agent with RAG access to company documents will hallucinate policy details because documents contradict each other and the model has no way to resolve the contradiction. An agent operating on a structured ontology can traverse the graph, find the authoritative record, and see exactly when it was established and by whom.

The local hosting requirement is not optional for enterprise

The a16z article ends with an open question: Where will this context layer live?

For enterprise, the answer is determined by what the context layer actually contains.

A company ontology holds decisions made, strategic reasoning, competitive positioning, legal exceptions, pricing logic, personnel assessments, and the kind of institutional knowledge that took years to accumulate. This is not data that belongs in a multi-tenant cloud service. It is some of the most sensitive information a company produces.

Cloud-hosted context layers will not pass a serious enterprise security review. The security team at any institution that has survived a data audit knows this instinctively. The data does not leave the building.

This means the architecture is constrained from the start. The context layer must run on hardware the company controls. The kernel that manages it must be auditable. The data it stores must remain within the organization's physical and logical perimeter.

This is not a differentiator. It is the baseline requirement for any enterprise deployment that involves genuinely sensitive institutional knowledge. Products that skip this requirement are not building for enterprise — they are building demos.

The clearance dimension

Not all agents should have access to all company knowledge. This is obvious in theory and systematically ignored in practice.

An agent helping a customer-facing team resolve a support ticket should not have access to the internal pricing logic that determines when to offer a discount. An HR agent processing a performance review should not have access to M&A reasoning that would affect how that review is framed. A procurement agent negotiating a vendor contract should not be able to read the internal assessment of that vendor's competitive position.

Agents operating on a flat knowledge base — where everything is equally accessible to everything — are not enterprise-ready. They are a liability.

A properly built company ontology assigns classification levels to records. Agents receive clearance levels. The intersection of those two numbers determines what any given agent can see. This is not novel architecture — it is how sensitive information has been handled in high-stakes environments for decades. It translates directly to agentic AI.

The clearance system also affects what agents can write. Actions that modify records at or above a threshold require human approval before they execute. The policy layer is not optional and not overridable by prompt. It is enforced at the kernel level.

Immutability and the audit requirement

Enterprise knowledge is not static. Decisions get revised. Policies change. People leave and their judgment gets superseded. A context layer that allows records to be deleted or silently overwritten is not trustworthy.

A properly structured company ontology treats all modifications as append-only. The current state of a record is always the most recent entry in its history. Previous states are always accessible. You can ask the system what it knew about a topic on a specific date and get an accurate answer.

This has two consequences. First, agents operating on historical context can do so accurately — they are not subject to data that has been modified since the context was established. Second, every agent action is attributable to a specific state of the knowledge it operated on. When something goes wrong, you can trace it.

This is the audit trail that enterprise compliance requires. It cannot be bolted on after the fact.

CIM as the inevitable category

CRM was inevitable in 2000. Every company needed a structured record of its customer relationships, and eventually every company got one. ERP before it. The infrastructure category that becomes inevitable is always the one that addresses the most acute information loss.

The acute information loss in 2026 is organizational knowledge. The 42% of company knowledge that lives only in people's heads. The 102 minutes per person per day spent searching for answers that already exist. The agent deployments that fail because the model has no idea how the company actually works.

Company Intelligence Management is the category that addresses this. Not because it is a clever product concept, but because agentic AI made it necessary. Agents cannot operate on a company they do not understand. The companies that build that understanding into a structured, queryable layer — running on their own infrastructure — will have a compounding advantage: every month the system runs, it becomes harder to recreate elsewhere. The moat is the data, not the software.

The category leader will be whoever establishes the standard first. That work is happening now.

Dominir is building the Company Intelligence Management layer — a company ontology that runs on your hardware, enforces clearance-aware access, and maintains immutable history. Request access or read the docs.