Knowledge graphs for business AI: when you actually need one

A managing director showed me a chatbot his team had bought and pointed at their SharePoint. It worked, in the sense that it answered questions. Then he asked it the question he actually cared about: which of our customers are exposed if this supplier stops delivering? It returned three PDFs that mentioned the supplier’s name. He looked at me and said the thing everyone says: our AI can’t answer that.

It couldn’t, and swapping in a smarter model would not have helped. The answer to his question was not written down anywhere. It existed only in the links between records — supplier to product, product to order, order to customer — and those links were spread across three systems that had never been introduced to each other. He didn’t have a model problem. He had a data-shape problem, and it has a name: he needed his business modelled as a graph.

Flat data versus connected data, without the jargon

Your business software stores things in lists. A customer list. An order list. A supplier list. A folder of contracts. Each list is good at one question: tell me about this one record.

A graph stores the same things, but it also stores the links as real data you can follow. Not “order #4471 has a supplier_id column” buried in a table an AI never sees, but an explicit statement: this customer placed that order, which contained this product, which came from that supplier, who is named in this contract, which was signed by this person, who left the company in March.

That chain is the whole point. Once it exists, an AI can walk it. Ask about the supplier and it can step outward — supplier, products, orders, customers, contracts, value at risk — and come back with a list of eleven customers and a number. Not documents that mention a word. An answer.

What “our AI can’t answer that” usually means

In practice it is almost always one of four things, and only the last one is about the model.

Three of the four are structural. That is the part most buyers get wrong: they go shopping for a better AI when what they need is for their data to be joined up before the AI ever sees it. I have written separately about the related mistake — assuming the answer is a model trained on your data. It usually isn’t that either.

The questions that only work on a graph

Abstract explanations of graphs are useless, so here are real questions from real conversations. Every one of them is unanswerable by search over documents and trivial once the relationships are stored.

• “If this supplier fails, who do I have to phone?” Supplier → products → open orders → customers → account manager. Five hops, one answer, with the revenue attached.
• “Which contracts contain the clause we lost the argument over last year?” Clause → contracts → counterparties → renewal dates. Search finds similar wording; the graph finds the exposure and when it comes up.
• “Who at our end has ever spoken to anyone at their end?” People → emails, meetings, tickets, deals → people. The most common reason a deal is lost twice by two different reps.
• “Which customers bought A but never B, and who sold to them?” Ordinary in a graph. In a documents index it is not a question at all.
• “Show me everything about this project.” Quote, contract, invoices, tickets, the three people involved, the two suppliers, the disputed delivery. One node, everything hanging off it.

Notice the pattern. None of these are hard questions. They are questions whose answer is spread thinly across five places, which is exactly the work a human currently does by opening five tabs and remembering things. That is the job you are buying back.

You already own the data. Nobody has joined it up

This is the part that surprises people, and it is why these projects are shorter than they sound. Almost nothing needs to be created. A 60-person company typically already has:

That third box is where the time goes. Not the graph database — those are commodity now. The value is in the modelling: agreeing what counts as a customer, which system wins when two disagree, and which relationships matter enough to keep current.

Why this stopped being an enterprise-only project

Graph projects had a reputation, and it was earned. Five years ago this meant a specialist consultancy, a six-month engagement and a six-figure invoice, because the work was enormous and repetitive: a connector for every system, a schema, an identity-matching layer, a query layer, an ingestion pipeline that keeps it fresh, and a test suite proving none of it silently breaks when a field name changes.

That work still has to happen. It is just no longer the thing you are paying for by the month. I build these with coding agents — Claude Code and OpenAI Codex — doing the implementation: reading the API docs for your CRM and writing the connector, generating the schema from a model we agreed on a call, writing the queries, writing the tests, and fixing them when they fail. What used to be weeks of a developer typing is now hours of a developer directing.

What that changes for you, in plain terms:

• The estimate collapses. The connector work — historically the bulk of the invoice, and the least interesting part of it — is no longer the bulk of the invoice.
• You see it early. A working slice over two of your systems in the first weeks, not a design document in month three. You can tell whether it answers your real questions before most of the money is spent.
• Changing your mind is cheap. Remodelling a relationship used to be a change request. Now it is an afternoon, which means the model can be argued about honestly instead of frozen early to protect the schedule.
• It stays maintainable. When your accounts package changes an endpoint next year, fixing the connector is a small job, not a re-engagement.

Which tool does which part is my problem, not yours, and I would be suspicious of any vendor who wants to spend your discovery call on it. What matters to you is the consequence: a category of project that was priced for companies with 5,000 staff is now priced for companies with 50.

What it costs and how long it takes

A graph-backed system is not a different species of project. It is a custom AI web app for your business where the retrieval layer happens to follow relationships instead of matching text, so it prices the same way everything else does: from $4,000, driven by how many systems it touches, how messy the identities are, and where it is hosted. The cost estimator will give you a range for your own case in three questions.

The shape of the work, in the order it happens:

1. Write down the five questions. The ones you actually want answered, in the words you would use to a colleague. This takes an hour and it decides the entire scope. Everything the graph does not need to answer, it should not model.
2. Model the entities and links. A whiteboard exercise with the people who know the business. Which things exist, how they connect, which system is the source of truth for each.
3. Connect two systems and prove it. Deliberately not all of them. Two systems, real data, and can it answer question one? If not, better to know now.
4. Extend, resolve identities, keep it fresh. Remaining systems, the deduplication rules, and the sync so it does not go stale — a graph nobody updates is worse than no graph.
5. Put an interface on it. The web app, permissions per user, and the visible trail from answer back to source records.

In weeks, not quarters — and the same phased logic I use on every build, set out in the timeline breakdown. Step 3 is the one to insist on. Any proposal that puts the first working answer after month two is asking you to buy on faith.

When you do not need this

Most companies who ask me about knowledge graphs should not buy one, and saying so on the first call has never once cost me a project worth having. Skip it if:

• Your important questions live in one system. If everything that matters is in the CRM, the answer is a better report or a straightforward AI layer over that one system. Two systems and a graph is over-engineering with extra steps.
• Your questions are about text, not connections. “What does our returns policy say?” is a retrieval question. Ordinary document search answers it well and costs a fraction.
• Nobody owns the data. If four departments each keep their own customer spreadsheet and nobody has authority to decide whose is right, a graph will surface that argument, not settle it. Fix the ownership first — genuinely, do that first.
• You are under about 20 people with one shared system. The relationships are still in everyone’s head, and heads are faster. Come back when the person who knows everything goes on holiday and the business notices.
• You want it because it sounds advanced. A graph you cannot name five questions for is a maintenance liability with a fashionable name.

The honest split I see: roughly one in five companies who raise this actually benefit. The other four get more from a simpler build done well, which is the same conclusion as custom versus off-the-shelf arrives at by a different route.

The test you can run this week

Free, takes an afternoon, and it settles the question better than any vendor call.

Write down the last ten questions someone in your business asked that took more than fifteen minutes to answer. Real ones, from your inbox and your meetings. Then mark each one:

• A — the answer was in one system, someone just had to go and look.
• B — the answer needed two or more systems joined by hand.
• C — the answer was only in someone’s head.

Mostly A: you need better access to what you already have, not a graph. Mostly B: that is exactly the shape a graph is for, and the fifteen minutes each is the number you are buying back. Mostly C: you have a knowledge problem, not a data problem, and the first job is writing things down — though C tends to become B once it is.

Then count how many people asked those questions, how often, and multiply. That figure is the whole business case, and it is usually either obviously worth it or obviously not. I have never needed a spreadsheet more complicated than that one.

Related reading

• Custom AI model development: do you really need one? — the other thing “our AI can’t answer that” gets blamed on
• Connecting an AI assistant to your business tools — the integration layer underneath all of this
• How to spec a custom AI system — turning your five questions into a one-page brief
• How custom AI development actually works — the six-stage methodology