May 11, 2026

Why We're Building Dominir

Every major enterprise software category was made inevitable by the same pattern: a new form of coordination required a new form of record.

When companies began managing customer relationships at the scale that sales forces and CRMs operate at, no one had to argue that the category should exist. The work required it. CRM became inevitable the moment companies needed to coordinate around customers across teams, time, and turnover. Salesforce did not invent the need. It built the infrastructure the need had been waiting for.

ERP followed the same logic. When supply chains, finance, and operations became too complex to coordinate through spreadsheets and institutional memory, the category emerged. The software existed because the coordination problem demanded it.

We are building Dominir because agentic AI has created the same conditions for a new category: Company Intelligence Management.

The coordination problem agentic AI exposes

An agent operating inside a company needs to know how that company works. Not what is in its documents. How it actually works — the decisions that have been made, the reasoning behind them, the exceptions that have been carved out, the context that makes a policy mean something specific here rather than something generic elsewhere.

This knowledge does not exist in any system today. It exists in the heads of the people who were present when things happened, in emails that have not been read in three years, in Slack threads that no one remembers, in the institutional memory of a company that has never been structurally captured anywhere.

Humans have been compensating for this gap for as long as companies have existed. A new employee learns by asking colleagues. A senior manager remembers context that the official policy omits. A lawyer knows what the contract clause really means because they were in the room when it was negotiated. The company works because people carry the knowledge that no system holds.

Agents cannot do this. They cannot ask a colleague. They do not remember last quarter's context session. They start from zero every time. And so every agent deployment that encounters company-specific questions — which is every serious enterprise deployment — hits the same wall.

The absence of a company ontology was survivable when humans were the only operators. It is not survivable when agents are.

Why we chose ontology

We looked at the existing approaches and rejected all of them as architecturally insufficient.

RAG retrieves documents. Retrieval finds relevant text; it does not represent structure. An agent with RAG access to company documentation knows what was written down. Most of what actually governs how a company operates was never written down. And what was written down contradicts itself, goes stale silently, and cannot be resolved by a retrieval system that has no mechanism for precedence or authority.

Semantic layers define metrics in YAML files. They are good at saying what "revenue" means in a BI context. They are not built to represent decisions, exceptions, relationships between teams, or the reasoning behind any of it. They are maintained by data teams who leave, and when they leave, the definitions become lies.

Knowledge bases and wikis are retrieval systems with a documentation problem. They capture what someone decided to record. The most important knowledge — the judgment calls, the edge case resolutions, the policy exceptions — lives in the gap between what was documented and what actually happened.

An ontology is different in kind. It represents entities, relationships, and typed connections. A decision is not a document. It is an event with a type, a subject, an authorizer, a date, a clearance level, and a set of records it supersedes. That structure is what makes knowledge queryable by agents — not retrievable, queryable. An agent can traverse the graph. It can ask: who approved this? What did it supersede? Does that authority still hold? What else depends on this record?

This is the architecture Palantir proved at scale, at great expense, for customers who could afford armies of forward-deployed engineers. We are building it as a product — accessible to every company deploying agents, not just the ones with Palantir contracts.

Why it must run locally

The company ontology holds the most sensitive information a company produces. Not customer data — that is already regulated and handled. The ontology holds decision rationale. Strategic reasoning. Competitive positioning. Legal interpretations. Personnel judgments. The reasoning behind pricing exceptions. The context that explains why a contract looks the way it does.

This is information that cannot leave the building. Not as a preference for privacy. As a hard limit imposed by the nature of the content and the requirements of the industries that produce it.

Finance, defense, healthcare, and law cannot transmit this information to external infrastructure. This is a compliance constraint, a security requirement, and in most cases a board mandate. The regulated enterprise — which is the highest-value market for a company ontology, because they have the most to protect — cannot use a cloud CIM. The architecture of the product determines whether it can serve this market at all.

Dominir's kernel runs on customer hardware. The ledger writes to customer disks. Queries resolve against customer memory. Nothing leaves. This is not a feature we added. It is the design we started with. A cloud-native competitor cannot replicate this by adding a checkbox. Local architecture requires building from the OS up, in Rust, with a storage and memory model designed for it. That is a different company.

Why the record must be immutable

Company knowledge is not a current state. It is a history.

The decision made in 2023 remains relevant in 2026 when someone needs to understand why the contract looks the way it does, or why the exception policy reads the way it reads, or why the org structure changed when it did. A system that allows records to be modified or deleted is not a company memory. It is a company amnesia machine — a system that makes the past inaccessible by design.

Dominir's storage layer is append-only. Records are superseded, not deleted. The full history of the ontology is always accessible. An agent operating on a historical contract can be given the knowledge state as of the contract date and reason correctly about it. A compliance audit can trace exactly what the system knew and when. A new employee inheriting a complex account can access the actual history of how it was managed, not just the current summary.

History is an asset. The infrastructure we build treats it as one.

Why clearance is structural

Not every agent should see all company knowledge. This is obvious in principle and systematically ignored in implementation.

The agent handling customer support should not have access to the pricing strategy that determines when exceptions are approved. The agent processing a performance review should not have access to M&A reasoning that would affect how that review is framed. An agent with access to everything is a liability. Access control is not a compliance feature — it is a structural requirement for operating AI in an environment with real stakes.

Dominir assigns clearance levels to records and to agents. The intersection determines what any agent can see or act on. This is implemented at the kernel level. It cannot be overridden by a prompt. It is not a policy; it is a property of the storage layer.

This design also determines what agents can write. Actions that modify records above a threshold require human approval before they execute. The policy layer runs before execution, not after.

Why now

Two YC partners published independent Requests for Startups identifying the same missing primitive. Andreessen Horowitz published their thesis on the context layer in March 2026. Sequoia backed a company building enterprise knowledge infrastructure the same month. McKinsey documented that 80% of companies deploying gen AI report no bottom-line impact — and identified productized, structured, governed data as the missing enabler.

The market is not being created by a product. It is being revealed by deployment. Every enterprise agent deployment that fails on company-specific questions is a data point. The failure is visible, measurable, and expensive. The buyers are awake and looking for the infrastructure that solves it.

The category is open. No incumbent holds it. Every existing player is a search tool, a wiki, or a cloud data product. None is the CIM. The window is the period before one of them decides to become it — or before the category coalesces around someone else.

What we're building

Dominir is a Company Intelligence Management system. A kernel written in Rust that holds the company ontology — decisions, relationships, reasoning, context — in an append-only, clearance-aware graph that runs on your hardware.

Agents connect to it over MCP. They traverse the graph rather than retrieving documents. They operate with structured knowledge about how the company works, not with search results from a corpus of documents that may or may not contain the answer.

The Kernel runs in a process on your infrastructure. It holds the ontology in shared memory, pre-connected and resolved, with sub-millisecond query latency. It ingests continuously through a background daemon. It never deletes a record. It enforces clearance before any read or write operation.

The companies that establish their company ontology now will have a compounding advantage: every decision recorded, every exception documented, every workflow captured in structured form becomes part of an asset that survives personnel changes, supports new agents, and deepens with every month the system runs. The moat is the data, not the software.

The category leader will be whoever establishes the standard first. We intend to be that company.

If you're building agentic infrastructure and want to understand how a company ontology fits in, read the docs. If you're deploying agents inside a company and hitting the context wall, request access.