What is enterprise context? Building the map, not hoarding the territory

There is a lot of talk right now about context, semantics, and AI agents. Every roadmap slide has a box labeled “context layer.” Every vendor claims their product “grounds” your LLM. But almost nobody is asking the harder question underneath all of it: what should actually be in that context, for enterprise AI specifically?

That question matters more than it sounds. Get it wrong and you end up with agents that are fluent but ungrounded: confident about things they should not be confident about, and blind to the parts of the business that actually determine whether an action is safe, correct, or even legal to take.

The point-solution trap

If you go looking for an answer today, most of what you will find are point solutions, tools built to solve one specific problem for one specific use case. A migration accelerator. A contract review assistant. A divestiture-readiness checklist. Each of these works, narrowly. Each of them also quietly encodes its own private model of “what matters” in the enterprise, rebuilt from scratch, specific to that one job.

That is fine if you only ever need to do that one job. It falls apart the moment you want a second use case, or a third, or an agent that can reason across all of them. You end up maintaining N different half-models of the same enterprise, none of which talk to each other, all of which drift the moment the underlying systems change.

So here is the real question hiding underneath all of this: not what is the use case, but is there a generalized model for enterprise context at all, one that does not need to be rebuilt every time the business problem changes?

It is not about “good data.” It is about scope.

Everyone already agrees that AI is only as good as its data. That is not the interesting part anymore. It is table stakes. The interesting question is scope and range: what data, at what breadth, captured at what level of abstraction, so that it is useful across use cases instead of just one.

That is the argument for treating your enterprise knowledge graph as more than a data model. Its greatest value is not as a database. It is an integration fabric and a grounding structure for AI agents. Built correctly, it becomes the generalized model of the enterprise that point solutions never bother to build, because they do not need to for their one job.

The meta-model problem

So what actually belongs in that graph? Here it is worth taking a page from how Databricks has framed the analogous problem in the data platform world: the real game is not played at the data level, it is played at the meta-model level. The question is not “what data do I have,” it is “what is the model of the enterprise itself, and can I even build one?”

That is a genuinely hard question, and it is worth naming why. Metamodels and schemas are traditionally treated as static: you design them once, you extend them carefully, you version them like software. Enterprises are the opposite of static. They reorganize. They acquire and divest. They migrate systems. They accumulate enormous, messy quantities of operational data that never sits still. A metamodel built for how the business looked eighteen months ago is already wrong.

What is needed instead is a generative context model, one that is derived continuously from how the enterprise’s systems are actually configured and used, not from a static design document that goes stale the day it is finished.

What belongs in the model

A generalized context model needs to capture the enterprise across several dimensions simultaneously, not just one:

• Org structure. Who the enterprise actually is, structurally.
• Business models. How it creates and captures value.
• Business processes. How work actually flows, not how the process diagram says it should.
• Business objects. The entities the business reasons about: customers, contracts, orders, assets.
• Technical objects and data models. How those business concepts are actually implemented in the underlying systems.
• Essential business metrics. The aggregated numbers leadership actually watches.
• Human knowledge and unstructured data. This is the dimension most models skip entirely. A huge amount of what makes an enterprise function was never entered into any system. It lives in people’s heads, in email threads, in meeting notes, in the tribal knowledge of whoever has been there fifteen years. A context model that only ingests structured system data is missing a real dimension of the business, not a minor one.

And this is not just true of the schema at the bottom of the stack. Every one of those dimensions (org structure, processes, objects, metrics, human knowledge, all of it) has to be derived from how the system is actually configured and used, not from how it was originally designed to be used. Org charts drift from how teams actually report. Process diagrams drift from how work actually gets done. If only the semantic layer stays current while everything above it is frozen at design time, you have not solved the staleness problem, you have just moved it up one level. The whole stack has to be observed, not assumed.

Compressed by design

One design choice matters more than it might first appear: the model is an abstraction of your enterprise, not a mirror of it. It captures object types, relationships, schema, lineage and ownership at a level that stays small enough to reason over and current enough to trust.

That is what makes it a map. When an agent needs the detail behind an entity, the graph knows where that detail lives and routes the agent, through an MCP server, to the source system to fetch it live. The graph tells you where the truth lives and how it is shaped, and hands off to the system of record for the rest.

You are building the map, not hoarding the territory.

That distinction is the whole point. A model pitched at the right level of abstraction is one you can keep current, reason across, and govern. One pitched too low stops being a model of the enterprise and starts being a second version of it.

Built for agents, not just queries

Finally, none of this matters if the model is not actually usable by the agents it is meant to ground. That is why it has to be graph RAG enabled from the start, built so that agents can traverse relationships and retrieve relevant subgraphs efficiently, not just run lookups against it the way you would query a conventional database. A generalized context model that agents cannot efficiently reason over is just a very expensive diagram.

Where this is going

This is the architecture we have been building at Graphmantix with e360°, proven first in the SAP® ecosystem, arguably one of the messiest and most metadata-rich enterprise environments there is, which makes it a reasonable stress test for whether a generalized model actually holds up. The underlying argument, though, is not SAP-specific. It is a claim about what enterprise context has to look like if you want AI agents that generalize across use cases instead of being rebuilt for each new one: generative rather than static, compressed rather than duplicated, and built from day one to be consumed by agents rather than bolted on for them afterward.

That is the meta-model problem everyone is dancing around. Worth solving properly.