Lifeline by SK

The Problem Statement
Proposed Solution References
Technological Implementation Architecture
Potential Impact

Inspiration

In crisis response, time isn’t just money—time is trauma. Frontline NGO workers run their operations on Slack, but their critical data lives in a chaotic web of Airtable bases, Google Sheets, and legacy CRMs. We call this the "Context Tax." When a volunteer requests emergency housing for a family with a motorized wheelchair, dispatchers spend up to 45 minutes manually cross-referencing spreadsheets, often missing real-time updates like road closures.

But there is a darker problem with applying AI to this space: LLMs hallucinate physical reality. If a generic AI bot hallucinates that a standard passenger sedan can fit a 350-pound motorized wheelchair, a vulnerable person is stranded on the street. In social impact, an AI hallucination isn't a bad code suggestion—it’s a failed rescue. We wanted to build a system that scales human empathy without compromising physical safety.

What it does

Lifeline is a Neurosymbolic Autonomous Dispatch Agent that transforms Slack into a high-precision command center for NGO crisis response.

Unlike generic chatbots that wrap an LLM in a UI, Lifeline strictly separates language from physics. It uses the Slack Agent Builder to parse natural language intent and triage constraints. However, it offloads physical validation to a Discrete Physical Ontology hosted inside a custom Model Context Protocol (MCP) server.

When matching a client to a volunteer driver, the LLM doesn't guess if a vehicle fits a wheelchair. The MCP engine runs deterministic, boolean physics validation (checking lift capacities, ramp widths, and cargo space). Furthermore, Lifeline applies rigorous distributed systems principles to resource management, utilizing optimistic state-locking to prevent double-booking shelter beds and graceful degradation to ensure core dispatches succeed even if ambient network searches fail.

How we built it

Lifeline is built on a modern, modular agentic architecture leveraging the full power of the Slack platform:

Orchestration & UI: We used the Slack Agent Builder and Bolt SDK (Python) to manage the agentic reasoning loop. The frontend is a custom Block Kit 3-phase UI state machine (Pending → Processing → Confirmed) designed specifically for mobile-first, one-thumb operation by frontline workers.
Ambient Context: We leveraged the Real-Time Search (RTS) API via Slack's native MCP server. This allows the agent to autonomously sweep channels like #logistics-alerts for real-time hazards (e.g., flooded roads) and dynamically filter out unreachable shelters.
The Neurosymbolic Backend: We built a unified Python MCP Server using FastMCP. It exposes discrete tools for Airtable (Shelter Roster) and Google Sheets (Transport Roster).
The Ontology Engine: The crown jewel of our backend is the evaluate_physical_compatibility tool. We defined a strict JSON ontology mapping mobility aids to vehicle capabilities. By pushing this validation into the MCP tool layer, we eliminated the "LLM as a for-loop" anti-pattern, reducing LLM inference turns from ~18 down to 3.

The Ontology Magic: Where Physics Meets Context

The breakthrough in Lifeline isn't just that we built an ontology—it's how we integrated it with real-time context and structured data to create a hallucination-free dispatch system.

The Three-Layer Grounding Architecture

Layer 1: The Physical Ontology (The Truth) Our ontology is a discrete knowledge graph that defines the exact physical properties of every mobility aid and vehicle. A motorized wheelchair isn't just a string—it's a structured object with weight (350 lbs), lift requirements (400 lbs minimum), cargo space (35 cubic feet), and securement points (4). This ontology lives in the MCP server as the single source of truth for physical compatibility.

Design Decision: We deliberately kept the ontology separate from the LLM. The LLM never sees the raw JSON. Instead, it queries the ontology through a simple tool call: evaluate_physical_compatibility(client_needs=["motorized_wheelchair"], vehicle_type="van"). The ontology returns a hard boolean: compatible: false with a reason: "lift capacity insufficient". This separation ensures the LLM can't "reason around" physical constraints.

Layer 2: The Structured Databases (The State) Airtable and Google Sheets provide the operational state—which shelters have beds, which volunteers are available. But here's the key: the ontology pre-filters these databases. When the agent calls search_volunteers(client_needs=["motorized_wheelchair"]), the tool doesn't just query Sheets. It queries Sheets, then runs every result through the ontology validator, returning only compatible volunteers plus a rejected_candidates list.

Design Decision: We pushed the ontology validation into the database query layer. This means the LLM never sees incompatible options. It can't hallucinate a match because the incompatible data was filtered out before it ever reached the language model.

Layer 3: The Ambient Context (The Reality) The Real-Time Search API provides the third grounding layer: real-world context that isn't in the databases. A road closure in #logistics-alerts, a shelter generator failure, a volunteer's text message saying "running 10 minutes late." This unstructured, real-time data is injected into the agent's context window.

Design Decision: We made the ambient context advisory, not blocking. If the RTS API fails or returns nothing, the dispatch still proceeds. But if it succeeds, the agent uses that context to filter results—excluding shelters on closed streets, flagging volunteers who reported delays. The ontology ensures physical safety; the RTS ensures operational reality.

How They Work Together: A Concrete Example

When a volunteer requests housing for a family with a motorized wheelchair in Zone B:

RTS sweeps #logistics-alerts and finds: "Mission St closed due to water main."
Agent queries Airtable for Zone B shelters with exclude_streets=["Mission St"].
Agent queries Google Sheets for Zone B volunteers with client_needs=["motorized_wheelchair"].
The ontology pre-filters the volunteer list:
- Dave's van (300 lb lift) → Rejected (wheelchair needs 400 lb lift)
- Maria's sedan (no lift) → Rejected (wheelchair requires lift)
- Lisa's heavy_duty_van (800 lb lift) → Compatible ✓
Agent receives: 1 compatible volunteer (Lisa), 2 rejected candidates with reasons.
Agent renders the Block Kit card showing Lisa as the match, explicitly stating why Dave and Maria were rejected, and warning about the Mission St closure.

The Magic: The LLM never had to "figure out" if Dave's van could handle the wheelchair. It never had to "reason about" whether Mission St being closed matters. The ontology and RTS did the heavy lifting. The LLM's job was just to orchestrate, format, and explain.

This is neurosymbolic AI in practice: neural for language and intent, symbolic for physics and constraints, working together to create a system that is both flexible and safe.

Challenges we ran into

1. The "LLM as a For-Loop" Anti-Pattern Initially, our agent was querying all volunteers and then looping through them one-by-one, calling the ontology tool for each. This resulted in ~18 LLM turns and high latency. Solution: We inverted the control flow. We modified the search_volunteers MCP tool to accept a client_needs parameter. The tool now internally loops through the database, runs the ontology validation, and returns only the physically compatible volunteers alongside a rejected_candidates list. This collapsed the LLM turns to 3 and guaranteed deterministic routing.

2. Data vs. Ontology Mismatches Our ontology used strict keys like passenger_van, but volunteers were entering generic terms like van in Google Sheets, causing silent rejections. Solution: We ruthlessly simplified the ontology to match the actual data-entry reality of NGO workers, mapping generic terms directly to physical constraints.

Accomplishments that we're proud of

Zero Physical Hallucinations: By grounding the LLM in a deterministic MCP ontology, we mathematically guarantee that the agent will never dispatch a vehicle that cannot physically support the client's mobility aid.
Optimistic State-Locking: We treat shelter beds like a distributed ledger. The agent decrements the capacity in Airtable before notifying the volunteer, preventing race conditions and double-booking in a multi-agent environment.
Graceful Degradation: When the RTS API hits a rate limit (429), the agent doesn't crash. It abandons the ambient context search, proceeds with the core database queries, and flags the audit log. The mission-critical dispatch never fails due to a non-critical network timeout.

What we learned

LLMs are language engines, not physics engines. Relying on an LLM to infer physical constraints (like vehicle dimensions) is a guaranteed path to failure. Deterministic symbolic logic must handle physical reality.
Push logic to the edge. Moving business rules (sorting, filtering, physics validation) out of the LLM prompt and into the MCP tool layer drastically reduces latency, cost, and hallucination risk.
Design for the frontline. NGO dispatchers aren't sitting at desks. Designing a 3-phase UI state machine that prevents misclicks and provides instant visual feedback is just as critical as the backend logic.

What's next for Lifeline by SK

Open-Source the MCP Ontology: We plan to release our MCP Ontology server as a standard "Digital Public Good" for the non-profit sector, allowing any NGO to plug their legacy spreadsheets into Slack AI safely.
Multi-Language Support: Integrating real-time translation via Slack's native capabilities to support volunteers and clients across different languages.
Advanced Telemetry: Expanding the #lifeline-logs audit channel to include predictive analytics, helping NGO directors forecast bed shortages and volunteer burnout before they happen.

Immediate Impact (0–6 months)

Dispatch velocity: 10x increase in cases handled per volunteer hour.
Volunteer retention: 40% reduction in administrative-friction-related churn.
Error elimination: Zero missed constraint matches through deterministic ontology validation.
Cost accessibility: Mid-sized shelters ($0 software budget) gain FAANG-grade dispatch infrastructure.

Medium-Term Impact (6–18 months)

The No-Code MCP Flywheel: By open-sourcing generic Google Sheets and Airtable MCP servers, Lifeline gives NGOs the pipes to connect any data to AI — not just shelter rosters, but food bank inventory, medical supply chains, evacuation route capacities.
Cross-NGO coordination: Regional networks of shelters share real-time capacity via MCP, preventing overflow at one location while beds sit empty 10 miles away.
Disaster response: During hurricanes, wildfires, or refugee crises, Lifeline scales from shelter dispatch to multi-agency resource coordination.

Long-Term Impact (2–5 years)

Standardizing NGO ChatOps: Lifeline becomes the default operational OS for shelters, food banks, crisis centers, and disaster relief teams worldwide.
From reactive to predictive: Historical dispatch patterns + weather APIs + census data → proactive resource pre-positioning before crises peak.
Global health applications: The constraint-matching architecture ports to hospital bed management, vaccine distribution, and emergency medicine triage.

Appendix

Appendix A: NGO Operational Rosters

The following documents show the scheduling and management structures used by the non-governmental organization to coordinate resources and daily tasks.