REMEMBER

A Slack agent that keeps disaster-response volunteers' institutional memory alive. Surfacing past decisions, flagging stale knowledge, and catching what walks out the door when someone leaves.

Comment

## Inspiration

Disaster response runs on volunteers, and volunteers churn. Every season, the people who knew who holds the Westside shelter keys, what the pet policy is, or whether the backup generator was ever fixed move on, and that knowledge walks out the door with them. The information usually still exists, buried in an old Slack thread, but nobody knows it's there or whether it's still true. When the next hurricane hits, teams re-litigate decisions they already made a year ago. We wanted an agent that treats a team's past conversations as institutional memory: searchable, trustworthy, and self-maintaining, so hard-won knowledge survives turnover.

## What it does

REMEMBER is a Slack agent that preserves institutional memory for disaster-response organizations. It has four capabilities:

  • 🔎 Memory search. @REMEMBER a question (or /remember-search) and it does semantic, in-workspace retrieval over past decision threads via Slack's Real-Time Search API, returning Block Kit cards with the real thread excerpt, the decision's owner, and a link back to the original conversation.
  • 🟢🟡🔴 Freshness scoring. Every decision in the registry is scored GREEN, YELLOW, or RED by how long since it was last verified, so knowledge quietly going stale becomes visible at a glance.
  • 🚨 Orphan monitor. When a volunteer goes inactive, REMEMBER finds the decisions they owned and surfaces them for reassignment before the knowledge is lost.
  • 🌀 Seasonal brief. Every September 1 (and on demand), it auto-posts a hurricane-season protocol review built from last season's actual decisions, so prep starts before the storm does.

A Home-tab dashboard ties it together with a memory-health summary for the operations lead.

## How we built it

TypeScript (strict mode) on Slack Bolt over Socket Mode, with a clean separation the whole codebase enforces: thin handlers that only route, services that hold all business logic, and a dedicated UI layer where every Block Kit card lives. Retrieval is powered by Slack's Real-Time Search API (assistant.search.context), which is semantic, in-workspace search. Airtable backs the volunteer roster and decision registry that drive freshness scoring and the dashboard. Scheduling uses node-cron, structured logging uses pino, and the config layer validates every required environment variable at startup so the app fails loudly rather than mysteriously. 59 Jest unit tests cover the services and UI builders, with every external API mocked.

## Challenges we ran into

  • Attribution across bot-posted history. Slack's RTS tags app-authored messages with a synthetic author id rather than the real user, which broke owner resolution for our seeded demo threads. We had to build a reconciliation step that maps the registry owner to that synthetic id so cards resolve to the right person.
  • Being honest about "AI." Slack's thread-summarization method isn't a live API, so instead of faking a summary we designed the cards around the genuine RTS capability, semantic retrieval, and show the real thread excerpt. Getting the product's story to match what the platform actually does took discipline.
  • Semantic isn't keyword. RTS is semantic, so queries had to be phrased in natural language rather than boolean, which reshaped how the agent prompts and how
    • Semantic isn't keyword. RTS is semantic, so queries had to be phrased in natural language rather than boolean, which reshaped how the agent prompts and how we demo it.
    • Graceful degradation. A response tool for a disaster org can't hard-fail. We built explicit fallbacks: if Airtable is down, search still works and ownership reads "check roster manually"; if RTS is down, users get a clear card pointing them to search Slack directly.

Accomplishments that we're proud of

  • A genuinely agentic use of Slack's newest retrieval API: semantic memory search wired into three distinct features (search, orphan detection, seasonal brief), not a chatbot wrapper.
  • A production-shaped codebase, with strict typing, typed custom errors, structured logging, a validated config boundary, graceful degradation for every dependency, and 59 passing tests.
  • A design that's honest about its capabilities, with no faked AI summaries and care taken about what the platform actually provides.
  • It connects and runs live end-to-end against a real Slack workspace and Airtable base.

What we learned

We learned to build with the grain of a new platform API instead of forcing it to be something it isn't. The strongest version of the product came from leaning into what RTS genuinely does (semantic retrieval) rather than papering over the gaps. We also relearned that for mission-critical tools, error handling and graceful degradation aren't polish; they're the feature. And that a strict, convention-driven codebase pays for itself the moment you're moving fast under a deadline.

What's next for REMEMBER

  • Automatic decision capture. Detect when a thread reaches a decision and offer to log it to the registry, so memory builds itself instead of relying on manual seeding.
  • AI-generated summaries. Swap raw thread excerpts for true summaries once summarization is available as a live capability.
  • Proactive re-verification nudges. DM a decision's owner when it drifts into YELLOW, closing the freshness loop automatically.
  • A live orphan-reassignment flow. Trigger orphan detection automatically on a volunteer's status change and let the team reassign ownership right from the alert.
  • Beyond hurricanes. Generalize the seasonal brief to wildfire, flood, and winter-storm protocols.

Paste into "Built with" (comma-separated tags)

typescript, slack, slack-bolt, slack-api, block-kit, airtable, node.js, node-cron, pino, jest

Two quick notes:

  • The ## Inspiration placeholder in the field is just a prompt — pasting my block (which starts with ## Inspiration) replaces it correctly.
  • Devpost usually also asks for a GitHub/repo link and a video/demo URL in later fields. Your repo is ready: https://github.com/cybort360/remember. The video is the demo recording you're doing from DEMO.md.

Built With

Share this project:

Updates