The five walls of a context layer. Part 1: knowledge graph and ontology

Building your own enterprise context layer? Here are the five walls you'll hit.

If you're giving AI agents access to your company's knowledge, you're building a context layer: the layer between your source systems and your agents. When you build it yourself, these are the five walls:

1. Knowledge graph and ontology — the entities and how they relate
2. Semantic layer — your business vocabulary
3. Understanding intent — narrowing the search space
4. Permissions — real ACLs for your agents
5. Breathing data at scale — fresh, and up, under live load

This is a series, one wall per post. Part 1 is the first and the least visible: the map of your company that nobody ever drew.

#First, three words, in plain English

Before the hard part, three terms. They stack, from simplest to most powerful.

1. Taxonomy, a filing cabinet. A hierarchy: a bug is a kind of Ticket, a Ticket is a kind of Work Item. Good for classifying and tagging. It tells you what something is filed under, and nothing else.

[IMAGE: Taxonomy hierarchy diagram — a bug is a kind of Ticket; a Ticket is a kind of Work Item]

2. Ontology, the rules of your world. It adds the relationships a filing cabinet can't hold: a Service is owned by a Team, and runs in an Environment. It's the blueprint: the types of things you have, and how they relate.

[IMAGE: Ontology diagram — a Service is owned by a Team and runs in an Environment]

3. Knowledge graph, the building. Take that blueprint, fill it with your real data (billing-svc, the Payments team, prod-eu, a few million of them), and you have a graph you can actually query.

The one line to remember: the ontology is the blueprint; the knowledge graph is the building you put on it. You can hold a blueprint with nothing built yet. But a knowledge graph always contains its ontology, because the rules are baked into the structure.

#The same service, five names

Here is why entity resolution is the hard part: the same real-world thing wears a different name in every system.

billing-svc in Git, "Billing Service" in the wiki, BILL in Jira, "the billing thing" in Slack. Four names, one service, and it belongs to a product, is owned by a team this quarter, and runs in a specific environment. No single system knows all of that. The entity only exists across all of them, and the edges between it and everything else live nowhere at all until someone builds the map.

On real data, the map is large. One plain question — "do we have a guide for creating a GitHub app?" — fans out into 107 connected sources across documents, people, tickets, pull requests and messages. That is the graph answering it actually requires.

On one enterprise customer's graph today, that is about 2.6 million nodes and 7 million edges, and roughly 139,000 of them are cross-reference links we pull out of messages and docs. A Slack message that links a commit becomes an edge to that exact commit. That is the heavy lifting nobody wants to maintain by hand.

And it is not free to get wrong. When the map is bad, you pay for it in tokens and wrong answers.

The experiment. We ran the same set of questions two ways: once through the context layer, once through a do-it-yourself agent over the same sources. We measured cost per correct answer, total model spend divided by the questions actually answered right, not just answered. The do-it-yourself side came out about 5x more expensive per correct answer, because it burned tokens wandering for answers a good map would have handed it directly. Treat it as directional: one run, a small question set (n=10), on our own data.

#Two kinds of entities: the ones we connect, and the ones only you can define

Not all entities are equal. Some come for free; some only you can define.

Built-in entities are the easy half. The connections between them are already implied by how the tools work: a commit belongs to a PR, a PR belongs to a repo, a person authored both. GitHub, Jira and Confluence did the linking. We read it and infer the rest statistically.

Custom entities are the hard half, and they can't be inferred. Take a Feature. One customer's definition:

1. An item or epic in the tracker
2. Not tagged as a bugfix
3. Linked to a PR that touched a feature flag
4. And it still has to look like a feature when an LLM reads it

No single tool in their stack could answer that. Not the docs, not the tracker, not the code. The definition only exists across all three, and only they could write it.

So the person who owns the context infrastructure declares it: the entity, its sources, its connections to other entities, its scope, its permissions, and the judge for what counts. They define it because they own the business logic. We resolve it across the whole corpus and wire it into the graph.

#An LLM wiki works until the company shows up

The most common plan for building a context layer without us is an LLM wiki: a curated, LLM-maintained wiki you feed the model as context. Andrej Karpathy described the pattern well, an LLM incrementally building and maintaining a markdown wiki so knowledge compounds instead of being re-retrieved every query.

And at small scale, it genuinely works. Karpathy's own framing is the tell. He calls it a pattern for building personal knowledge bases using LLMs.

Personal. Maybe a team inside a company. Not the company. He aims it at dozens to hundreds of sources: personal notes, one research topic, a team wiki. At that scale it's a great idea.

Then the company shows up, and it collapses. Three reasons, structure first:

1. A wiki is prose; a knowledge graph is structure. You cannot traverse a paragraph. "Who owns billing now, and where does it run?" is a graph hop across resolved entities, not a lookup in a document. Even Karpathy's design needs a separate schema file, which is an admission that prose needs a structure it doesn't have.
2. It's stale by lunchtime. In an org merging fifty PRs a day, the bookkeeping never catches up. The LLM doesn't get bored, but the wiki is still wrong between updates, all day.
3. Not everything is prose. Permissions, live edges, the millions of connections between things. None of that compresses into a page.

This isn't theoretical. Several of our customers tried exactly this first. It didn't scale, and maintaining it got expensive, which is why they came to us.

#Run this on your own org

You don't need our product to find your walls. Ask your current setup three questions:

1. Is this PR a feature or a bugfix? Can it answer without a human?
2. Who owns billing now, and where does it run? Does it know billing-svc, BILL and "the billing thing" are one service?
3. Ask Finance and Growth for "activation rate". Does it give each the definition they actually mean?

Whichever ones your setup can't answer are the walls you haven't cleared yet.

#What we build

This map, the ontology and the knowledge graph on top of it, is the hard, unglamorous infrastructure nobody wants to own. So we do the heavy lifting: we connect everything into one context layer, resolve the entities, and maintain it as your company changes.

And we do it whitebox, not blackbox. You build your own context layer on top of us, in your language, for your business. The context was always there. It was just hidden.

The next four walls are where it gets harder:

• Wall 2, semantic layer: teaching the agent your words. That shipped means merged, that billing means billing-svc, that a KPI means what your team means by it.
• Wall 3, understanding intent: narrowing millions of candidates to the handful that could answer this question, before you retrieve.
• Wall 4, permissions: real, per-user ACLs that survive down to a fragment of text.
• Wall 5, breathing data at scale: keeping all of it fresh and fast under live load.

One per post. Next up: the semantic layer.

#Hitting one of these?

If you ran the three questions above and your setup couldn't answer them, that's the wall you're on. We've cleared all five, on real enterprise graphs, and we're happy to talk through where yours is stuck, whether or not you end up building it with us.

Let's talk through your setup. Book a demo.