OffboardMe

About the project

OffboardMe is a Slack-native offboarding agent built to reduce the silent knowledge loss that happens when someone leaves a company. The idea came from a familiar failure mode: handovers usually focus on assets and access, while the most valuable context lives in conversations, half-finished tasks, undocumented workarounds, and the people who know why decisions were made.

We built OffboardMe around a simple goal:

$$ K_{retained} = K_{captured} + K_{structured} + K_{routed} $$

The agent starts in Slack, where work already happens. It can guide a departing employee through targeted interviews, identify pending work, collect context from collaboration tools, and prepare a reusable handover dossier. The system is designed to turn unstructured offboarding knowledge into structured records, SOP candidates, and graph relationships between people, topics, tasks, and documents.

How we built it

The project is split into separate repos so each part has a clear responsibility:

slack-agent is the Slack-facing TypeScript service. It handles Slack Socket Mode events, guided interview flows, Slack replies, and calls into backend and MCP services.
mcp-server is the integration and tool boundary. It exposes MCP prompts/tools/resources for Jira, Trello, search, OAuth flows, and dossier-related operations.
backend is the FastAPI service for durable APIs, auth boundaries, persistence, dossier state, and future graph/expert lookup endpoints.
infra owns the Docker Compose stack, the self-hosted GitHub Actions deployment workflow, Cloudflare tunnel routing, and smoke checks.

For the demo environment, everything runs on one Docker LXC hosted on Proxmox. GitHub Actions deploys through a self-hosted runner on that LXC, rebuilds the three services from main, restarts the Compose stack, and validates the deployment with smoke checks. Public demo access goes through Cloudflare Zero Trust, while Slack communication uses Socket Mode so Slack can reach the agent without exposing a raw public events endpoint.

What we learned

The main product lesson was that offboarding is not a single form to fill out. It is a knowledge routing problem. Good handover automation needs to ask the right follow-up questions, preserve source links, identify who else knows a topic, and separate urgent pending work from background context.

The main engineering lesson was that hackathon speed still needs strong operational boundaries. Keeping the Slack agent, backend, MCP server, and infra repo separate made the architecture easier to reason about, but it also forced us to build real CI/CD, clear environment contracts, health checks, and a shared knowledge base for future agents.

Challenges we faced

The hardest part was aligning several moving parts at once: Slack app configuration, Socket Mode, MCP transport, Docker Compose networking, Cloudflare ingress, and cross-repo GitHub Actions. We also had to handle practical deployment issues such as container health checks, service ports, runner permissions, environment drift, and keeping the bot behavior consistent after redeploys.

Another challenge was deciding what to fully implement for the hackathon and what to scaffold cleanly. We focused on a credible end-to-end architecture: Slack as the user interface, MCP as the tool layer, backend persistence and graph boundaries, Kafka for async lifecycle events, and a reproducible deployment environment that judges can access.

Why it matters

Offboarding is usually treated as an administrative workflow, but the real cost is organizational memory. OffboardMe treats knowledge as something that can be captured, structured, searched, and routed before it disappears. That makes the next teammate faster, the manager less dependent on ad hoc handovers, and the company less vulnerable to context loss.