Aasha — AI Relief-Operations Agent for Slack

Track: Slack Agent for Good

*Aasha means "hope" *

Inspiration

During the 2024 Bengaluru floods, NGO volunteer groups coordinated through chat — and drowned in it. Hundreds of messages an hour: people trapped, insulin needed, boats offered, roads blocked. Critical calls for help scrolled past unseen. Coordinators didn't lack compassion; they lacked attention. In a disaster, attention is the scarcest resource. Aasha gives it back.

What it does

Aasha is an AI relief-operations agent that lives inside Slack — because in a crisis, nobody installs a new app; responders coordinate where they already are.

  1. Auto-triage — Aasha reads every message in relief channels. When someone cries for help in plain, messy language ("HELP grandmother trapped near koramangala, diabetic, water chest high!!"), the AI extracts type, severity, location, people affected, and needs — and posts a structured incident card in-thread within seconds. The AI is an invisible form-filler: victims never fill a form, coordinators always get structured data.
  2. One-click response — every card has "🙋 I can help" / "✅ Resolved" buttons. Cards update in place (unassigned → in progress → resolved), so there are no duplicate rescues and no "is anyone on this?"
  3. Auto-escalation — life-threatening incidents (trapped, drowning, medical emergencies) trigger an instant DM to the coordinator with a jump-link. Critical calls can never scroll away again.
  4. /sitrep — one command generates a live situation report from the real database: everything open, sorted by severity, ending with the single most urgent unmet need. Written by the AI in seconds; a human would need an hour.
  5. App Home mission control — a live ops dashboard inside Slack itself: open/critical/in-progress/resolved counts and the active incident list.
  6. MCP server — all four operations (log_incident, assign_volunteer, resolve_incident, get_sitrep) are exposed via the Model Context Protocol, so any AI agent ecosystem can plug into the same relief operation.

How we built it

                    ┌─────────────────────────────────────────────┐
                    │              SLACK WORKSPACE                │
                    │  #relief-ops channel · DMs · App Home tab   │
                    └───────────────┬─────────────────────────────┘
                        messages ↓  ↑ cards / DMs / sitreps / home view
                    ┌───────────────┴─────────────────────────────┐
                    │      AASHA AGENT (Node.js + Bolt,           │
                    │             Socket Mode)                    │
                    │                                             │
                    │  brain.js ──── LLM classification &         │
                    │                sitrep generation (GLM)      │
                    │  cards.js ──── Block Kit UI (cards, home)   │
                    │  tools.js ──── incident operations          │
                    │  mcp-server.js─ same tools via MCP (stdio)  │
                    └───────────────┬─────────────────────────────┘
                                    ↓  ↑
                    ┌───────────────┴─────────────────────────────┐
                    │        SUPABASE (Postgres)                  │
                    │  incidents · volunteers · assignments       │
                    └─────────────────────────────────────────────┘
  • Slack Bolt (Socket Mode) — listens to messages, serves buttons, slash command, and App Home.
  • LLM brain — every message is classified into strict JSON (is_incident/type/severity/location/people/needs); non-incidents (chatter, questions) are silently ignored. The same brain writes /sitrep reports from live incident JSON.
  • Supabase (Postgres) — the shared operational state: incidents, volunteers, assignments.
  • MCP server — a stdio Model Context Protocol server wrapping the same tools the Slack agent uses, verified with a real MCP client.

Challenges we ran into

  • The loop-guard bug: filtering message.bot_id to prevent infinite loops also silently dropped legitimate app-posted messages. Fix: compare against the bot's own user ID resolved at startup.
  • Idempotent buttons: double-clicking "I can help" double-assigned incidents. Fix: status guards with ephemeral "already in progress" replies.
  • Keeping the AI honest: strict JSON schema prompting so severity is consistent and chatter is never logged as an incident.

Accomplishments we're proud of

A complete, live-tested relief-operations loop — from a panicked plain-language message to a triaged, escalated, assigned, and resolved incident — without the victim or volunteer ever leaving Slack or filling a form.

What we learned

The best crisis UX is invisible: no forms, no commands, no new apps. AI's job is to impose structure on human chaos quietly, and Slack's job is to put the result where people already are.

What's next for Aasha

Cross-message memory (follow-ups update incidents instead of creating new ones), volunteer skill matching (auto-DM the nearest doctor/boat owner), multi-language triage (Kannada, Hindi, Tamil), and a WhatsApp bridge for victims — coordination stays in Slack, intake widens.

Built with

node.js · slack-bolt · block-kit · model-context-protocol · supabase · postgresql · glm-5.1 · socket-mode

Built With

  • block-kit
  • glm-5.1
  • mcp
  • model-context-protocol
  • node.js
  • postgresql
  • slack-bolt
  • socket-mode
  • supabase
Share this project:

Updates