Knowledge graph · Graph Hacks 2026
Know who knows.
Know why it was decided.
Every team has modules only one person understands. Keystone turns a codebase's real history into a graph, then answers who should review, who knows what, where knowledge is at risk, and why a decision was made. Every answer shows its evidence.
For judges · where each track is satisfied
Agents That Act on Connected Data
Picks graph tools (multi-hop scoring, PageRank, betweenness, shortest path), shows the exact Cypher, exposes them over MCP, and opens a real issue on approval.
See it → Track 02Agent Memory and Coordination
A graph per user holds episodic, semantic and procedural memory. A rule you teach changes the next answer. Two agents share one queue with an atomic claim.
See it → Track 03Company Brain
People, modules, PRs, issues and decisions in one graph. Ownership, knowledge risk, and every decision traced to a verified quote.
See it →Demo video
01 · The problem
Every team has modules only one person understands.
This is a real codebase: FalkorDB's own repositories, grouped by repo. Each tile is a module; size is how active it was in the last year, colour is how much of that history one person holds. Warm tiles are where the knowledge leaves if that person does.
Where it is most concentrated
A statement about modules, not a judgment of any person.
02 · Ask
Ask in plain English. See exactly how it knew.
The agent chooses among nine fixed graph tools. It never writes a query and never sees the database. On the right: the reasoning trail the answer rests on, the same data as a graph, and the exact Cypher that ran.
03 · Remember
It remembers, and remembering changes its answers.
Memory is not a chat log. Each person gets their own FalkorDB graph holding what they asked (episodic), what they approved or rejected (semantic), and rules they taught it (procedural). Three steps, all real.
04 · Act
Agents that hand off work, and take real action.
A triage agent queues open pull requests and flags those touching at-risk modules. Router workers claim tasks through one atomic write, so two workers can never take the same one. On your approval an executor opens a real issue in our sandbox repository; it never writes to the project being analysed.
The shared queue
Tasks are nodes in a FalkorDB graph that every agent reads and writes.
05 · Trust
Does it actually work? We measured it.
We hid the real reviewers of later pull requests and asked each method to predict them using only the history before each PR was opened. Weights were tuned on separate data; the test slice was never touched.
The model is never trusted on its own
An LLM proposes decisions with a quote. Code keeps one only if the quote is a verbatim substring of the source message and a second check confirms it states the decision.
Per-repository results (hit@3 on the test slice)
What we do not claim
- It predicts who did review, a proxy for who should.
- Risk is per module, never a judgment of a person; only public handles are used.
- The docs repository is the weak case (0.65): its main reviewer changed over time.
- We have not measured time saved for a real team.
06 · How it works
A graph, nine fixed tools, and an agent that cannot touch the database.
Everything the product knows lives in FalkorDB. Take FalkorDB away and there is nothing left to run.
The graph model
(Person)-[:AUTHORED|REVIEWED]->(PR)-[:TOUCHES]->(File)-[:IN]->(Module)-[:PARENT]->(Module) (Decision)-[:DECIDED_IN]->(PR|Issue) (Person)-[:STATED]->(Decision) (Person)-[:COLLAB|LINKS|KNOWS]-> derived for algorithms and paths one graph per tenant (kb_x), per user (mem_x), per task queue (ops_x)
FalkorDB features used: openCypher, variable-length traversal, PageRank, betweenness, label propagation, shortest path, HNSW vector index, named graphs, RO_QUERY.
The query behind "who should review this?"
MATCH (f:File) WHERE f.id IN $files
MATCH (p:Person)-[r:AUTHORED|REVIEWED]->(pr:PR)-[:TOUCHES]->(f)
WHERE pr.createdAt < $asof AND p.login <> $author
RETURN p.login,
sum( (CASE type(r) WHEN 'REVIEWED' THEN 1.0 ELSE 0.5 END)
* exp(-($asof - pr.createdAt) / $tau) ) AS s
History strictly before the PR, reviews weighted above authorship, exponential recency decay (tau 90 days). The same query, with $asof set to each PR's creation time, is the evaluation.
Track 01 · MCP tool selection
Use it from any agent
The same read-only graph tools are exposed over the Model Context Protocol, so Claude Desktop, Claude Code, Cursor or any MCP client can list them, pick the right one for a question, and get answers with their evidence. Tested end to end with a real MCP client.
| Tool | What the client can ask |
|---|---|
| who_knows | Who knows a module, path or topic |
| suggest_reviewers | Reviewers for a PR, with the PRs that justify them |
| bus_factor | Modules where knowledge is concentrated |
| bridges | People who connect groups (betweenness) |
| connection | Shortest path between two people |
| why_decision | Past decisions with verbatim quotes and sources |
Claude Desktop / Cursor config
{
"mcpServers": {
"keystone": {
"command": "python",
"args": ["-m", "keystone.mcp_server"],
"env": { "OPENAI_API_KEY": "..." }
}
}
}
Claude Code
claude mcp add keystone -- python -m keystone.mcp_server
Run from the repository with FalkorDB reachable (docker compose up or your own instance). Then ask your agent: "Who should review FalkorDB/GraphRAG-SDK#328?"
Run it anywhere
docker compose up starts the app with FalkorDB and both graphs preloaded. One command builds a graph from any public repos.
Tested, not just demoed
Unit, isolation and concurrency tests, including 12 threads racing for 30 tasks with each claimed exactly once.