The event bus is down at Nimbus Labs.
That one sentence starts a chain of questions that a normal chatbot cannot safely answer from a few retrieved documents:
We built Company Brain to answer those questions from connected evidence instead of assumptions. It is a FalkorDB-powered knowledge graph for a fictional company, Nimbus Labs, built by Team Terminator for Graph Hacks by WeMakeDevs and FalkorDB.
One product demonstrates all three hackathon tracks:
Repository: github.com/Swaroop29/company-brain
Live demo: terminatorcompanybrain.streamlit.app
Watch the complete walkthrough: Company Brain: FalkorDB Graph Hacks Demo
The live application runs on Streamlit Community Cloud with a managed FalkorDB Cloud graph. All Nimbus Labs records are synthetic, and the graph is seeded automatically when the Cloud graph is empty.
Company knowledge is rarely in one place. A system has an owner, dependencies, documents, historic decisions, messages, projects that use it, and tickets that affect it. An answer such as “What breaks if the event bus goes down?” depends on following those relationships.
FalkorDB is not a visual layer placed on top of another database. It is where Company Brain finds facts, stores updates, records incident memory, and writes the tickets that affect later answers.
If FalkorDB is removed, the core workflow disappears:
That made the graph a natural fit for the project: the answer is not just a record. It is the route between records.
Our main demo starts with a failure in event-bus.
The user asks:
What breaks if the event bus goes down?
Company Brain follows dependency paths in FalkorDB and returns the affected systems, projects using them, owning teams, active people, and existing open tickets. The chat response also exposes the graph evidence and Cypher used to reach the answer.
The core traversal is deliberately small and readable:
MATCH p=(x:System)-[:DEPENDS_ON*1..4]->(s:System)
WHERE s.name = $n
RETURN x.name, length(p), p
That path is the explanation. The LLM writes the response, but FalkorDB supplies the connected facts behind it.
The same impact analysis drives the Respond to a system incident workflow.
That final step matters most. The application does not merely describe an incident. It changes the graph, and the changed graph changes what the agent can say next.
Before: event-bus → dependencies, owners, projects, existing tickets
Action: create Ticket + AFFECTS + ASSIGNED_TO
After: event-bus → dependencies, owners, projects, existing tickets + new ticket
Nimbus Labs is synthetic, but its connections mirror the questions teams ask every day.
(Person)-[:MEMBER_OF]->(Team)-[:OWNS]->(System)-[:DEPENDS_ON]->(System)
(Person)-[:LEADS]->(Project)-[:USES]->(System)
(Person)-[:AUTHORED]->(Document)-[:ABOUT]->(System|Project)
(Ticket)-[:ASSIGNED_TO]->(Person)
(Ticket)-[:AFFECTS]->(System)
(Person)-[:POSTED]->(Message)-[:MENTIONS]->(System|Project)
(Decision)-[:DECIDED_BY]->(Person)
(Decision)-[:CONCERNS]->(System|Project)
(Decision)-[:SOURCED_FROM]->(Document|Ticket|Message)
This lets Company Brain answer questions that require more than a keyword match:
| Question | Graph work |
|---|---|
| Why did we move from RabbitMQ to Kafka? | Follow a decision to the records that sourced it and to the decision it superseded. |
| Who knows how to rotate signing keys? | Find people connected to operational documents, tickets, decisions, and messages; identify whether they are still active. |
| What breaks if event-bus goes down? | Traverse dependency paths, then find affected projects, owners, and tickets. |
| How is Dana connected to payments-service? | Run a shortest-path query. |
| Which systems are most critical? | Run PageRank over the dependency graph. |
The application also handles questions beyond its suggested examples. When appropriate, the agent can build one validated, read-only MATCH query for a count, filter, grouping, or list. Data-changing or unsafe clauses are rejected, and the generated Cypher is shown as evidence.
Knowledge is only useful if it changes with the company. Company Brain has two update workflows:
For example, an imported ticket immediately becomes part of later impact analysis:
[
{
"type": "Ticket",
"id": "T-200",
"title": "Event bus outage",
"status": "open",
"assignee": "Priya Nair",
"created": "2026-10-17",
"affects": ["event-bus"]
}
]
This is a small feature with a useful consequence: the graph stays a working model of the company rather than a static seed dataset.
An incident often moves between people, shifts, or tools. A chat transcript is weak shared memory because it lives with one conversation. Company Brain stores the incident state itself in FalkorDB.
The Incident Investigator has one job: inspect graph-derived impact evidence, write a concise report, and save that report as a Memory node connected to the incident.
The Response Coordinator has a different job: read the saved incident memory and handoff, check current ownership context, decide on the recovery follow-up, and create the linked ticket.
(Incident)-[:CONCERNS]->(System)
(Incident)-[:HAS_TICKET]->(Ticket)
(Agent)-[:WROTE]->(Memory)-[:ABOUT]->(Incident)
(Agent)-[:HANDED_OFF]->(Handoff)-[:FOR_INCIDENT]->(Incident)
(Handoff)-[:TO]->(Agent)
The important boundary is visible in the demo: the Coordinator does not depend on the Investigator's browser chat history. It reads stored incident context from FalkorDB. Reload the page, start again, or use a different compatible client: the memory and handoff remain available.
The Streamlit application is the interface people see, but the incident capabilities are also exposed through an MCP server. MCP, or Model Context Protocol, gives another AI client a standard way to use the same graph-backed operations.
The server exposes incident tools including:
That means the graph workflow is not tied to one UI. An MCP-compatible client can investigate a system, read the shared memory, hand work to another role, and create a follow-up ticket through the same FalkorDB context.
The hard part was not rendering a graph. It was making every workflow prove that the graph did real work.
We had to keep the answer grounded, make graph evidence understandable in the chat, and ensure that an action persisted into later reasoning. The incident demo became our test: if the new ticket did not appear after the write, or the Coordinator could continue without reading saved context, then FalkorDB would not be carrying enough of the product.
That led to a simple design rule:
The LLM can explain and choose tools. FalkorDB holds the connected facts, the evidence path, the memory, and the resulting action.
docker run -d --name falkordb -p 6379:6379 -p 3000:3000 -v falkordb_data:/var/lib/falkordb/data falkordb/falkordb:latest
python -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt
streamlit run app.py
FalkorDB Browser runs at http://localhost:3000 and the application uses the graph named companybrain.
Company Brain does not use FalkorDB to decorate an AI answer. FalkorDB is where the answer is found, where the incident is remembered, and where the next agent picks up the work.