Inspiration

I kept noticing the same failure pattern everywhere, not just in crises.

A support team escalates a bug that engineering already fixed last week — nobody told them. A sales rep chases a lead that customer success already flagged as churned. A hospital ward is short on a supply that the ward two floors down has in surplus. Different industries, same root cause: the information existed. It just never reached the person who needed it, in time to matter.

We usually blame this on "poor communication," as if the fix is just telling people to talk more. But the real problem is scale — no human can watch every channel, every workspace, every conversation, and reliably notice the one message that should trigger action somewhere else entirely. That's not a discipline problem. It's a problem that needs an agent, not a reminder.

So I built Coordina — not as a disaster-relief tool first, but as an answer to a much more general question: what if Slack itself could notice what people miss, and act on it before anyone has to ask?

What it does

Coordina is a cross-organization decision intelligence agent that continuously observes multiple connected Slack workspaces in real time, understands what's actually happening, and proactively coordinates a response — all without waiting for a command.

The demo you'll see is built around disaster relief (a hospital, an NGO, a food bank, a volunteer network) because it's a domain where the stakes make the value obvious in seconds. But nothing about the underlying engine is disaster-specific. The same pipeline — observe, classify, score, decide, recommend, coordinate — applies just as directly to:

  • An IT team where an outage report should silently notify the on-call engineer who already has the fix, not wait for someone to escalate
  • A sales org where a churn signal in one channel should reach customer success before the renewal call, not after
  • A supply chain where a shortage at one warehouse should trigger a reallocation from another, automatically

Concretely, Coordina:

  • Observes every message across connected workspaces in real time
  • Classifies incoming needs, offers, and urgent reports using an LLM (Gemini, with automatic Groq fallback — never a single point of failure)
  • Scores every incident with a fully deterministic priority engine — never AI-generated — using live data pulled through MCP servers
  • Recommends an action and asks the LLM to explain only the reasoning in plain English — it never invents the priority number
  • Coordinates proactively, reaching out to the right team before anyone files a ticket or sends a "hey, does anyone know..." message
  • Deduplicates intelligently, so a restated need doesn't spawn noise
  • Always keeps a human in the loop — Coordina recommends, it never acts unilaterally

How I built it

  • Backend: Node.js, Express, @slack/bolt running in Socket Mode — one Bolt app instance per organization, sharing a single service layer
  • MCP: five servers (inventory, shelter, volunteer, logistics, routing) behind one unified client — swapping a mock for a real integration later requires zero changes to the agent itself
  • RTS: an event-driven signal bus with semantic search, used specifically to catch duplicate or restated incidents without polling
  • AI layer: Gemini as the primary model, Groq as an automatic fallback, with a hard architectural line between "the AI explains" and "the engine decides"
  • Frontend: React, Vite, Tailwind, shadcn/ui, Recharts, live-updated over Socket.IO
  • Actually deployed: Render, Vercel, and a live MySQL instance — this isn't a localhost demo

Challenges I ran into

The hardest bugs weren't in my code — they were in assumptions I didn't know I was making. Both Gemini and Groq's models spend tokens "thinking" before answering, silently eating the same budget as the visible response, so my AI explanations were quietly getting truncated or emptied out for days before I found it. A known bug in Slack's own socket-mode library could crash the entire agent on a routine reconnect. My free-tier database didn't support the JSON column type at all, and only allowed one auto-timestamping column per table — both very old MySQL limitations I'd genuinely never hit before.

None of these were "hard" problems in the algorithmic sense. They were the kind of problem you only find by actually shipping something and watching it run in the real world instead of a demo environment — which is exactly why I made sure this was live, not just recorded.

What I learned

The interesting engineering in an "AI agent" isn't the AI call. It's everywhere around it — a scoring system that's auditable instead of a black box, a fallback path so one provider's rate limit doesn't take the whole thing down, and an architecture that keeps the model in an advisory role no matter how tempting it is to let it do more. The AI explains. It never decides. That boundary is the whole point.

What's next

Replacing the mock MCP servers with real integrations — hospital inventory systems, support ticketing platforms, CRM data — and building out the enterprise-facing version of this: the same engine, pointed at IT, sales, or supply chain workspaces instead of relief organizations. The disaster-relief demo proved the concept works when it matters most. The next version proves it works everywhere else, every day. "The organizations may change. The coordination engine doesn't."

Built With

Share this project:

Updates