SlackOps AI

Thumbnail
Real ownership identification screenshot
Real /slackops summarize screenshot
Real /slackops blockers screenshot
Real Slack engineering Q&A screenshot
Architecture Diagram

Inspiration

Engineering teams rarely have an information problem. They have a context problem.

A failure analysis might live in a document, the latest test result might be buried in Slack, and the person responsible for the next step may have only been mentioned once in a meeting thread. That forces engineers to repeat investigations, search through old conversations, and spend time resolving ownership instead of fixing the issue.

I built SlackOps AI around one question: what would an engineering assistant look like if it worked where teams already coordinate and showed the evidence behind every answer?

The goal was not to build another chatbot. I wanted to build an AI teammate that could find the right context, explain where it came from, and help a team move toward a concrete next step without leaving Slack.

What it does

SlackOps AI is an AI engineering teammate that lives inside Slack.

An engineer can ask:

@SlackOps AI Why is the motor controller failing?

SlackOps AI searches the engineering knowledge base through MCP tools, retrieves the most relevant evidence, and returns a grounded answer with citations and a confidence level.

It also supports several engineering workflows:

/slackops blockers identifies blockers, owner signals, severity, and recommended next steps.
/slackops summarize extracts decisions, unresolved questions, assigned tasks, and deadlines.
Ownership questions such as “Who owns firmware validation?” search Slack conversation evidence and identify the responsible engineer.
Workflow actions create a structured local task proposal with an owner, severity, source, due date, and status.

Every response includes safe Agent Activity metadata. Users can see which MCP tools were called, what evidence was retrieved, and how confident the result is without exposing private chain-of-thought.

The result is less time spent repeating investigations, fewer ownership gaps, and a faster path from technical evidence to action.

How I built it

SlackOps AI is a Node.js application with three main layers.

Slack Bolt application The Slack app handles mentions, /slackops commands, loading states, threaded responses, interactive actions, and Block Kit output.

MCP server The MCP server exposes typed tools for:

search_documents()
answer_engineering_question()
search_slack_history()
summarize_channel()
identify_blockers()
create_task()

AI backend The backend handles document ingestion, retrieval, conversation analysis, citations, confidence scoring, optional OpenAI generation, and task proposals.

Engineering documents are indexed into a lightweight local vector store. SlackOps AI combines semantic similarity with keyword overlap to retrieve the strongest evidence, then uses either optional OpenAI generation or a deterministic local fallback to produce a grounded answer.

For the demo, I created a fictional company called AeroTech Robotics with realistic engineering documents, including architecture notes, hardware specifications, firmware changes, failure analysis, meeting notes, and test reports.

The Slack conversation intelligence uses representative AeroTech messages stored locally. The search_slack_history() MCP tool retrieves those exact messages, which is why ownership and blocker responses can show their supporting evidence. The current MVP does not use Slack’s Real-Time Search API.

Challenges I ran into

One of the hardest parts was making the agent’s behavior visible without exposing chain-of-thought.

A generic loading animation would not be enough, so I created a constrained Agent Activity format that shows observable actions such as:

understanding the request
calling a named MCP tool
retrieving evidence
generating a recommendation

This makes the system easier to trust while keeping the internal reasoning private.

Reliability was another major challenge. A hackathon demo should not fail because an external model API is unavailable, so SlackOps AI can still retrieve evidence and produce grounded responses without an OpenAI key.

I also found that consistency matters more than I expected. The engineering Q&A flow originally exposed more metadata than summaries and blocker analysis. I standardized every main workflow so tools, evidence, confidence, and Agent Activity remain visible across the entire experience.

Accomplishments that I'm proud of

The part I am most proud of is that SlackOps AI does not just answer a question. It shows where the answer came from.

Engineering responses include source citations and confidence. Ownership results reference the exact Slack messages that support them. Blocker analysis includes severity, owner signals, evidence, and a suggested next step.

I am also proud that the project is a working end-to-end system rather than a collection of scripted Slack responses. Slack Bolt calls a real MCP server over stdio, the MCP server invokes reusable backend capabilities, and engineering questions run through an actual ingestion and retrieval pipeline.

The app is also easy to demonstrate locally. A judge can install the dependencies, ingest the engineering documents, and start the environment with one command.

What I learned

The biggest lesson was that trust comes from evidence, not just fluency.

A polished paragraph is not enough for an engineering team. People need to see the source document, the supporting Slack message, the tool that was called, and the confidence behind the result.

I also learned the importance of describing workflow automation honestly. SlackOps AI creates a local task proposal for human approval. It does not claim to create a Jira or Linear task when it does not.

That boundary makes the current MVP more credible and creates a clear path for future integrations.

Finally, I learned that a deterministic local retrieval system can be a strong foundation for an agent. It makes the demo reliable while preserving the same architecture needed for managed embeddings, persistent vector databases, and enterprise knowledge connectors later.

What's next for SlackOps AI

The next step is replacing the local demonstration sources with permission-aware enterprise connectors.

The MCP architecture could support Slack search, GitHub, Jira, Linear, Google Drive, and Confluence without changing the Slack experience itself.

I would also replace the local JSON vector index and in-memory task store with persistent managed services, add workspace-level authorization and audit controls, and connect approved workflow actions to real task systems.

SlackOps AI already demonstrates the core experience today: