Why am I even thinking about company memory?
Whenever we talk about AI brain for companies, the first thing that usually comes to mind is a chatbot over some documents. You upload your docs, you ask questions, you get answers.
But I think the actual problem is more interesting than that.
Imagine I am an engineer at a company and I ask:
"Why did INC-231 happen?" (INC-231 is just an incident ID, don't worry about it)
What exactly should happen?
The system needs to understand that I am not asking for a document. I am asking for a causal chain (causal as in cause-and-effect, not a typo for casual). It needs to:
- Find the incident in the company's history.
- Trace what caused it: which PR, which decision, which commit.
- Show me the path, not just the answer.
- Cite every source along the way.
- Tell me who was involved and who knows the most about it.
And now take this one step further.
What if I then ask:
"What breaks if we migrate the ledger database?"
The system needs to follow service dependencies outward, rank the impact, and then, before doing anything about it, stop and ask a human for permission.
That's where the idea of Recall comes in.
First, let's understand the problem
Company knowledge doesn't live in one place. It lives in:
- Incidents (what broke)
- PRs and commits (what changed)
- ADRs (why decisions were made)
- Chat messages (what the team actually said)
- People (who knows what)
A normal RAG system chunks all of this into vectors and hopes semantic similarity finds the right pieces. But the questions I care about aren't similarity questions. They're connection questions:
"Why did this happen?" is a path question.
"What breaks if I touch this?" is a traversal question.
"Who knows this system?" is a ranking question.
These are graph questions. So I built a graph.
The graph model
The core idea is simple. Everything a company knows becomes nodes and edges:
People, teams, services, incidents, PRs, commits, decisions, chat messages. All connected. All queryable with Cypher.
But here's the thing I want to be clear about. The demo company, Meridian Pay, is fictional. Every person, incident, and message is seeded test data. What's real is the FalkorDB instance, the queries, and the agent behavior. I say this upfront because the whole point of the project is honesty about evidence.
What "shows its work" actually means
When you ask "why did INC-231 happen?", the agent doesn't just generate an answer. It runs a causal traversal:
Every claim in the answer links back to a node. If the model can't cite it, it doesn't say it. That's the rule.
I think this matters more than it sounds. Most AI answers are confident prose with no provenance. You can't check them. You can't trace them. You just have to trust the model. Recall inverts that: the answer is only as good as its citations, and the citations are right there.
Memory has scope
This is something I thought hard about. In a company, memory isn't global.
If Priya tells the system "the deploy window is 2-4 PM," that's Priya's memory. Anshu shouldn't see it as his own. So each person gets their own isolated memory graph, running as a separate graph in the same FalkorDB instance.
And memories have a lifecycle. When Priya later says "actually, make it 2-4 AM," the old fact isn't deleted. It's superseded:
The past is versioned, never rewritten. And if someone wants a fact gone entirely, there's a forget operation that issues an erasure receipt. You can prove what was forgotten and when.
The agent acts, but only with permission
Here's the flow:
The pause is the feature. The agent proposes a database migration, shows you the blast radius, and then stops. Nothing happens until you click approve. And the approval itself becomes a node in the graph, so the audit trail survives even if the backend restarts mid-flow.
I verified that last part by killing the backend mid-approval. The executor reads the approved proposal from FalkorDB, not from process memory. It picked up where it left off.
The kill-switch
This is the part I'm most serious about. The hackathon rules say FalkorDB must be central, not decorative. "If the product still works once FalkorDB is taken out, the graph is decoration."
So I built the test into the demo. Disconnect FalkorDB and the entire product falls back to honest "I don't know" answers. No graph, no answers. No silent degradation, no pretending.
Most demos tell you the database matters. Mine shows you what happens without it.
The numbers, including the misses
I ran 30 questions across five categories. Graph vs flat RAG. Same corpus, same model, same scoring.
Graph: 24.667. Flat RAG: 19.251.
But here's what I want to be honest about. The graph lost 5.333 points. Two hard zeros where the scorer demanded exact phrasing and the model paraphrased. Plus partial-credit losses scattered across categories. The README documents every one of them.
I could have tweaked the questions or dropped the zeros. I didn't. If I'm building a system whose entire pitch is "show your work," the benchmark has to show its work too.
I re-ran the eval to check reproducibility. Graph won again, 25.0 to 19.251. Same margin. The numbers hold.
What I learned
The hardest bug wasn't in the graph. It was in the test suite.
An e2e check asserted the literal string "Ledger freeze ends Friday" in the model's answer. It broke four different ways across four runs: lowercase, markdown bold, an invisible unicode narrow no-break space, and a paraphrase ("ends on Friday"). The data was correct every time. The assertion was wrong.
I rewrote it to check the structured evidence block instead of the prose. The lesson is simple:
Never assert on LLM prose. Assert on structured data.
The second lesson: scope your memory before you search it. Don't dump the entire memory store into the model and hope it figures out what's relevant. Resolve the user, resolve the scope, retrieve only what applies. Then rank.
The architecture in one sentence
If I had to explain Recall in one sentence:
Recall keeps a company's causal history in a graph and reasons over it, so every answer traces its path, every memory respects its owner, and every action waits for a human.
Final principles
If I had to reduce the whole project to a few principles:
- Every claim needs a citation. If the model can't cite it, it doesn't say it.
- Memory is scoped. A fact belongs to a person, not to the system.
- The past is versioned, never rewritten. Supersede, don't delete. And when you do delete, issue a receipt.
- The agent proposes. The human disposes. The pause before execution is the most important part of the loop.
- The graph is the foundation, not a feature. Disconnect it and the product should honestly stop, not silently degrade.
- Show your misses. A benchmark that hides its zeros is marketing. A benchmark that documents them is evidence.
- Never assert on LLM prose. Assert on structured data.
The main idea
The way I currently think about it is:
Company knowledge is a graph. Answers are paths through it. Memory is scoped and versioned. Actions require permission. And everything, including the failures, should be visible.
That visibility is what makes it trustworthy.
By Anshu
Built for the WeMakeDevs x FalkorDB Graph Hacks hackathon. I used OpenCode as a coding assistant with Muse guiding the work. The architecture, the graph schema, and every verification step are my own. Meridian Pay is fictional; the graph, the queries, and the kill-switch are real.
Repo: https://github.com/101xAnshu/Recall
Video: https://youtu.be/F9H5nxtCiow
Top comments (0)