Here is the complete project story, formatted neatly in Markdown, tailored for your Devpost submission based on your repository and blog post:


🧠 CompanyMind AI: Autonomous Enterprise Graph Brain & Cross-Agent Shared Memory

💡 Inspiration

Every engineering team has lived this frustration:

"Why did we deprecate the v1 Auth Service, who approved it, and what downstream services break if we shut it down on Monday?"

When that question comes up, nobody can answer it quickly. The reasoning is buried inside an executive Google Meet transcript. The architectural specifications live as an RFC in Google Docs. The commitments are scattered across GitHub issues, and the actual implementation spans multiple PRs. The only entity connecting them all was someone's memory—and that person is currently on holiday.

We built CompanyMind AI to solve this knowledge fragmentation once and for all. Instead of letting tribal knowledge walk out the door, CompanyMind creates a living, queryable knowledge graph of your entire enterprise, powered by a multi-agent workforce that reasons over it and shares persistent memory.


🛠️ How We Built It

We realized early on that traditional vector RAG completely falls apart on structural, multi-hop company questions. Vector search can tell you what text looks "similar," but it cannot follow causal chains, calculate variable-depth blast radiuses, or verify whether a policy constraint was actually approved.

To solve this, we architected the platform around FalkorDB, a high-performance graph database that runs as a Redis module, stores graphs as sparse matrices using GraphBLAS, and is queried via OpenCypher.

  • Core Graph Engine & Schema: We mapped out a rich graph model connecting :Person, :Team, :Meeting, :Doc, :Decision, :Service, :GitHubIssue, and :GitHubPR nodes via relationships like APPROVED, PROPOSES, SUPERSEDES, GOVERNS, OWNS, DEPENDS_ON, and TOUCHES.
  • Multi-Hop Cypher Tools: Instead of forcing the LLM to write raw Cypher from scratch (which leads to hallucinations), we built parameterised tools like service_blast_radius and trace_decision_provenance. Our 4-hop blast radius query traverses service dependencies down to the exact microservices and traces them backward to governing RFCs and meeting decisions.
  • Built-in Graph Algorithms: We exposed FalkorDB's native graph algorithms (CALL algo.*) directly to the agents as tools, enabling PageRank (to find critical service dependencies), betweenness centrality (to spot single points of failure), and community clustering.
  • Shared Multi-Agent Memory: Our agent workforce—consisting of an Orchestrator, Researcher, Governance Watchdog, and Scribe—doesn't pass bloated text transcripts around. Instead, agent findings and hand-offs are stored as :Memory and :Task nodes right inside the company graph, allowing future sessions to recall relevant context instantly.
  • Document Ingestion Engine: Users can upload PDFs, Word documents, Excel sheets, CSVs, and Markdown files through the dedicated workspace view. Files are chunked, stored with full-text indexing, cited in responses, and can be converted into connected graph entities with a single click.
  • Security & Human-in-the-Loop: Tenant isolation is enforced securely via per-tenant namespaces (org_<uid>) derived server-side from verified Firebase ID tokens. Furthermore, any sensitive tool action (like writing data or sending a message via Composio connectors) is queued as an explicit Approval node requiring user confirmation.

🧗 Challenges We Faced

  1. Preventing LLM Query Hallucinations: Asking an LLM to freely write OpenCypher queries often resulted in invalid labels or relationship names. We solved this by enforcing a mandatory schema-lookup step (graph_schema) before tool execution, combined with rigid, parameterised backend queries.
  2. Context Window Bloat in Multi-Agent Workflows: Passing full conversation histories between specialized agents quickly degraded performance. By shifting agent memory and hand-off tasks directly into the FalkorDB graph as structured nodes, we kept token footprints minimal while making agent memory fully auditable and linkable.
  3. Balancing Autonomous Actions with Safety: Allowing AI agents to interact with live developer and workspace tools (GitHub, Google Workspace via Composio) posed safety risks. We implemented a strict security boundary: read-only actions execute automatically, while any write operation fails closed and halts for atomic human approval.

🏆 What We Learned

  • Give models tools, not raw query strings: Parameterised graph tools yield vastly more stable and predictable results than letting models construct complex queries on the fly.
  • Graphs make AI auditable: When an agent answers a question, rendering the traversed graph path visually using Cytoscape.js lets users instantly verify why the AI gave that answer.
  • Co-locating memory with data is powerful: Storing agent episodic, semantic, and procedural memory in the same graph as enterprise assets lets AI reason about who knows what with native contextual awareness.

🚀 Try It Out

Built With

  • api
  • artificial-intelligence
  • automation
  • developer-tools
  • docker
  • document-processing
  • enterprise
  • falkordb
  • firebase
  • fullstack
  • github-api
  • google-workspace
  • graph-database
  • knowledge-graph
  • multi-agent-system
  • natural-language-processing
  • next.js
  • opencypher
  • opensource
  • rag
  • react
  • security
  • tailwind
  • typescript
  • vector-search
Share this project:

Updates

Submission history