{"slug": "when-the-event-bus-fails-building-company-brain-with-falkordb", "title": "When the Event Bus Fails: Building Company Brain with FalkorDB", "summary": "Team Terminator built Company Brain, a FalkorDB-powered knowledge graph application for a fictional company, Nimbus Labs, that answers cross-system questions such as what breaks when the event bus fails by traversing dependency paths rather than retrieving isolated documents. The Streamlit app exposes the Cypher queries and graph evidence behind each answer, and its incident-response workflow writes new tickets into the graph so later agent responses reflect the change. The project, built for the Graph Hacks hackathon by WeMakeDevs and FalkorDB, uses synthetic data and a managed FalkorDB Cloud graph.", "body_md": "The event bus is down at Nimbus Labs.\n\nThat one sentence starts a chain of questions that a normal chatbot cannot safely answer from a few retrieved documents:\n\nWe 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.\n\nOne product demonstrates all three hackathon tracks:\n\nRepository: [github.com/Swaroop29/company-brain](https://github.com/Swaroop29/company-brain)\n\n**Live demo:** [terminatorcompanybrain.streamlit.app](https://terminatorcompanybrain.streamlit.app/)\n\n**Watch the complete walkthrough:** [Company Brain: FalkorDB Graph Hacks Demo](https://app.trupeer.ai/view/GQXOsufUc/company-brain-falkor-db-graph-hacks-demo)\n\nThe 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.\n\nCompany 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.\n\nFalkorDB 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.\n\nIf FalkorDB is removed, the core workflow disappears:\n\nThat made the graph a natural fit for the project: the answer is not just a record. It is the route between records.\n\nOur main demo starts with a failure in event-bus.\n\nThe user asks:\n\nWhat breaks if the event bus goes down?\n\nCompany 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.\n\nThe core traversal is deliberately small and readable:\n\n``` php\nMATCH p=(x:System)-[:DEPENDS_ON*1..4]->(s:System)\nWHERE s.name = $n\nRETURN x.name, length(p), p\n```\n\nThat path is the explanation. The LLM writes the response, but FalkorDB supplies the connected facts behind it.\n\nThe same impact analysis drives the **Respond to a system incident** workflow.\n\nThat 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.\n\n```\nBefore: event-bus → dependencies, owners, projects, existing tickets\nAction: create Ticket + AFFECTS + ASSIGNED_TO\nAfter:  event-bus → dependencies, owners, projects, existing tickets + new ticket\n```\n\nNimbus Labs is synthetic, but its connections mirror the questions teams ask every day.\n\n``` php\n(Person)-[:MEMBER_OF]->(Team)-[:OWNS]->(System)-[:DEPENDS_ON]->(System)\n(Person)-[:LEADS]->(Project)-[:USES]->(System)\n(Person)-[:AUTHORED]->(Document)-[:ABOUT]->(System|Project)\n(Ticket)-[:ASSIGNED_TO]->(Person)\n(Ticket)-[:AFFECTS]->(System)\n(Person)-[:POSTED]->(Message)-[:MENTIONS]->(System|Project)\n(Decision)-[:DECIDED_BY]->(Person)\n(Decision)-[:CONCERNS]->(System|Project)\n(Decision)-[:SOURCED_FROM]->(Document|Ticket|Message)\n```\n\nThis lets Company Brain answer questions that require more than a keyword match:\n\n| Question | Graph work | \n|---|---|\n| Why did we move from RabbitMQ to Kafka? | Follow a decision to the records that sourced it and to the decision it superseded. | \n| Who knows how to rotate signing keys? | Find people connected to operational documents, tickets, decisions, and messages; identify whether they are still active. | \n| What breaks if event-bus goes down? | Traverse dependency paths, then find affected projects, owners, and tickets. | \n| How is Dana connected to payments-service? | Run a shortest-path query. | \n| Which systems are most critical? | Run PageRank over the dependency graph. | \n\nThe 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.\n\nKnowledge is only useful if it changes with the company. Company Brain has two update workflows:\n\nFor example, an imported ticket immediately becomes part of later impact analysis:\n\n```\n[\n  {\n    \"type\": \"Ticket\",\n    \"id\": \"T-200\",\n    \"title\": \"Event bus outage\",\n    \"status\": \"open\",\n    \"assignee\": \"Priya Nair\",\n    \"created\": \"2026-10-17\",\n    \"affects\": [\"event-bus\"]\n  }\n]\n```\n\nThis is a small feature with a useful consequence: the graph stays a working model of the company rather than a static seed dataset.\n\nAn 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.\n\nThe **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.\n\nThe **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.\n\n``` php\n(Incident)-[:CONCERNS]->(System)\n(Incident)-[:HAS_TICKET]->(Ticket)\n(Agent)-[:WROTE]->(Memory)-[:ABOUT]->(Incident)\n(Agent)-[:HANDED_OFF]->(Handoff)-[:FOR_INCIDENT]->(Incident)\n(Handoff)-[:TO]->(Agent)\n```\n\nThe 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.\n\nThe 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.\n\nThe server exposes incident tools including:\n\nThat 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.\n\nThe hard part was not rendering a graph. It was making every workflow prove that the graph did real work.\n\nWe 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.\n\nThat led to a simple design rule:\n\nThe LLM can explain and choose tools. FalkorDB holds the connected facts, the evidence path, the memory, and the resulting action.\n\n```\n# Start FalkorDB\ndocker run -d --name falkordb -p 6379:6379 -p 3000:3000   -v falkordb_data:/var/lib/falkordb/data falkordb/falkordb:latest\n\n# Create the Python environment\npython -m venv .venv\n.venv\\Scripts\\Activate.ps1\npython -m pip install -r requirements.txt\n\n# Add GROQ_API_KEY or GEMINI_API_KEY to .env\nstreamlit run app.py\n```\n\nFalkorDB Browser runs at [http://localhost:3000](http://localhost:3000) and the application uses the graph named companybrain.\n\nCompany 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.", "url": "https://wpnews.pro/news/when-the-event-bus-fails-building-company-brain-with-falkordb", "canonical_source": "https://dev.to/swaroop_patil_d9a2f9cb9de/when-the-event-bus-fails-building-company-brain-with-falkordb-21fm", "published_at": "2026-10-18 18:11:21+00:00", "updated_at": "2026-10-18 18:17:30.644536+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["FalkorDB", "Company Brain", "Nimbus Labs", "Team Terminator", "WeMakeDevs", "Streamlit", "Graph Hacks", "Swaroop29"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/when-the-event-bus-fails-building-company-brain-with-falkordb", "markdown": "https://wpnews.pro/news/when-the-event-bus-fails-building-company-brain-with-falkordb.md", "text": "https://wpnews.pro/news/when-the-event-bus-fails-building-company-brain-with-falkordb.txt", "jsonld": "https://wpnews.pro/news/when-the-event-bus-fails-building-company-brain-with-falkordb.jsonld"}}