-
-
The continuity workspace defined!
Inspiration
Continuity began with my experience of moving to college. For the first time, I had to manage important needs such as food, medicine, accommodation, and day-to-day support in a new environment. I realised how strongly a disruption in even one of these services could affect a person’s health, studies, safety, and ability to continue normally.
That experience made me think about people who depend on humanitarian services and have far less control over the support available to them. A child may depend on a school meal provider, a patient may rely on regular medicine delivery, and a displaced family may depend on shelter, healthcare, or relief supplies. If the organisation delivering that support faces a stockout, funding cut, staff shortage, access restriction, or withdrawal, the people receiving the service may have no immediate alternative.
Real humanitarian emergencies show why early warning and coordinated action matter.
During Somalia’s 2010–2012 famine, warning signs existed before famine was officially declared. FAO reports that approximately 250,000 people died between October 2010 and April 2012, and later humanitarian analysis emphasised that many deaths occurred before the formal famine declaration. The danger was not completely invisible; the challenge was converting warning information into sufficiently early and effective action.
A more recent service-level example occurred in Afghanistan. As of 27 May 2025, WHO reported that 422 health facilities had been suspended or closed because of funding termination, affecting approximately 3.08 million people across 30 provinces. The disruption reduced access to essential healthcare, particularly for women and children.
In March 2025, the World Food Programme also warned that funding shortages would force it to suspend food and nutrition assistance for 2 million crisis-affected people across the Central Sahel and Nigeria, including refugees, displaced people, and vulnerable food-insecure families.
These crises are much larger than any software tool can solve. Continuity cannot create missing funding, reopen blocked roads, end conflict, or prevent a national famine.
However, the same warning-and-handoff problem also appears at the operational level:
- A field worker reports that food stocks are nearly exhausted.
- A provider says that its funding ends next month.
- A clinic reports that staff can no longer reach a community.
- A logistics team reports that a road is blocked.
- Another organisation mentions that it has spare capacity.
These messages may appear in separate Slack channels and look like routine updates when viewed individually. Together, they may show that an essential service is about to stop.
Continuity was built to connect those warning signs earlier and help teams act on them. It turns scattered Slack messages into an evidence-backed case, helps identify an approved backup provider, routes the handoff for human approval, and tracks whether the replacement accepts and the service continues.
What it does
Continuity is a Slack-native service-continuity agent for humanitarian, nonprofit, and service-delivery teams.
It monitors selected Slack channels and identifies messages suggesting that an NGO, local team, or existing provider may no longer be able to continue delivering an essential service.
Continuity looks for risks such as:
- stockouts and supply shortages
- funding cuts or expiring grants
- staffing shortages
- provider withdrawal
- blocked roads or access restrictions
- security incidents or conflict
- disaster-related disruption
- transport and logistics problems
- and many other issues
When Continuity detects a possible risk, it:
- Creates a structured continuity case.
- Collects the Slack messages supporting the warning.
- Identifies the service, location, provider, affected group, and deadline.
- Classifies the type and urgency of the risk.
- Searches the workspace for related evidence.
- Suggests an approved backup provider.
- Checks whether the handoff information is complete.
- Routes the proposed handoff to a human approver.
- Contacts the selected provider after approval.
- Tracks whether the provider accepts, requests more information, or declines.
- Allows a coordinator to confirm whether the service resumed.
- Updates the dashboard and impact information.
Continuity can support services such as:
- school feeding
- medicine distribution
- maternal healthcare
- community and mobile clinics
- shelter support
- nutrition programmes
- water and sanitation
- emergency logistics
- relief distribution
- and many more
The app also includes:
- provider registration
- detection of providers mentioned across chats
- detected-provider candidate review
- monitored-channel configuration
- role-based App Home views
- Assistant prompts
- case and provider search
- approval history
- provider-response tracking
- impact reporting
Continuity also includes an external risk watch. It monitors selected locations for emerging disasters, conflict, access disruption, and supply risks, then alerts coordinators so they can investigate whether services in those areas require additional support. This enables risk detection beyond messages and based on real-life data.
External context can strengthen an investigation, but it does not create a case by itself without service-related evidence.
How we built it
Continuity is built as a Slack-native application using Slack Bolt as the main workflow engine.
The user experience uses:
- Slack message events
- slash commands
- Block Kit cards
- interactive buttons
- modals
- App Home
- the Slack Assistant panel
The workflow remains inside Slack, where coordinators already discuss field conditions, providers, deadlines, and operational problems.
Slack Agent and Assistant
Continuity uses Slack Agent and Assistant surfaces through:
- Assistant prompts
- App Home dashboards
- interactive actions
- message-driven workflows
- Slack-native cards and responses
Example Assistant prompts include:
- Show open cases
- Investigate this risk
- Find a replacement provider
- Summarise this channel for service risks
Three-stage detection pipeline
Continuity uses a three-stage NLP pipeline.
1. Risk detector
Determines whether a Slack message represents a genuine service-continuity risk or normal operational conversation.
2. Risk-type classifier
Classifies the issue as a stockout, funding gap, staffing shortage, provider gap, access disruption, security risk, logistics issue, or another continuity threat.
3. Entity extractor
Extracts important details such as:
- service
- location
- current provider
- affected group
- deadline
The detection pipeline is supported by:
- confidence thresholds
- duplicate filtering
- cooldown periods
- snooze controls
- crisis keywords
- “not a risk” feedback
These safeguards reduce repeated or unnecessary alerts.
Real-Time Search API
Continuity uses Slack’s Real-Time Search API.
When a coordinator investigates a risk, Continuity retrieves related Slack evidence, including:
- relevant messages
- source channels
- timestamps
- original-message links
- recent operational context
This allows users to understand not only what Continuity detected, but also why the case was created.
Data and persistence
SQLite stores:
- continuity cases
- detected signals
- providers
- provider candidates
- approvals
- partner responses
- monitored channels
- user roles
- workspace settings
- case events and history
This allows workflow state to survive application restarts and provides a record of how each case progressed.
MCP-ready tool layer
We built an MCP-ready, MCP-like local tool layer containing:
- partner matcher
- handoff-readiness checker
- case tracker
- crisis-context checker
Each tool accepts structured input and returns structured output for use by the workflow.
The current implementation is an MCP-like local tool layer, not yet a complete standards-compliant MCP server. Converting it into a full MCP implementation is part of our next development phase.
Challenges we ran into
Preventing alert fatigue
The earliest versions detected too many messages and repeated alerts for the same situation.
We added:
- monitored-channel controls
- confidence thresholds
- duplicate filtering
- cooldown periods
- snooze actions
- “not a risk” feedback
- stricter risk rules
The goal was to make every alert meaningful rather than reacting to every negative sentence.
Moving beyond detection
Detecting a possible risk was only the beginning.
The harder challenge was building everything that followed:
- evidence collection
- case creation
- provider matching
- handoff preparation
- approval
- provider notification
- response tracking
- service confirmation
This transformed Continuity from a message classifier into a workflow agent.
Verifying providers safely
An organisation mentioned in a Slack conversation should not automatically become an approved operational provider.
We therefore separated:
- provider detection
- candidate review
- provider approval
- capability verification
- contact-route validation
- live handoff use
A provider must be reviewed and have valid routing information before Continuity can use it in a live handoff.
Balancing automation and human control
Continuity can detect, investigate, search, suggest, and organise.
However, it should not independently transfer responsibility for an essential service.
The workflow therefore requires human approval before a replacement provider is contacted.
Maintaining reliability
Hosted AI services can be slow or unavailable.
We designed the core workflow to continue using local models, stored information, rules, and structured templates. Hosted AI may improve summaries, but essential workflow steps do not depend entirely on an external model.
Accomplishments that we're proud of
We are proud that Continuity is not simply a chatbot.
It is a Slack-native workflow agent that moves a real operational process from an early warning to a confirmed service response.
The parts we are most proud of include:
- proactive detection from normal Slack messages
- evidence-backed risk cards
- a three-stage detection pipeline
- Real-Time Search evidence
- service, location, provider, and deadline extraction
- provider registration and candidate review
- approved backup-provider matching
- handoff-readiness checks
- human approval before provider contact
- provider accept, information-request, and decline actions
- persistent case history in SQLite
- role-based App Home views
- external disruption monitoring
- impact tracking after coverage is confirmed
We are especially proud that Continuity keeps humans in control. It is not an LLM making operational decisions on its own. Instead, people review risks, approve handoffs, and decide escalations, while AI supports them with tasks like detection, summarization, evidence organization, and provider matching.
The agent helps teams identify risks earlier, understand evidence faster, find possible support, and complete handoffs in a structured way. Coordinators and approvers still make the final operational decisions.
What we learned
We learned that building a useful Slack agent is less about making it talk and more about helping it act clearly, reliably, and responsibly.
Detection alone is not enough.
A useful service-continuity system must answer:
- What service is at risk?
- Where is the service delivered?
- Who currently provides it?
- Why might the provider stop?
- When could the interruption happen?
- Who depends on the service?
- What evidence supports the warning?
- Is there an approved replacement?
- Who must authorise the handoff?
- Did the replacement provider accept?
- Did the service actually resume?
Technically, we learned how to combine:
- Slack Agent and Assistant surfaces
- Slack Bolt
- Block Kit
- App Home
- Real-Time Search
- SQLite persistence
- local NLP models
- role-based workflows
- interactive approvals
- tool-style actions
Most importantly, we learned that trust requires transparency.
Users need to understand:
- what Continuity detected
- why it created a case
- what evidence it used
- what action it recommends
- what it has already done
- which decisions still require human approval
What's next for Continuity
The next step is to make Continuity easier to deploy in real humanitarian and nonprofit environments.
Planned improvements include:
- guided onboarding for new organisations
- stronger workspace and role management
- a complete standards-compliant MCP server
- integrations with verified provider directories
- multilingual risk detection
- richer disaster, conflict, and access-risk data
- scheduled continuity briefings
- improved impact and donor reporting
- making it faster by using paid services and better management techniques
- multi-organisation coordination
- live provider-capacity updates
- deadline-based escalation
- support for additional service areas
- Improve multi-message reasoning so Continuity can connect separate Slack messages about shortages, deadlines, and backup providers into one clearer evidence-backed case.
We also want to test Continuity with realistic coordination scenarios and gather feedback from people working in:
- nonprofit operations
- emergency response
- public health
- field logistics
- provider management
- community service delivery
Long term, Continuity could help NGOs, health programmes, school-feeding networks, emergency-response teams, local governments, and community organisations identify service risks earlier and coordinate backup support before vulnerable people lose access to essential services.
Built With
- fastapi
- hugging-face-transformers
- llm
- microsoft-deberta
- model-context-protocol-(mcp)
- natural-language-processing
- ner
- python
- rule-based-operational-tools
- slack-ai-capabilities-&-agent-builder
- slack-app-home
- slack-assistant
- slack-block-kit
- slack-bolt-for-python
- slack-real-time-search-api
- slack-socket-mode
- sqlite
Log in or sign up for Devpost to join the conversation.