How do we tell whether we need one?

Look at the questions that go unanswered. If the frustrating ones are of the form which of these relate to those, spanning several systems, then no amount of better retrieval will help, because the answer is not written down anywhere. If they are about finding the right document, this is a large investment in the wrong thing.

Why is the modelling so contentious?

Because it forces one answer to questions departments have been answering differently for years. Sales and finance may not agree on what a customer is, and a graph cannot hold both definitions, so building one surfaces disagreements that were previously survivable. That is genuinely useful and it is also why these projects stall.

What goes wrong most often?

The relationships go stale and nobody notices, which is worse than a stale document. A wrong connection corrupts every question that traverses it, so one departed customer still attached to live contracts produces several confidently wrong answers, each about something different. Maintenance here is not optional in the way it can be elsewhere.

Glossary

Knowledge graph

A knowledge graph records how things relate to one another rather than what documents say, which lets a system answer a question whose parts live in several places at once.

In plain terms

A map of things and how they connect: this customer holds that contract, which is owned by this team, and covers those products. Search finds documents that mention a thing. This answers questions where the answer is not written down anywhere, because it lives in the connections between several records rather than in any one of them.

Why it matters

Because a whole class of ordinary business question has no document containing the answer. Which contracts renew next quarter for customers of a team that lost its account manager is a perfectly reasonable thing to ask and there is no page that says it, so retrieval will return things that mention the words and never the answer.

How it works

Things and relationships are recorded explicitly, which is the difference and the cost. Somebody has to decide that customers, contracts, products and teams are the things worth modelling, and that a customer holds a contract while a team owns a customer, and those decisions are the actual work rather than any of the technology built on top of them.

It answers by traversing rather than by matching, so questions spanning several hops become tractable. Where search asks which documents look like this question, a graph follows connections from one thing to the next, which is why it handles the joined-up question and why it is unhelpful for finding a paragraph about a topic.

Keeping it current is the standing obligation, and it is heavier than keeping documents current. A document that goes stale is one wrong answer; a relationship that goes stale corrupts every traversal that passes through it, so a contract wrongly still attached to a departed customer misleads about several questions rather than one.

It is worth building where the relationships are stable and the questions recur. Organisations whose entities genuinely persist, and who ask the same shape of joined-up question repeatedly, get a great deal from it. Where the model would need constant renegotiation the effort exceeds the return, and that judgement is the whole decision.

Two questions that sound similar

The reason this distinction is worth drawing carefully is that the right-hand failure is not experienced as a failure. Somebody asks a joined-up question, the search returns several relevant-looking documents about renewals and about that team, and the person reads them and assembles an answer themselves, or gives up quietly and asks a colleague. Nothing reports that the system was structurally incapable of the request. That is why organisations sometimes spend a year improving retrieval and find that the questions people actually wanted answered are exactly as unanswered as before. The diagnostic is simple and worth doing before any large investment: collect the questions people gave up on, and sort them by whether a document containing the answer could exist. Everything in the first pile is a retrieval problem worth working on. Everything in the second is this, and no amount of better search will touch it.

Seen in the wild

A curated knowledge layer whose agents retrieve and act across connected tools, which requires knowing how things in those tools relate to one another.
Guru
A workspace where pages and databases carry structured properties and relations, so connections between records are recorded rather than inferred.
Notion AI
A work-management platform whose AI answers from live task states, documents and schedules, which are related records rather than free text.
ClickUp (Brain)

Common misconceptions

People assume

It is a better search.

In fact

It answers a different question. Search finds material about a subject and this follows connections between things, so a graph is unhelpful for locating a paragraph and search is incapable of answering which contracts belong to customers of a particular team. Organisations that need both end up with both.

People assume

The technology is the hard part.

In fact

Deciding what the things are is the hard part, and it is a business argument rather than an engineering one. Whether a customer is an organisation or a contracting entity, and whether a team owns a customer or an account, are questions different departments answer differently, and the graph forces one answer.

Telling them apart

Knowledge graph vs Semantic search

Knowledge graph

Follows connections between things.

Semantic search

Finds passages that mean what you asked.

One answers a question spanning several records and the other answers a question about a subject, which is why neither substitutes for the other.

Questions

How do we tell whether we need one?: Look at the questions that go unanswered. If the frustrating ones are of the form which of these relate to those, spanning several systems, then no amount of better retrieval will help, because the answer is not written down anywhere. If they are about finding the right document, this is a large investment in the wrong thing.
Why is the modelling so contentious?: Because it forces one answer to questions departments have been answering differently for years. Sales and finance may not agree on what a customer is, and a graph cannot hold both definitions, so building one surfaces disagreements that were previously survivable. That is genuinely useful and it is also why these projects stall.
What goes wrong most often?: The relationships go stale and nobody notices, which is worse than a stale document. A wrong connection corrupts every question that traverses it, so one departed customer still attached to live contracts produces several confidently wrong answers, each about something different. Maintenance here is not optional in the way it can be elsewhere.

Key takeaways

It answers questions whose answer is in the connections, not in any document.
Deciding what the things are is the work, and it is a business argument.
A stale relationship corrupts every question that passes through it.
It is worth building where entities persist and the questions recur.

Tools that use this

Guru
Agents retrieving and acting across connected tools.
Notion AI
Structured properties and relations recorded rather than inferred.
ClickUp (Brain)
Answers from live task states and schedules, which are related records.