A category question keeps coming up in conversations. We already buy a knowledge platform. We already do master data management. We already do IT asset management. Doesn’t that cover what you are talking about? It is a good question, and the honest answer takes more than a sentence.
Each of those categories solves a real problem. None of them solves the problem we are solving. They are adjacent — sometimes complementary — and it is worth being precise about how.
The browser-augmented knowledge layer
A modern knowledge platform usually shows up as a browser extension and a SaaS layer. It rides along inside the apps you already use, augments the screens you already look at, and uses APIs underneath to surface the right snippet at the right moment. Cards in the corner of your tab. Search across systems. The right policy or contract or playbook, in front of the right person, at the right time.
That is genuinely useful. It is also bounded. The unit it operates on is the human in a browser tab. The architecture it produces is “augment what people are already doing, where they are already doing it.” That works as long as the human is the bottleneck. The moment the work shifts to agents and copilots that do not run in a browser tab, the model breaks.
We are solving a different problem. The unit we operate on is the capability — a composed, governed, declared interface that an agent calls. Not a card in the corner of a screen. A contract on the wire that an agent can call from anywhere, with telemetry, with scope, with reuse across teams. Knowledge layers and capability layers are not the same thing, and a company will probably need both.
Master data management
MDM is about the data. The whole point is to clean, reconcile, and govern the records — the customer that exists in five systems with three subtly different spellings, the product SKU that drifts between the catalog and the warehouse, the account that the finance side and the support side disagree about. MDM produces one trusted view of a record class.
That is not what we are. We are not a record-cleaning layer. The data quality work still has to happen, and it does not get easier just because there is an agent in the loop. If anything, it gets less forgiving — a model is happy to confidently produce a wrong answer based on a dirty record, and “the agent told me” is a terrible audit trail.
What we are is the pipes between cleaned data and the agents that need to call it. We assume MDM is happening somewhere, or that it should be. We provide the API-and-capability layer that gives a governed agent access to the records — clean ones, ideally — without burning a custom integration every time.
If MDM is the work of making the records true, capabilities are the work of making the records callable, safely, on behalf of an agent. They are two different jobs. Doing one does not finish the other.
IT asset management
IT asset management is the closest neighbor in the conversation, because it is about what you have. Accounts, services, licenses, the bills, the renewals, the inventory of contracts. ITAM is the system of record for the procurement-and-finance view of the SaaS sprawl.
The gap between ITAM and what AI governance actually needs is bigger than most people realize. ITAM tells you we have an account with this vendor, and the bill is this much. It does not tell you what the menu is — what operations are exposed by that vendor’s API. It does not tell you what is in active use — across your employees, your agents, and your copilots, today, this week, this quarter. It does not tell you what is reachable — by which roles, with which scopes, through which governed paths.
The accounts and bills are static. The actual current state of usage is a live thing, and it shifts week over week as teams turn on new MCP servers, deprecate old integrations, and quietly hand agents access to systems nobody put on the inventory. ITAM was not built to track that. It was built to track invoices.
We are the layer where the live state of usage actually lives — what is being called, by what, on behalf of whom, against which contract, with which result. ITAM and capability governance both want to see your SaaS landscape clearly. They see it in different time signatures, and at different layers.
The pipes and the toll booths
I have been using a phrase for this a lot lately. Pipes and toll booths.
Pipes are the integrations. The connections between the systems your business runs on and the agents that want to act on them. Pipes are old. We have had pipes for a long time. The interesting work has shifted from “can we build the pipe” to “can the pipe be reviewed, governed, scoped, observed, and reused.”
Toll booths are the governance points along the pipe. Authentication. Authorization. Observability. Telemetry. The places where you can stop a call, log a call, scope a call, charge for a call, or audit a call after the fact. Toll booths are how the legacy SOAP service, the database connection, the EDI handoff, and the modern REST API all show up to your agents through the same governed surface — instead of each one being its own bespoke integration with its own bespoke risk profile.
Knowledge layers do not build pipes and toll booths. MDM does not build pipes and toll booths. ITAM tracks the bill for the pipes, but does not build them.
That is what we do. The pipes and the toll booths — at the scale a real enterprise needs them, on open standards, in open source, with the governance baked in instead of bolted on.
Where this leaves the category question
The category question, then, has a cleaner answer than it first looked like.
A company at full maturity will probably have all four — a knowledge layer for the human-in-the-browser augmentation, an MDM practice for record quality, an ITAM system for the procurement and finance view, and a capability layer for the governed agent integration. Each of them owns a piece of the problem. None of them substitutes for another.
The mistake is assuming that, because you already bought one of these categories, the AI integration problem is covered. It is not. The AI integration problem is the pipes-and-toll-booths problem, and it lives in a layer most enterprises have not staffed for yet.
That is the layer we are here to build.
