Inspiration
Every engineering team loses hours to the same ritual. A new engineer, or a tired one, needs to know how a system works, who owns a file, or what a change might break, and the only real source of truth is a senior developer's memory. That knowledge is scattered across code, pull requests, and docs in five different tools. We wanted the answers to live where the work already happens: in Slack. And with the Model Context Protocol emerging as the standard way agents talk to tools, we saw a chance to expose a team's entire code knowledge graph through one protocol and let both IDEs and Slack ask it anything.
What it does
Ask Oynix lets anyone @mention a bot in Slack and get an answer grounded in their organization's actual codebase and connected docs, with file-level citations and a confidence score. Ask "how does record authentication work?", "who owns this file?", or "what would break if this API changed?" and get a cited answer in seconds, across every repo the team has indexed, not just the ones you wrote yourself. It reads from code and from connectors like Notion, Jira, and Confluence, so it answers questions that span code and documentation, not just one or the other.
How we built it
Oynix indexes a team's repositories and connected docs into a knowledge graph. We expose that graph as a Model Context Protocol (MCP) server: 18 JSON-RPC tools including ownership, cross-repo blast radius, change impact, decision search, and module wikis, which IDEs like Cursor and Claude connect to directly. The Slack agent is a second client on the same graph. It runs over Socket Mode, so it dials out to Slack and needs no public URL and no inbound hosting. A mention becomes a query against the graph, an LLM synthesizes a grounded answer from the retrieved nodes, and the bot posts it back in-thread with citations and a rendered architecture diagram when relevant. The bot authenticates as a team-scoped service identity, so it answers org-wide no matter who indexed a given repo.
Challenges we ran into
- Grounding, not guessing. Getting an LLM to talk about code is easy. Getting it to only say things the graph actually supports is hard. We leaned on retrieval plus citations so every answer points at real files with a confidence band.
- One graph, two front doors. Making the same knowledge serve an IDE over MCP and humans in Slack meant designing a tool layer that neither surface is special to, instead of building two separate answer engines.
- Socket Mode gotchas. A stray second bot process holds a duplicate websocket, and Slack round-robins events between the two, so replies silently drop. We learned to guarantee exactly one live connection.
- Diagrams that actually read. Rendered diagrams came back on transparent backgrounds that vanished on Slack's dark theme, so we composite them onto a white canvas before uploading them in-thread.
Accomplishments that we're proud of
Real answers over a real, multi-repo codebase, not a demo stub. A single mention returns a grounded, cited explanation in about thirty seconds, and the same knowledge graph powers an IDE through MCP and Slack through the bot with no duplicated logic. Because it runs over Socket Mode inside the team's own infrastructure, nothing sensitive has to leave their stack.
What we learned
MCP turned out to be a genuinely good abstraction for this. Once the graph was a set of MCP tools, adding Slack as a client was mostly plumbing, not a second brain. We also relearned that trust is the product: an answer with a citation and a confidence score is worth ten confident guesses, and it is what makes people actually keep asking.
What's next for Ask Oynix
Deeper connector coverage, so one mention answers across code, tickets, docs, and incidents in a single reply. Proactive answers on pull requests, surfacing who should review a change and what it touches across repos before it merges. And a hosted option, so a team can add the agent without running anything themselves.
Log in or sign up for Devpost to join the conversation.