Gary

Overview

Every company has a Gary. He has been there since the early days. Ask him why the refund window is 14 days and he tells you the whole story in two minutes: the refund abuse in July, the Slack thread where the CEO approved the change, and the old Notion page you should stop trusting.

The day Gary goes on holiday, things slow down. The day he leaves, the company simply forgets. So I built a Gary that never leaves.

Instead of throwing every document into a search index, Gary builds a graph of people, teams, systems, projects, every record, and most importantly the decisions people made and which older decisions they replaced. Questions are answered by walking that graph, so every answer carries its path.

Built for Graph Hacks 2026, the FalkorDB and WeMakeDevs hackathon, in October 2026. Main track: Company Brain.

The Problem

Company knowledge does not live in one place, and it does not stay true.

In the demo company, a Notion page from February says customers can get a full refund within 30 days. In June, a pricing meeting changes the rule for annual plans. In August, the CEO cuts the monthly window to 14 days in a Slack thread because of refund abuse. Nobody updates the Notion page, the support playbook or the public help center article.

Now support asks: “Can a customer get a full refund after 20 days?” A normal document chatbot finds the pages with the right words and says yes, 30 days. Very confident. Completely wrong.

Similarity search can find text that sounds like the answer. It cannot tell you which of three contradicting documents is still true, because that information lives in the relationships between them, not in the words.

Goals of the Project

System Architecture

Records flow in through one ingestion pipeline and come out as nodes and edges. Questions flow through an agent that can only read the graph through a fixed tool catalogue, and every answer is checked against the rows those tools returned before it reaches the screen.

Decision extraction is the interesting part of ingestion. The language model reads each record while looking at the decisions currently in force, so it can say which older decision a new one replaces, why it was made and which docs repeat it. Reads go through GRAPH.RO_QUERY, so the agent side physically cannot write.

The Graph Model

Two relationships carry most of the weight. SUPERSEDES links a newer decision to the one it replaced, and it is the heart of Gary. ASSERTS links a doc or ticket to a decision it repeats, so the moment that decision is replaced, the doc is stale.

Key Features

Proof the Graph Does the Work

A fair test for any graph project is simple: take the graph away and see what breaks. The app runs a plain document chatbot next to Gary with the same records, the same language model and FalkorDB's own full-text index, just without the relationships.

Current versus replaced decisions, stale documents, who knows what, single points of knowledge, the time machine, multi-hop “why” answers and memory that expires are all walks through the graph. None of them can come from text similarity alone.

The Cypher Behind It

The agent picks from 12 tools: decision_lineage, who_knows, profile, connect, risk_radar, real_teams, as_of, catch_up, search, open_ticket, fix_stale_docs and remember. Each one is a fixed query with parameters. Three of them do most of the heavy lifting.

MATCH (s:Entity {key:$key})
MATCH (cur:Decision {status:'active'})-[:ABOUT]->(x)
WHERE x = s OR (s)-[:USES]->(x)
OPTIONAL MATCH chain = (cur)-[:SUPERSEDES*1..6]->(:Decision)
WITH cur, chain ORDER BY length(chain) DESC
WITH cur, collect(chain)[0] AS longest
RETURN cur.key AS key, [n IN nodes(longest) | n.key] AS lineage

MATCH (cur:Decision)-[:SUPERSEDES*1..6]->(old:Decision) WHERE cur.key IN $heads
MATCH (doc:Doc {living:true})
WHERE ((doc)-[:ASSERTS]->(old) OR (old)-[:DECIDED_IN]->(doc))
  AND NOT (doc)-[:ASSERTS]->(cur)
OPTIONAL MATCH (a:Person)-[:AUTHORED]->(doc)
RETURN DISTINCT doc.key AS doc, doc.title AS title, old.key AS old,
       cur.key AS current, a.name AS author

MATCH (s:Entity {key:$key})
MATCH (d:Decision)-[:ABOUT]->(x)
WHERE (x = s OR (s)-[:USES]->(x))
  AND d.at <= $t
  AND (d.superseded_at IS NULL OR d.superseded_at > $t)
OPTIONAL MATCH (n:Decision)-[:SUPERSEDES]->(d)
RETURN d.statement, d.at, n.statement AS later_replaced_by, n.at AS replaced_on

Application Flow

Challenges and Solutions

Tech Stack

Deployment and Data Ethics

The app runs on Vercel against a FalkorDB Cloud instance, and the same graph can be run locally with Docker Compose, which also brings up the FalkorDB Browser for poking at the graph directly. One graph per company is already supported through GRAPH_NAME.

All data is synthetic. Kitestring is a made-up 21-person billing startup with 65 records across Slack, Jira, Notion, meetings and GitHub. Its storylines, like two refund policy reversals, a SOC2-delayed migration and an engineer going on leave mid-cutover, are written so the right answer always depends on how things connect. No private, personal or scraped data is used anywhere.

Conclusion

Most “chat with your docs” tools treat company knowledge as a pile of text. Gary treats it as a history of decisions, and that one change is what lets it tell current from replaced, find the docs that are lying, and admit when it does not know.

Next up are real connectors with webhooks instead of exported files, permissions that travel with every record so people only see what they are allowed to see, and a multi-tenant UI on top of the one-graph-per-company support that already exists.