PERSPECTIVES — 01 · KNOWLEDGE GRAPHS
Knowledge Graphs: How Enterprises Unlock What They Already Know
Every company has more knowledge than it can use. The problem was never a lack of information, it's that almost none of it is connected.
By Chris Byler and Keith Jacobs, with Cason Swindle · geniant
“The knowledge sharing is just an unbelievable handbrake to literally everything an organization does.”
Chris Byler
The Problem
Brands have never had more AI tools. So why does so much knowledge still live nowhere?
Human to human conversation moves at roughly ten bits a second, a useful shorthand for how slow information travels from person to person. In practice, that's often the limit of teams scattered across an organization, some detached from the group actually building the product, even though what those teams do affects everything downstream. When one team changes something and it breaks another team's work, the only way to sort it out is a string of meetings: find the other team, schedule time, spend the first two figuring out what they're even doing, and finally get somewhere on the third. All of it happening at ten bits a second.
This is what poor knowledge sharing costs an organization in practice. The knowledge is almost always already there, sitting somewhere. What's missing is a way to find it, connect it, and rely on it once it actually surfaces.
The Concept
Knowledge graphs: from a single prompt to a full graph
Stripping away the jargon, a knowledge graph is a simple idea: facts and ideas as nodes, and the relationships between them as edges. The concept evolved through a series of increasingly complex, lower-dimensional forms: early LLM use was effectively a single-node graph, one prompt, one response. Chat threads expanded this into a linear graph, with each bubble a node dependent on the last. Agents and sub-agents structured these lines into trees: hierarchical graphs that, while more sophisticated, remain limited in their connectivity.
Follow that evolution from single prompt to linear thread to hierarchical tree, and you eventually break through to a full, multidimensional knowledge graph. This is the only structure flexible and high-dimensional enough to map everything an organization knows. Almost any kind of organizational knowledge (a codebase, a client history, an org chart, or a decision nobody wrote down) can be represented within this interconnected web.
That structure doesn't organize itself. The term borrowed here is ontology, originally a philosophy term for the study of being: the categories that determine what exists in a domain and how those categories relate to each other. Applied to a knowledge graph, an ontology is a shared, explicit definition of what the important concepts are and how they connect. It's the scaffolding that decides where new nodes are even allowed to attach, in practice, the prompt you give an AI to organize a graph's initial connections.
The Alignment Problem
The real gap between what you want and what AI delivers
Why this matters at this exact moment comes down to a gap between what a human wants AI to produce and what the AI can produce, limited by a lack of knowledge. It's a form of the alignment problem, a term borrowed from AI safety research. In that context, it means something much bigger: making sure a powerful AI system stays aligned with human intentions instead of causing harm at scale. Brought down to something everyday, it just means getting the AI to do what you actually want on the first try, not the tenth.
In an enterprise setting, this alignment gap is often a knowledge gap. Most of what an AI needs to stay aligned with your specific intent is unstructured, living in the connective tissue of documents, expert judgment, and historical context rather than tidy database rows. A knowledge graph solves for this by creating a flexible, multidimensional web of information that acts as the necessary ground truth. By mapping the documents that explain a dataset or the expert assumptions behind a number, the graph ensures the AI delivers exactly what you want on the first try, rather than producing something technically accurate but contextually misaligned.
The Payoff
What changes when experts share a graph
Take a simple example. An engineer writing rules to monitor code brings in a physics expert to check the underlying logic. The expert spots a flawed assumption, makes a tweak, and that correction is made part of the graph. The expertise links itself in.
That's the promise: a new hire, a veteran, and an AI agent can all draw on the same understood knowledge instead of rediscovering it independently, one slow conversation at a time.
The Approach
Why you don't build a knowledge graph all at once
The obvious next question is how to actually build one, and the answer cuts against the instinct to treat it as a single big project.
“We would not build a knowledge graph for knowledge graph's sake. We'll expand it project after project, and like a flywheel, it will ultimately grow bigger and bigger, until it's the size that it could truly affect how your company operates.”
Keith Jacobs
From a practical standpoint, it's rarely a standalone project. More often it rides along as an add-on to something already underway. Grouping it with a real need and a real application makes sure it's never just knowledge for knowledge's sake, and building it inside real engagements builds in its own quality control: a graph nobody uses never gets tested, corrected, or improved.
Before any of that starts, the ontology has to come first, agreed on before a single node gets added. Skip that step and you don't have a knowledge graph, you have an unsorted pile of nodes. The specifics of how teams land on that structure are still being worked out, but the sequence holds: structure before scale.
The Maintenance Problem
From thankless to enjoyable: solving the maintenance problem
Every team that's tried this before has a company wiki graveyard to point to. The reasons those efforts die are blunt: it's a completely thankless job to maintain, there's no reward for updating it, and staleness makes it useless the moment a decision gets made outside the system.
What changes with AI is who does the connecting. Deciding that one note relates to another document, or that a decision made in one meeting affects a project three teams over, used to be manual work, and manual work is exactly what nobody had time to keep doing. AI can now surface those connections, which turns the maintainer's job into mostly reviewing and approving what the system found, more shepherd than scribe.
Open Questions
What we're still working out: privacy and ownership
People can't operate effectively without some measure of privacy. They need room to think, function, and create. One early answer is summarization, treating the compressed version of a piece of knowledge as the privacy layer itself, letting information keep flowing without exposing everything underneath it raw. Striking the right balance is key, and clear answers haven't emerged yet.
An additional concern is who owns the knowledge graph. If AI companies control these graphs and keep the raw knowledge siloed project after project, they could permanently restrict the future effectiveness of any system built outside their ecosystem.
“Imagine if the AI companies controlled the knowledge graphs. Every time they did a project, they kept the raw knowledge to themselves. Ten projects down the road, they could never use AI as effectively without them as they could with them.”
Keith Jacobs
Where This Leads
The knowledge your organization needs almost certainly already exists
There's something bigger on the horizon than the knowledge graph itself: what happens once an enterprise's graph is good enough to generate what it needs on demand, instead of commissioning a new custom application every time.
The knowledge your organization needs almost certainly already exists. It's not hidden because it doesn't exist, it's hidden because nothing connects it. Closing that gap, one real project at a time, is exactly the work geniant does: finding where the highest-value knowledge already lives in your business, and building the structure that lets your teams, and your AI, finally use it.