Building a Company Brain in 3 Days: How Graph Memory Makes Every AI Answer Traceable

Most people imagine a "company brain" as a chatbot that can answer questions about documents. But Recall, an open-source project that developer Anshu built in three days, points to a more fundamental problem: when an engineer asks "Why did INC-231 happen?" the system doesn't need a semantically similar passage—it needs a complete causal chain: which PR, which decision, which commit caused the incident, and who knows the relevant systems best.

This article breaks down the design philosophy behind Recall: using the graph database FalkorDB to carry the causal relationships of company knowledge, making every answer traceable, isolating memory per person and managing it by version, and forcing the Agent to stop and wait for human approval before executing.

Why RAG Isn't Enough

Traditional RAG chunks documents, vectorizes them, and retrieves by semantic similarity. This approach works for "find a relevant passage," but the questions that truly matter in a company are often not similarity problems—they're connection problems.

"Why did it happen" is a path problem; "what will break if I change this" is a traversal problem; "who understands this system" is a ranking problem. All three point to the same thing: the relationships between pieces of knowledge matter more than the knowledge itself.

So Recall models company knowledge as a graph: events, PRs, commits, architecture decision records (ADRs), services, people, teams, and chat messages are all nodes, connected by labeled edges, all queryable via Cypher. The author explicitly states that the demo company Meridian Pay is fictional, and that the people and incidents are seed test data—but the FalkorDB instance, the queries, and the Agent behavior are real. This honesty about the boundaries of evidence is itself part of the project's design philosophy.

Graph databases and Cypher queries

A graph database uses nodes and edges as its basic storage units, making it naturally suited to expressing multi-hop relationships between entities. Unlike traditional relational databases, graph databases don't need expensive JOIN operations when traversing deep associations—they jump directly via pointers, making path queries like "find the PR that caused the incident" extremely efficient. FalkorDB is a graph database built on sparse matrices and linear algebra, supporting the property graph model and compatible with the OpenCypher query language. Cypher is a declarative graph query language that describes paths using ASCII-art-like patterns, for example (e:Event)-[:CAUSED_BY]->(pr:PR) means an event is caused by a PR. Recall uses Cypher to implement causal traversal, dependency analysis, and expert ranking, so that every conclusion can be traced back along the edges of the graph to its source node.

Every Conclusion Must Be Citable

Recall's core rule is strict: if the model can't cite a node, it can't state the corresponding conclusion. When a user asks about the cause of an incident, the Agent performs causal traversal rather than text generation: first locate the event, then trace back the PRs and decisions that caused it, display the full path, annotate sources along the way, and finally list the relevant people and the experts who know the system best.

This contrasts sharply with the experience of most AI products. Usually you get a confident, fluent paragraph that you can't verify or trace—you just have to trust the model. Recall reverses the order: the quality of the answer depends on the quality of the citations, and the citations sit right next to the answer.

Causal traversal and traceable reasoning

Causal traversal means exploring "cause-effect" paths directionally in a graph, rather than simple keyword matching. In Recall, when a user asks about the cause of an incident, the Agent starts from the event node and traces back layer by layer along labeled edges such as CAUSED_BY, DECIDED_BY, and AUTHORED_BY, until it finds the root-cause node (such as a commit or an ADR). Each node along the way carries source information (such as a PR link or a chat message ID), and these sources form the citation chain. Traceable reasoning requires that the model can only use nodes actually visited during traversal as the basis for generating an answer, thereby eliminating hallucinations. This mechanism shifts the reliability of answers from the model itself to the graph's structure and citation integrity.

Memory Has Boundaries and a Lifecycle

Company memory isn't global. If Priya tells the system "the deployment window is 2–4 PM," that's Priya's memory and shouldn't automatically become her colleague Anshu's fact. Recall builds a separate memory graph for each person, all running on the same FalkorDB instance.

Memory also evolves. When Priya later says "change it to 2–4 AM," the old fact isn't deleted—it's marked as superseded, and the new fact becomes the active version. The past is versioned but never rewritten. If a user asks to completely forget a fact, the system performs a forget operation and issues an "erasure receipt" that proves what was deleted and when.

This design addresses a hidden obstacle to many enterprise AI deployments: employees don't trust a system that silently rewrites or mixes up memories.

Versioned memory and erasure receipts

Versioned memory means keeping a historical version of every change to a fact rather than overwriting the old value. Recall uses a "supersede" strategy: a new fact marks the old one as superseded, but the old fact remains in the graph—only its status changes. This allows the system to answer "what was the fact at a given point in the past," meeting audit and compliance needs. An erasure receipt is proof issued by the system when a user requests complete forgetting; it records the identifier of the deleted fact, the deletion time, and the operator, but the receipt itself does not contain the fact's content. This design balances the usability of memory with users' desire for data control, and is especially suited to enterprise environments where employees are sensitive about privacy and memory ownership.

Pausing Is a Feature, Not a Bug

When a user asks "what will break if I migrate the ledger database," the Agent traverses outward along service dependencies, ranks the impact surface, and produces a migration proposal—then stops.

This pause is intentional. Nothing happens without a human clicking approve. And the approval action itself becomes a node in the graph, so the audit trail persists even after a backend restart. The author verified this by killing the backend process in the middle of an approval: the executor reads the approved proposal from FalkorDB rather than from process memory, so the workflow resumes from where it was interrupted.

This corresponds to a principle: the Agent proposes, the human disposes. The pause before execution is the most important part of the entire loop.

Human-in-the-loop and persistent approvals

Human-in-the-loop refers to placing checkpoints in automated workflows that must be confirmed by a human, ensuring that critical operations remain under control. Recall models the approval action as a node in the graph (such as Approval) and links it to the proposal node. Because approval state is persisted in FalkorDB, the executor reads approved proposals from the graph database when resuming, rather than relying on volatile process memory. This achieves atomicity and recoverability for approvals: even if the backend crashes, approved proposals aren't lost, and unapproved ones won't be executed by mistake. This pattern embeds human decisions into the graph structure, making the audit trail part of the knowledge graph rather than a side-channel log.

Kill Switch: Pull the Database and the Product Should Honestly Say It Doesn't Know

The hackathon rules required FalkorDB to be core rather than decorative: "if the product still works when you take FalkorDB away, then the graph is just decoration."

Recall builds this test into the demo: disconnect FalkorDB, and the entire product degrades to an honest "I don't know." No silent fallback, no pretending it can still answer. Most demos tell you the database matters; Recall directly shows what happens without it.

Benchmarks, Including the Misses

The author ran 30 questions across five categories, comparing graph retrieval with flat RAG—same corpus, same model, same scoring criteria. The result: graph retrieval scored 24.667, flat RAG 19.251.

But the point is the honesty: graph retrieval lost 5.333 points, including two hard zeros because the scorer required exact wording and the model paraphrased, with the rest being scattered partial-credit losses across categories. The README records every lost point. The author could have adjusted the questions or deleted the zero-score items, but didn't—a system whose selling point is "showing the work" must also show the work of its benchmarks. In a re-run validation, graph retrieval won again, 25.0 to 19.251, with a consistent gap.

The Hardest Bug Was in the Test Suite

The trickiest problem wasn't in the graph database—it was in the test code. An end-to-end check asserted that the model's answer must contain the literal string "Ledger freeze ends Friday," and it failed in four different ways across four runs: lowercase, Markdown bold, an invisible narrow no-break space, and a paraphrase to "ends on Friday." The data was correct every time; the assertion was wrong.

The author's conclusion is blunt: never assert on LLM prose—assert on structured data. After rewriting the test to check structured evidence blocks, the stability problems disappeared.

Another lesson: scope memory before searching it. Don't dump the entire memory store into the model and hope it figures out relevance on its own—resolve the user, resolve the scope, retrieve only the applicable parts, and then rank.

One-Sentence Summary and Seven Principles

Recall can be summarized as: store the company's causal history in a graph and reason over it, so that every answer traces a path, every memory respects ownership, and every action waits for a human.

The seven principles the author distilled are worth considering for anyone building enterprise AI systems: every conclusion needs a citation; memory is scoped per person; the past is versioned rather than rewritten, and deletions issue a receipt; the Agent proposes, the human disposes; the graph is the foundation rather than a feature, and when disconnected the product should honestly stop; show the misses—a benchmark that hides zeros is marketing, while one that records zeros is evidence; don't assert on LLM prose, assert on structured data.

All these principles point to visibility—every part of the process, including failures, is visible, and that is precisely where credibility comes from. The project code and demo video are publicly available on GitHub and YouTube.

One-line Summary

Open-source project Recall uses a graph database to build a traceable, per-person company memory system that requires human approval.

Paragraph Summary

Recall is an open-source project aimed at addressing the shortcomings of traditional RAG in enterprise knowledge management. It uses the graph database FalkorDB to model company knowledge as nodes and edges, supporting causal-chain queries, dependency traversal, and expert ranking. The system requires every conclusion to be citable, isolates memory per person and versions it, and issues receipts for forget operations. Before executing, the Agent must pause and wait for human approval, and approval actions are persisted to the graph. Benchmarks show that graph retrieval outperforms flat RAG; the author discloses all lost points and distills seven principles, emphasizing that visibility and the boundaries of evidence are the source of credibility.