Inspiration
Institutional knowledge loss is a quiet crisis in modern organizations. The "bus factor" is real: when a key team member leaves, goes on leave, or changes roles, teams spend days reconstructing "why a system was built this way," "what caused that past outage," or "who is the actual expert here."
Critical information sits scattered across Slack DMs, GitHub PRs, Jira tickets, and Google Drive docs. We wanted to build an agent that sits directly in the tool teams already use—Slack—and connects these fragmented endpoints into a single, living memory. Helix AI was inspired by the dream of making organizational truth findable, citable, and actionable in seconds.
What it does
Helix AI is a Slack-native intelligence agent that transforms corporate knowledge into a queryable enterprise graph.
- Ask in Slack: Users mention
@Helix AIor DM the bot to ask natural-language questions (e.g., "What caused the Acme outage?"). - Structured Briefs: Instead of a raw chat dump, Helix returns a structured card in Slack Block Kit featuring a Summary, a chronological Root-Cause Timeline, Cited Evidence (with source links), and Actionable Recommendations.
- What-If Simulations: Teams can run capacity risk scenarios (e.g., "What if Alex leaves?"). Helix queries the graph to calculate sprint delays, identify single points of failure (bus-factor risks), and suggest cross-training mitigations.
- Failsafe Integrity: Every claim is tied to real data. If no evidence is found in the databases, Helix refuses to make up a story and fails closed, establishing corporate trust.
How we built it
We architected Helix AI as a modular, containerized monorepo built for high performance and strict data isolation:
- Slack Agent (Interface): Built using Node.js and the Slack Bolt framework, communicating via Socket Mode for instant event acknowledgment and utilizing interactive Block Kit designs.
- FastAPI Backend (Core Orchestrator): A Python FastAPI application that coordinates intent recognition, entity extraction, and query synthesis.
- Databases (Dual-Plane Storage): PostgreSQL (hosted on Supabase) handles tenancy and session states, while Neo4j stores the semantic organizational graph (mapping relationships between People ↔ PRs ↔ Incidents ↔ Customers).
- AI Engine (Brain): Powered by Google Gemini (using
gemini-2.5-flash) for natural-language intent parsing, NER, and reasoning over retrieved graph context. - Integrations (MCP Connectors): Utilizes the Model Context Protocol (MCP) to fetch real-time context from GitHub, Jira, and Google Workspace without putting heavy integration logic into Slack handlers.
Challenges we ran into
- The 3-Second Slack Timeout: Slack requires HTTP request acknowledgments within 3 seconds, but searching a large graph and calling an LLM takes longer. We solved this by immediately acknowledging incoming events and pushing the processing queue to an asynchronous background worker loop.
- Parent Path Resolution in Docker: When containerizing the app, relative file paths that worked locally broke inside Docker. Specifically, Python's path resolver encountered
IndexErrorwhen finding migrations. We rewrote this to dynamically evaluate file paths using safe try-except blocks. - Strict Block Kit Formatting: Mapping LLM reasoning outputs to rigid Slack Block Kit JSON objects was challenging. We solved this by building strong schema decorators on the API backend to validate and parse Gemini's outputs before sending them back to Slack.
Accomplishments that we're proud of
- Living Simulation Engine: Building a scenario planner that parses a team member's graph ownership signal and outputs mathematically grounded project risk metrics.
- Unified Docker-Compose Stack: Creating a single, highly optimized multi-stage build that spins up Postgres, Neo4j, the FastAPI backend, and the Node.js Slack Agent on a live Google Cloud VM with one command.
- Failsafe Design: Creating a hybrid search pipeline that forces Gemini to cite database-backed evidence, completely eliminating the LLM hallucination problem for enterprise search.
What we learned
- MCP Protocol Power: We learned how powerful the Model Context Protocol is for building extensible agents, keeping our external integrations lightweight and modular.
- Neo4j + Vector Fusion: Combining graph database traversal with dense vector search yields much more contextually accurate results than traditional semantic search alone.
- Socket Mode Scaling: Understood the operational requirements of deploying WebSocket-based Slack agents to production GCP Compute Engine environments.
What's next for Helix AI
- Active Graph Ingestion: Automatically extracting semantic relationships from ongoing Slack threads (e.g., matching a thread to a Jira issue) and proposing graph edits to admins.
- Local MCP Server Integrations: Allowing local development teams to connect their local IDE workspaces to the organizational knowledge graph.
- Enterprise Multi-Tenancy: Expanding Postgres partition layers to support secure search across multiple enterprise workspaces.
Built With
- alembic
- cypher
- docker
- docker-compose
- fastapi
- gemini-api
- git
- github
- github-api
- google-calendar-api
- google-cloud
- google-compute-engine
- google-drive-api
- javascript
- jira-api
- model-context-protocol
- neo4j
- node.js
- postgresql
- python
- slack-api
- slack-bolt
- supabase
- typescript
- uvicorn
Log in or sign up for Devpost to join the conversation.