Why was the SQL Server loader documentation reverted in QueryWeaver, and who decided?

Commit 819b96a reverts 6cc5a67. Anchel135 reverted it, inside PR #719, which Gal Shubeli merged. The reason, pulled from the revert message: the file belonged on the SQL Server branch, and on this branch it broke spellcheck.

That is a real answer about a real repository in FalkorDB's own GitHub organisation. The graph work took tens of milliseconds. You can open the links and check every word.

Nobody wrote that down in a doc. The answer existed only as a path: a file, a commit that touched it, a commit that reverted that commit, the PR each commit belonged to, the people who authored and merged them, and a message two hops away from the file you asked about. That path is what we built HandsOnRepo to walk.

The problem: who knows what is not written anywhere

Every engineering organisation has the same unwritten knowledge. Who really owns the vector index code: not who is listed in CODEOWNERS, but who actually touches it. Who should review this PR. Why was that change undone, and who signed off. What breaks if one specific person leaves next month.

None of that lives in documentation. It lives in commit history, review threads, merge events and revert messages, spread across dozens of repositories. A new team member learns it by asking around for six months. An AI agent does not get six months.

Retrieval over documents does not fix this. The questions are multi-hop: file to commits to people to reviews to PRs to comments to who merged to what reverted it. A chunk of text does not hold a path. A graph does.

The idea

HandsOnRepo takes a public GitHub organisation name, builds that organisation's company brain as a graph inside FalkorDB, and lets you ask it questions that only a graph can answer. Every answer shows the tool it called, the graph time, the sources as real GitHub links, the exact subgraph it traversed, and the Cypher that ran.

We built it for Graph Hacks: Context for AI Agents, the WeMakeDevs and FalkorDB hackathon, for three tracks: Company Brain, Agents That Act on Connected Data, and Agent Memory and Coordination.

One decision shaped everything else: no fictional company. Many demos run on an invented company with a few dozen hand-written nodes, so nobody watching can verify an answer. So the demo brain is FalkorDB's own organisation: 8 repositories, 21k nodes, 73k edges, every person real, every PR number clickable.

Watch the demo

Under five minutes: FalkorDB's org, a live build on a repository we had never opened, and the MCP side.

What is in the graph

Ingestion pulls from two places: the GitHub GraphQL API for PRs, issues, reviews, comments and releases, and bare git clones for commit history and the files each commit touched. Repositories are fetched in parallel, so a mid-sized organisation takes about three minutes on a laptop, a little longer on free hosting.

Then FalkorDB does the second half of the work. After ingestion, Cypher derives the relationships the questions actually need. This is the real model, drawn from the schema the backend creates:

REVERTS edges are parsed from commit messages and PR bodies. TOUCHES aggregates every commit a person made to a file. REVIEWED_FOR points from reviewer to author and is the input to PageRank. Owner Fact nodes carry SUPERSEDES history, so when ownership changes the old answer is kept, not overwritten.

Two labels belong to the agents rather than GitHub. An Episode is a remembered answer, with edges to the sources it cited. An Action is something an agent did, for example a triage comment posted on a new issue, linked to the issue, the people it suggested and the evidence it used.

One graph per organisation, brain_<org>, in a single FalkorDB instance. Switching tenant is select_graph.

How an answer is produced

The chat agent is a tool-calling loop over 18 graph tools, with OpenAI gpt-5-mini as the model. The model does not answer questions. It picks a tool, and the tool runs Cypher or a FalkorDB algorithm. The model only phrases what comes back. A question costs about half a cent, and the graph part takes 2 to 90 milliseconds.

Take "Who should review a change under lib in falkordb-browser, and why them?"

The agent calls who_knows. It matches the files, follows TOUCHES and REVIEWED edges to people, and ranks:

MATCH (p:Person)-[t:TOUCHES]->(f:File)
WHERE f.key IN $files AND NOT coalesce(p.is_bot, false)
WITH p, sum(t.count) AS commits, count(DISTINCT f) AS files, max(t.last) AS last
OPTIONAL MATCH (p)-[:REVIEWED]->(pr:PR)-[:TOUCHED]->(f2:File)
WHERE f2.key IN $files
WITH p, commits, files, last, count(DISTINCT pr) AS reviews
RETURN p, commits, files, last, reviews
ORDER BY commits DESC, reviews DESC LIMIT 10

Then it breaks ties with a global score:

CALL algo.pageRank('Person', 'REVIEWED_FOR') YIELD node, score
RETURN node.key AS key, score

The final ranking is commits_on_topic + 2 * reviews_on_topic + 40 * PageRank(reviewer -> author). For this question it puts Anchel135 first: 210 commits touching 64 files under lib, 26 reviews on PRs that touched those files. The ranking is the graph's, not the model's guess.

The revert question from the top of this post runs reverts and decision_trail. One MATCH (a)-[:REVERTS]->(b) plus optional hops to authors, parent PRs, closed issues and comment threads, ordered by time.

And the one every maintainer dreads. "What happens if Guy Korland leaves? Who could cover?"

283 files touched, 145 that nobody else has ever touched, 10 open PRs, 18 assigned issues, and for each area, the collaborators who could cover it. That is a bus factor with names. It comes from a negative existence check over the person-to-file graph (files with exactly one human TOUCHES edge) plus nearest neighbours in the COLLABORATES projection. Neither exists in a document store.

If you remove FalkorDB, nothing works. There is no cache and no fallback store. The graph is the product.

An org we had never touched

A fair question for any demo: does it only work on data you prepared? So we typed google-ai-edge, an organisation we had never opened, and clicked Build brain.

212 seconds later: 36,514 nodes, 112,095 edges, all eight of its most active repositories. The suggested questions on the empty chat were generated from that org's own graph, not canned: its busiest area, its most active person, a real PR to trace. (The live site runs on FalkorDB Cloud's 100 MB free tier, which already holds the FalkorDB org, so in the video we build just the Gallery repository there: paste a repository link instead of an org name and HandsOnRepo builds only that repo.)

"Who should review a change to the Gallery app?" Kangning Chen, 382 commits on 104 Gallery files, last touched two days earlier. Then Zichuan Wei, 311 commits on 84 files.

"What happens if Sebastian Schmidt leaves?" 877 files touched, 695 that only he has touched. On an org we had opened four minutes earlier.

Four things the graph told us about FalkorDB

All of this comes from public data, and every line links to the evidence. It is the kind of thing a team knows in fragments and rarely sees in one place.

1. One person holds 145 files nobody else has touched. Guy Korland has touched 283 files across the organisation, 145 of them with no other human commit ever, plus 10 open PRs and 18 assigned issues. The graph also names who could cover each directory, so this is a to-do list, not a scare.

2. A revert whose reason lived three hops away. Commit 819b96a in QueryWeaver reverted the SQL Server loader docs. The commit message explains it; the context (the SQL Server branch, the spellcheck failures, who merged PR #719) is spread over the commit, the PR and its comment thread. No single page on GitHub shows that path.

3. The vector index has a clear owner and a clear backup. For graph/src/index, Dvir Dukhan has 186 commits on 30 matching files and 22 reviews on PRs touching them; Avi Avni has 93 commits on 51 files. Codex reached the same pair through MCP without being told.

4. Bots would top every ranking if you let them. Of the accounts the ingestion saw in the FalkorDB organisation, 225 were bots or shared automation identities. Dependabot, Copilot, CodeRabbit and release bots author and comment more than most humans. Flagging them is the difference between a credible answer and a silly one.

Memory and coordination: three agents, one graph

Every answer is stored back into FalkorDB as an Episode citing its sources. Before the next question the agent runs a full-text query over memory and shows matches as "Remembered from earlier". Memory survives restarts because it is in the graph, not in a process.

Three agents share that memory with no message passing between them: the chat agent in the web app, a triage agent that fires on a GitHub webhook when an issue is opened, finds the likely owner through the graph, posts a comment with the evidence and leaves an Action node behind, and any MCP client.

The MCP server exposes the same 18 tools and works in Claude Desktop, Claude Code, Cursor, Codex, Antigravity, VS Code, Gemini CLI and Cline:

{
  "mcpServers": {
    "handsonrepo": {
      "command": "/path/to/.venv/bin/python",
      "args": ["/path/to/mcp/server.py"],
      "env": { "BRAIN_DEFAULT_ORG": "FalkorDB" }
    }
  }
}

The first real task we gave it, from Codex: "Use the handsonrepo MCP tools. I am about to change the vector index code under graph/src/index in FalkorDB/FalkorDB." Codex called who_knows, reverts, decision_trail and remember, then wrote a PR_NOTES.md naming Dvir Dukhan as primary reviewer (he approved and merged the vector fix, PR #3087) and Avi Avni as backup (owner of graph/src/index/mod.rs). It stored the decision as an Episode tagged mcp.

We opened the web app and the chat agent showed it as "Remembered from earlier". One graph, two clients, shared state, no glue code.

What broke, and what we learned

Free text-to-Cypher was not trustworthy enough for the key questions. Early on we let the model write Cypher from scratch. It invented relationship names, forgot the bot filter, and produced a different query for the same question on every run. So the 18 tools are tested Cypher with parameters, the model only chooses and phrases, and a read-only run_cypher is kept as a last resort with a guard that refuses writes.

FalkorDB has no undirected shortestPath. find_path needed to connect a person to a PR through edges that point both ways. We used algo.SPpaths with relDirection: 'both' over 15 relationship types instead.

EXISTS subqueries are not supported. Our first "files only this person touched" query used one. We rewrote it as WITH f, collect(p) AS ps WHERE size(ps) = 1, which turned out to be clearer anyway.

A 100 MB free-tier instance holds a 21k-node org at about 83 MB. Indexes and comment bodies are the memory hogs, not nodes and edges. Trim comment text and be deliberate about full-text indexes if you want two orgs on one small instance.

Git identities are not GitHub users. Commit authors arrive as names and emails, often GitHub's noreply addresses. We fold them into GitHub logins by email, name and noreply pattern. The ones we cannot fold stay as names without handles and are never shown as mentions.

Bots are 10 to 30 percent of accounts. dependabot, copilot, coderabbit and friends would top every ranking. Every ownership, review and trail query excludes is_bot.

By the numbers

Measured on the FalkorDB organisation, on a laptop.

Run it in three commands

You need Docker, Python 3.12+, Node 20+, a GitHub token with public_repo scope and an OpenAI key in backend/.env.

# 1. FalkorDB, with its browser on :3000
docker run -d --name falkordb -p 6379:6379 -p 3000:3000 falkordb/falkordb:latest

# 2. Backend, then build a brain
pip install -r backend/requirements.txt && cd backend && python -m app.ingest FalkorDB && python -m uvicorn app.main:app --port 8000

# 3. Frontend
cd frontend && npm install && echo BACKEND_URL=http://localhost:8000 > .env.local && npm run dev -- -p 3001

Open http://localhost:3001, type an organisation name, click Build brain.

Stack: FalkorDB (Cypher, PageRank, betweenness, label propagation, full-text indexes, one graph per org), Python FastAPI, Next.js with a force graph, an MCP server, deployed on FalkorDB Cloud, Render and Vercel.

Try it on your own org

The live app is at handsonrepo.vercel.app. Open the FalkorDB brain and ask the questions above, or build your own and ask it something only you know the answer to. That is the whole point: if the answer is wrong, you will know, and so will we.

Two practical notes. The free FalkorDB Cloud instance behind the demo is 100 MB and the two brains already fill about 95 percent of it, so to build a new one live, pick a small organisation or paste a single repository link (github.com/owner/repo). And the public demo is capped at 150 questions a day so the OpenAI bill stays sane. For unlimited use, run it locally with the three commands above.

The code is at github.com/mithuna2357/FalkorDB, MIT licensed. If it earned it, a star helps other people find it.

HandsOnRepo is by team OrByte: Chethan Vasthaw Tippani (Chethan-4255) built the backend engine, the ingestion, the graph model, the agent and the MCP server. Mithuna Somireddy (mithuna2357) built the frontend, the deployment and the docs. Built for Graph Hacks: Context for AI Agents, October 2026.