KT Brain
At the startup I work with, every time someone leaves, knowledge transfer turns into a scheduling puzzle. You have to find a slot when both developers are free, then cram six months of context into a one-hour call. Half of it never makes it across. So I built KT Brain.
It’s a SaaS where a company connects the tools it already uses, and KT Brain turns them into a knowledge graph of what its developers know:
- GitHub commits and PRs
- Jira tickets
- Company chat (we used Google Chat)
- Research docs, ADRs, runbooks, postmortems
- Coding agent session logs, meaning the Claude Code conversations where half the real reasoning now happens
2 developers, Arjun & Priya left the company & Meera joins the company and is working on payment feature.
Here’s a story that has happened at every company that ships software.
Someone sets a payment retry count to 7. It’s a strange number, so everyone assumes there was a reason. Six months later that person is gone. A new developer sees the 7, thinks “that seems like a lot,” and changes it to 3. Payments start failing.
The reason it was 7 was real. It lived in a chat thread, a Jira ticket, and a Claude Code session that nobody saved. The code kept the what and lost the why.
That’s the problem I built KT Brain to fix. (KT stands for knowledge transfer, the thing everyone promises to do before someone leaves and nobody has time for.)
Then you can ask it things in plain English:
- “Why is the retry count 7?”
- “Who actually knows how our backups work?”
- “What happens if Arjun leaves?”
And it answers with receipts: the PR, the ticket, the chat message, and the person.
“Isn’t that just a RAG chatbot?”
Fair question. I asked myself that too.
A RAG chatbot chops your docs into pieces, finds the pieces that sound like your question, and has an LLM summarize them. That’s useful, and we do have that layer. It’s one tool among several.
But “why was this built this way?” is not a similarity question. It’s a trail:
▎ ticket → PR → commit → chat thread → decision → person
Text that sounds similar can’t follow that trail. A graph can. So KT Brain extracts real entities (people, files, decisions, tickets) and the typed links between them. The AI agent on top never writes its own database queries. It picks from a fixed menu of vetted graph tools: why, who_knows, if_leaves, radar, search. That makes answers repeatable, cited, and much harder to talk into nonsense. When there’s no evidence in the graph, it says so instead of making something up.
Vector search is in there too, in the same database. It’s a supporting actor, not the star.
The part I’m most proud of: “What if they leave?”
Answering questions is nice. But the thing managers actually lose sleep over is: who’s the only person who knows X?
KT Brain computes who knows what by looking at real behavior:
Then comes the fun bit. Pick someone and hit “if leaves”. KT Brain copies the entire company graph using FalkorDB’s GRAPH.COPY, marks that person inactive on the copy, and asks: what does nobody else know now? The real graph is never touched. It’s a fire drill for your team’s knowledge, with no actual fire.
Get Shreyash Mandlapure’s stories in your inbox
Join Medium for free to get updates from this writer.
My favorite result is what I call combination risk. One decision in our demo (rotating secrets) is known by two people. If either leaves alone, you’re fine. If both leave, nobody is left. No single-person view catches that. The graph does.
The demo: meet TiffinBox
I didn’t want to demo on a toy, so I built TiffinBox, a fictional meal-subscription startup. It has a full cast (Arjun, Priya, Kavya, Meera, Rohan, Neha), real-looking commits and PRs, tickets, Google Chat threads, 17 Claude Code sessions, and long design docs.
I planted an answer key in the data: decisions with known right answers, plus a few traps:
- a decoy decision that looks important but isn’t
- a superseded decision (the team deployed everything at once, then stopped)
- a combination decision only visible when two people leave together
Then I wrote tests that check whether KT Brain finds the right answers. That’s how I knew the graph was right, and not just plausible-sounding.
What I learned
1. A graph database is a good fit when the question has a shape
“Who knows this, and does anyone else?” is a 3-line path pattern in Cypher. In SQL it’s recursive CTEs and a headache. FalkorDB being in-memory and a one-container Docker setup meant I could try an idea in the Browser, see the graph drawn, and put it in code ten minutes later.
2. One database beats three
Entities, edges, text chunks, vector indexes, and full-text indexes all sit in the same graph. No syncing a separate vector store, no “which system is the truth?” That decision saved me a lot of pain.
3. Don’t let the LLM write your queries
My agent picks from a fixed set of tools. It’s less flashy than “AI writes Cypher”, but it’s safer, testable, and gives the same answer twice. Boring on purpose.
4. Commits are not knowledge
My first instinct was “whoever committed it knows it.” That’s wrong. Someone can commit a typo fix to a file they’ve never understood. So reviews, docs, and real discussion count, and trivial commits and AI-only sessions are capped. It’s still not perfect (lots of non-trivial-looking spam commits would still inflate a score), and I’d rather say so than pretend.
5. I found two FalkorDB bugs (on a hackathon clock)
Fun detour. Both are on FalkorDB 6.0.2 and both involve OPTIONAL MATCH plus aggregation:
- Bug 1: an OPTIONAL MATCH after WITH … count() returns no rows. Every item in my graph suddenly looked like nobody else knew it. I rewrote the query as one MATCH with sum(CASE …).
- Bug 2: an OPTIONAL MATCH … RETURN with 7+ grouping keys (one always null) plus count() makes the server panic (reply.rs:655, an unwrap() on None) and drop every connection. My admin login returned a 500 and I stared at it for a while. The workaround was counting with a pattern comprehension: size([(s)-[:RECORDS]->(d) | d]).
Both workarounds are marked in the code. I’ll be honest: finding engine bugs wasn’t the plan, but working around them taught me more about how the engine thinks than any tutorial did.
6. Be honest about what’s cool and what’s just there
GRAPH.COPY for the “if leaves” drill is neat. But today the copy only flips an active flag, so a simple filter would give the same answer. I’m keeping it because it’s the right foundation once the dry run does more (re-deriving scores, simulating a successor learning things). I’d rather admit that than oversell it.
What’s next
- More sources (GitLab, Linear, Notion, Teams)
- An onboarding mode: new hires ask the brain instead of interrupting senior engineers
- Proactive nudges: “Only one person understands the billing module. Schedule a handover.”
The next time someone says “we’ll do the knowledge transfer before they leave,” maybe the knowledge could already be there.
Built for the FalkorDB Graph Hacks hackathon.
Thankyou :)
