BridgeLine — Devpost write-up

Inspiration

Accessibility support can fail at the worst possible moment: captions stop working, an interpreter becomes unavailable, or an event location changes without a clear accessible alternative. Teams then scramble across Slack channels, lose valuable time, and risk excluding attendees. We built BridgeLine to turn that stressful, fragmented process into one clear, accountable response flow inside Slack.

What it does

BridgeLine helps event and nonprofit teams respond to urgent accessibility incidents.

A coordinator reports an issue in plain language — for example, "Live captions failed for the 2 PM workshop in Room B." BridgeLine organizes the incident, pulls in relevant Slack context, identifies qualified available support, and presents a human-approved action plan without anyone leaving the thread.

It provides:

• Three natural entry points: the /bridgeline command, a "New BridgeLine incident" message shortcut, and an @mention
• Structured incident intake that asks only for missing facts
• Fresh, live context from the workspace via Slack Real-Time Search
• Qualified provider recommendations with an explainable rationale
• Clear fallback accommodation and escalation options
• One-click assignment, owner notification, and escalation
• Provider accept / decline responses in a direct message
• A no-response safety net that nudges the coordinator and surfaces the next candidate if a provider goes quiet
• A "mark resolved" action that closes the loop once the accommodation is restored
• A visible incident timeline and live status

How we built it

BridgeLine is a Slack-native application built with TypeScript and Slack Bolt, running in Socket Mode.

The interface is built entirely with Slack Block Kit — structured, interactive incident cards instead of long chatbot replies. We built a real Model Context Protocol (MCP) server that exposes the provider roster as typed tools (find_available_providers, get_provider, create_assignment, get_fallback_plan); the app talks to it through an MCP client over stdio, so MCP is load-bearing rather than decorative. Provider qualification, availability, and active status are enforced in deterministic code, so an unqualified or unavailable provider can never be recommended. We use Slack Real-Time Search (assistant.search.context) to bring current workspace context into the response, and when live search isn't available the agent says so plainly instead of inventing context.

The architecture combines:

• Slack Bolt for commands, shortcuts, modals, buttons, events, and direct messages
• Slack Block Kit for the interface
• A custom MCP server + client for provider lookup, fallback plans, and assignments
• Slack Real-Time Search for current event and incident context
• SQLite for incidents, assignments, providers, and an audit timeline
• An always-on deployment on AWS EC2 (Socket Mode) so the agent is testable 24/7

Challenges we ran into

The hardest part was balancing speed with responsibility. Accessibility incidents are urgent, but an agent should never make commitments or expose sensitive information without human approval, so every assignment, notification, and escalation is human-confirmed.

We also worked to make the required technologies genuinely necessary rather than bolted on. Real-Time Search keeps recommendations from relying on a single vague message, and MCP makes provider recommendations actionable. Along the way we learned real platform details the hard way: Real-Time Search calls made with a bot token require an action_token that only arrives with a message or mention event, so we added an @mention entry point to obtain it and made the slash-command path fall back gracefully. We also handled Slack-side details like slash-command registration conflicts, interaction routing, permission scopes, and clean error states.

Accomplishments that we're proud of

We are proud that BridgeLine solves one real, high-impact workflow extremely well instead of being a generic chatbot.

In particular:

• A calm, Slack-native incident experience designed for high-pressure moments
• Human approval before any assignment or notification
• Explainable recommendations with clear reasons, fallback plans, and inline source links
• A resilient workflow: no-response handling and graceful fallback when live search or a provider isn't available
• Privacy-aware behavior that keeps sensitive details out of public channels
• A complete, accountable lifecycle — from report to resolution — with a visible timeline
• A genuinely deployed, always-on agent that judges can test live, not just a local demo

What we learned

We learned that the best agents don't try to do everything — they solve one specific problem exceptionally well. We also learned that good agent design isn't only about model intelligence. Trust comes from clear actions, transparent reasoning, human control, privacy-aware behavior, and graceful handling when the ideal answer isn't available. Making the required technologies meaningful — not decorative — pushed us to design the workflow around real context and real, verifiable capacity.

What's next for BridgeLine

BridgeLine already models multiple accommodation types (live captions, sign-language interpretation, mobility support, and accessible materials); next we want to deepen the workflow for each beyond the captioning-focused demo. We also plan to add provider self-onboarding, richer provider and calendar integrations, organization-specific escalation policies, analytics for time-to-accommodation, and configurable privacy controls. Our long-term goal is to help every Slack-based team respond to accessibility needs quickly, consistently, and respectfully.

Built With

TypeScript · Node.js · Slack Bolt · Slack Block Kit · Model Context Protocol (MCP) · Slack Real-Time Search API · SQLite · AWS EC2

Built With

• bolt
• mcp
• slack
• slackcli
• ts