Company Brain: Building an Enterprise Intelligent Knowledge Assistant with Knowledge Graphs and AI Agents

Enterprises accumulate massive amounts of employee profiles, project documents, training records, and internal policies every day, but this information is typically scattered across spreadsheets, databases, and systems in different departments. Finding a single piece of information is often harder than one would imagine. An open-source project called Company Brain attempts to combine "knowledge graphs + expert Agents + LLMs" to turn organizational knowledge into a conversational query assistant. Its architectural choices and the security shortcomings it exposes offer valuable reference for teams looking to deploy enterprise AI assistants.

Five Typical Pain Points in Enterprise Knowledge Retrieval

In the background section, the project author lists common problems in organizational information management: knowledge scattered across multiple files and systems, time-consuming manual record searches, the difficulty of representing relationships between employees and projects/managers/training records in traditional spreadsheets, employees not knowing which system to search for answers, and multi-system switching disrupting workflows. These problems point to the same conclusion—what enterprises lack is not data, but a unified entry point that "connects" data and supports natural language access.

This judgment aligns with the industry consensus on RAG (Retrieval-Augmented Generation) deployment: simply piling up document retrieval tends to produce irrelevant answers, while structured relationships can significantly improve answer accuracy and interpretability.

RAG (Retrieval-Augmented Generation) is a technical paradigm that combines external knowledge retrieval with the generative capabilities of large language models. Its core workflow is: after a user asks a question, the system first retrieves document fragments or structured records relevant to the question from the knowledge base, then feeds this content as context into the LLM, letting the model answer based on this "evidence" rather than relying solely on parameter memory from training. Compared to letting the model "freestyle," RAG can significantly reduce hallucinations and improve answer timeliness and traceability. In practice, the industry has gradually discovered that relying solely on vector similarity to retrieve unstructured documents has limitations—when questions involve relationships between entities (such as "who reports to whom" or "which projects an employee has participated in"), structured knowledge graphs often hit the target more precisely than text chunks. Therefore, "graph + RAG" hybrid retrieval has become an important evolution direction for enterprise knowledge assistants.

Architecture Breakdown: A Six-Step Pipeline from CSV to Conversational Answers

Company Brain's workflow can be divided into six stages:

1. Data Ingestion: Supports CSV formats for employee information, engagement surveys, recruitment records, training data, and project data.
2. Knowledge Graph Construction: The backend writes records into FalkorDB, establishing nodes and edges between employees and managers, projects, training records, and surveys, turning isolated records into an explorable relationship network.
3. Question Routing: After a user asks a question, the system dispatches it based on keyword matching to expert Agents such as People & Teams, Projects, Issues & Telecom, Documents, and Decisions. If no match is found, it is handled by the Generalist.
4. Evidence Retrieval: Relevant records are pulled from the knowledge graph as the data foundation for answers, rather than relying solely on the model's parametric knowledge.
5. Answer Generation: The LLM is called via OpenRouter to generate natural language answers based on the retrieved evidence.
6. Frontend Presentation: A dashboard built with React + TypeScript, including a chat interface, charts, knowledge browser, employee and project pages, search, reports and insights views, and support for voice search, command palette, light/dark themes, and chat history.

Regarding the tech stack, the backend uses Python + FastAPI to provide REST APIs, FalkorDB stores the graph, Supabase optionally stores chat history, Streamlit provides another chat and CSV import interface, and Vite handles frontend builds. Overall, it is a typical three-stage architecture of "graph retrieval + Agent routing + LLM generation."

FalkorDB is an open-source graph database that implements graph queries based on sparse matrices and linear algebra techniques. It is compatible with the Redis protocol and the openCypher query language (the graph query syntax commonly used in the Neo4j ecosystem). It models data as nodes and edges, where nodes can carry properties and edges represent relationships between entities—making it ideal for expressing highly interconnected data such as "employee—manager," "employee—project," and "employee—training record." Compared to relational databases that require multi-table JOINs to reconstruct relationships, graph databases can answer multi-hop queries like "all projects participated in by the subordinates of a certain employee's manager" with a single traversal. In this project, FalkorDB plays the role of converting scattered CSV records into a traversable relationship network and serves as the data foundation for the "evidence retrieval" stage.

What Sets It Apart from Traditional Retrieval

Traditional information systems require users to navigate menus, apply filters, and guess keywords. Company Brain's differentiation lies in the combination of three elements: the knowledge graph organizes relationships, expert Agents route questions to the correct knowledge domain, and the LLM converts retrieval results into easy-to-understand answers.

More critically, evidence is traceable: the backend attaches source and evidence information from graph records to answers, letting users know where the answer comes from. This is particularly important in enterprise scenarios—if answers about HR or project data cannot be traced, they are hard to truly trust.

Current Limitations: Keyword Routing and Open-by-Default Data Permissions

The project documentation, unusually candidly, lists its shortcomings, two of which deserve particular attention:

First, routing is still keyword-based. When users phrase questions differently, matching may fail. The author suggests introducing semantic routing in the future to identify intent more accurately.

Second, there are security risks in the default configuration. The documentation explicitly states that the current optional Supabase chat history policy allows anonymous read/write, which must be tightened before real enterprise data goes live; identity authentication, role-based permissions, and access control should also be added. Enterprise knowledge involves sensitive information such as employee profiles, making this a hard prerequisite before deployment.

Other areas for improvement include: evaluating answer accuracy, relevance, and evidence consistency using a test question set; keeping data fresh through scheduled imports; introducing embedding-based semantic retrieval to handle wording differences; and enhancing analytics capabilities to discover missing information and usage trends. The author emphasizes that these are future directions rather than implemented features.

The distinction between keyword routing and semantic routing is worth elaborating on. Keyword routing relies on whether words from a predefined vocabulary appear in the question to determine intent. It is simple to implement, interpretable, and requires no additional model calls, but it is fragile against synonymous rewording, colloquial expressions, and cross-domain mixed questions—a user saying "who's been mentoring new hires in our group lately" might not match the "training" vocabulary. Semantic routing encodes user questions as vectors and compares them with the responsibility description vectors of each expert Agent, or directly uses an LLM for intent classification, thereby dispatching based on "meaning" rather than "literal text." The cost is introducing embedding models or additional LLM calls, increasing latency and expense, and requiring maintenance of description corpora for each Agent. When transitioning from keyword routing to semantic routing, keywords are usually retained as fallback rules, forming a hybrid routing strategy.

RBAC (Role-Based Access Control) is a common paradigm for enterprise permission models: the system first defines roles (such as HR, project manager, regular employee), then grants roles permissions to operate on specific resources, and users indirectly obtain permissions through assigned roles. Compared to configuring permissions individually for each user (ACL), RBAC is easier to manage and audit. In enterprise knowledge assistant scenarios, RBAC determines "who can see which graph nodes and fields through conversation"—for example, regular employees should not be able to query others' salary or performance records. Deployment typically also requires combining identity authentication (such as SSO/OAuth) with field-level filtering to ensure that permission trimming occurs during the retrieval stage before answer generation, rather than redacting after generation.

Applicable Scenarios and Deployment Recommendations

Based on the data categories the project supports, HR can use it to query employee information, training records, and engagement surveys; project management teams can map out personnel-to-project relationships; recruitment and training data can also be explored through conversation. However, effectiveness depends heavily on the quality, completeness, and accessibility of the data in the graph.

For teams planning to borrow this approach, three practical recommendations: first, validate the pipeline on a small-scale, low-sensitivity data domain before gradually expanding the knowledge domains covered by Agents; treat evidence traceability as an acceptance criterion rather than an add-on feature; and complete the permission model design before connecting real organizational data—do not carry over default policies from the development phase.

Company Brain's value lies not in being a mature enterprise product, but in demonstrating the combination of "graph-organized relationships + Agent domain routing + evidence-driven generation" through a runnable open-source implementation, and honestly marking the distance from demo to production.

One-line Summary

Company Brain combines knowledge graphs with expert Agents and LLMs to turn enterprise knowledge into a conversational query assistant.

Paragraph Summary

Company Brain is an open-source enterprise AI assistant project that addresses the pain point of enterprise knowledge scattered across spreadsheets, databases, and multiple systems by proposing a "knowledge graph + expert Agents + LLMs" combination. Its pipeline goes from CSV import, to writing into FalkorDB to build a relationship network of employees and project entities, to keyword-based routing of questions to expert Agents in various knowledge domains, to evidence retrieval from the graph, to LLM-generated answers via OpenRouter, and finally to presentation in a React dashboard. Its differentiation lies in evidence traceability—answers come with graph sources. The article also candidly points out shortcomings: routing relies solely on keyword matching, and the default Supabase configuration allows anonymous read/write, requiring authentication and RBAC before real data goes live. It is applicable to HR, project management, recruitment, and training scenarios, with effectiveness depending on graph data quality.