When the Event Bus Fails: Building Company Brain with FalkorDB

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:

• Which systems depend on it?
• Which projects and teams are affected?
• Who should own the response?
• Is there already an open ticket?
• What did the last investigation discover, and can another agent continue it after a restart?

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:

1. Company Brain: ask grounded questions about people, teams, systems, projects, documents, messages, tickets, and decisions.
2. Agents That Act on Connected Data: investigate a system failure, recommend an owner, and create a follow-up ticket in the graph.
3. Agent Memory and Coordination: let an Investigator save graph-backed incident memory and hand work to a Coordinator who continues from that stored context.

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.

The idea: the graph is the product's working context

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:

• the agent cannot traverse dependencies or ownership,
• it cannot prove why it selected an owner or priority,
• it cannot persist a follow-up ticket,
• and the next agent cannot recover the prior investigation.

That made the graph a natural fit for the project: the answer is not just a record. It is the route between records.

One outage, three graph-powered behaviours

Our main demo starts with a failure in event-bus.

1. Understand the company

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.

2. Turn evidence into an action

The same impact analysis drives the Respond to a system incident workflow.

1. Company Brain traverses DEPENDS_ON and USES relationships.
2. It finds the systems and projects at risk.
3. It looks up the owning team and active people.
4. It recommends an owner and priority from those graph results.
5. The user creates a follow-up ticket.
6. FalkorDB receives a new Ticket node with AFFECTS and ASSIGNED_TO relationships.
7. The impact analysis runs again, and the new ticket now appears in future evidence.

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

The graph model

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.

Keep the company brain current

Knowledge is only useful if it changes with the company. Company Brain has two update workflows:

• Log a decision: save a decision, its rationale, author, related systems or projects, and optionally the earlier decision it replaces.
• Import or update records: upload Document, Ticket, or Message records as JSON. Existing IDs are updated in place rather than duplicated.

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.

Memory that survives the first agent

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.

MCP makes the incident workflow reusable

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:

• analyze_system_impact(system)
• start_investigation(system, summary)
• read_incident_memory(incident_id)
• handoff_to_coordinator(incident_id, note)
• coordinate_followup(incident_id, decision)

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.

What was difficult

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.

Running it locally

# Start FalkorDB
docker run -d --name falkordb -p 6379:6379 -p 3000:3000   -v falkordb_data:/var/lib/falkordb/data falkordb/falkordb:latest

# Create the Python environment
python -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt

# Add GROQ_API_KEY or GEMINI_API_KEY to .env
streamlit run app.py

FalkorDB Browser runs at http://localhost:3000 and the application uses the graph named companybrain.

Try the complete story

1. Ask: What breaks if the event bus goes down?
2. Inspect the graph evidence.
3. Open Respond to a system incident and create the recommended follow-up ticket.
4. Run the impact analysis again and confirm the ticket is now graph evidence.
5. Open Track 2: shared incident memory and handoff to watch Investigator → stored memory → Coordinator → ticket.
6. Use Graph Schema to inspect the ticket or incident that the workflow created.

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.

---