What a team knowledge graph actually is

A team knowledge graph is a typed map of how your team actually works: decisions, threads, people, and runbooks stored as nodes, connected by edges that name the relationship between them, with every node carrying provenance back to the Slack message, ticket, or doc it came from. It is not a wiki and it is not search. A wiki stores pages a person wrote once. Search points you at a page to read. A graph stores the relationships - this decision reversed that one, this person is the only one who has touched that runbook - and it can be traversed, queried, and read by an AI agent that then does something with what it finds.

The difference is easiest to feel when it is missing.

A backend engineer named Priya picks up a ticket to add a region to the billing service. She greps the codebase, finds a config flag from eight months ago, and flips it. The deploy goes out clean. Three days later support is on fire: a cohort of EU customers got double-charged, because that flag was disabled on purpose after an incident, and the reason lived in a Slack thread that scrolled out of view in October. The wiki had a page on the billing service. It did not have the one sentence that mattered: we turned this off, here is why, do not turn it back on. Priya did not lack documentation. She lacked the edge connecting the flag to the decision that killed it.

A graph stores relationships, not pages

A knowledge graph, in the plain technical sense, is a set of nodes (entities) and edges (relationships) where both have types. A node represents a thing; an edge represents a named, directional connection between two things. That typing is what makes it more than a pile of documents. You are not storing text and hoping a search query surfaces the right paragraph. You are storing facts you can walk.

In a team knowledge graph the node types are the units of work a team actually argues about:

• Decisions - a call the team made, with the before-to-after change, the reason, and the date.
• Threads - one piece of work, stitched from the scattered signal across chat, tickets, PRs, and docs.
• People - who knows what, and where the team is one resignation away from losing something load-bearing.
• Runbooks - a procedure the team has run several times, captured as a playbook that sharpens each time it runs.

The edges are where the value lives. A decision supersedes an earlier decision. A thread is blocked on a ticket. A person owns a runbook. A runbook was triggered by an incident. None of that fits in a page. A page is a leaf; the graph is the tree, and most of what you need to know on a bad day is in the branches.

Provenance is the part that makes it trustworthy

Every node points back to where it came from. The decision node about the billing flag links to the exact Slack thread and the incident ticket that produced it. This is the one property that separates a knowledge graph you can rely on from a generated summary you have to second-guess.

It mirrors a pattern engineers already trust. An architecture decision record captures one decision, its context, and its consequences, so that someone reading the system months later understands why it is built the way it is. The discipline is sound. The problem is that ADRs are written by hand, which means they get written for the decisions someone remembered to document and skipped for the ones made at 5pm in a thread. A graph that compiles itself from the team's real traffic keeps the rationale without depending on anyone's diligence. And because each node cites its source, "Ody says so" is never the answer. "This thread on October 14th says so" is.

When a decision changes, you do not overwrite the old one. You add a node and an edge: the new call supersedes the prior one, with the reason and the date. The history stays walkable. That is what we mean by decisions that don't rot - the record evolves as a diff instead of getting silently replaced by whoever edited the wiki last.

How it differs from a wiki and from search

These three things get lumped together because they all claim to hold "team knowledge." They do different jobs.

Enterprise search is genuinely useful for finding a document in a 5,000-person company. Tools like Glean do that well, at roughly fifty dollars a seat with a hundred-seat minimum, priced and built for a scale most teams of twenty do not have. Notion AI sits inside the wiki and answers questions over the pages you wrote, bundled at around ten dollars a seat. Both end at the same place: a person, reading. We wrote a longer comparison in Glean vs Notion AI vs Ody if you want the detail.

A graph does not end at reading. It ends at an answer you, or an agent, can take an action on.

Why "callable by both people and agents" is the whole point

A wiki is callable by humans only. You open it, you read, you close the tab. A team knowledge graph is built to be queried by software too, and that changes what it is for.

The mechanism is the Model Context Protocol (MCP), the open standard for connecting AI agents to the systems where data and context live. When the team graph is exposed over MCP, a coding agent like Claude Code or Cursor can read it directly. So before that agent writes a migration, it can read the decision that says you moved off the old library, see who owns the work, and read the reason, instead of confidently shipping code that re-litigates a call your team already made. The same graph a person reads in the morning is the one the agent reads at 2am.

That is the line that matters for an AI-native engineering team: the humans and the agents work from one source of truth, not two. Ody is callable from four places against the same graph: the web for owners, MCP for agents in the editor, a CLI in the terminal, and Slack in a thread. Ask in whichever place you already are.

One honest boundary. Ody senses continuously and compiles the graph on its own, but it acts only when a human says so. The ceiling of its autonomy is a nudge. It will tell you the billing flag is tied to a closed incident before you flip it. It will not flip it back, and it writes nothing into your tools on its own. The graph removes the surprise. The human keeps the decision.

If your team is twenty engineers and a growing number of agents, a callable graph is the difference between context that scales and context that walks out the door on a Friday. See a week in one team, or book a demo.