Omen

Find out how your launch fails, before it ships.

Comment

Inspiration

Every team has lived the same story. A launch starts as one clean, well scoped job. Then, in the same Slack channel, someone says "while we're in there, can we also add..." and a second feature slips in. Then a third. The ship date never moves. Nobody says out loud that the scope has tripled. And the launch breaks in exactly the place all that quiet scope creep piled up.

The tools we already have don't help here. Delivery trackers tell you when you'll slip. Postmortem tools explain why you failed, after the outage. Incident tools clean up after the fire. None of them answer the question you actually care about the day before you ship: how is this specific launch going to break?

Omen is the premortem agent that answers exactly that, before a single line ships, right where the work already happens: Slack.

What it does

You type /omen [launch name] in a project channel, and Omen forecasts how that launch will fail as an evidence backed report, not a generic checklist. It:

  • reads the channel to detect scope drift, the work that crept in beyond the original spec,
  • pulls your team's own incident history from GitHub through a real MCP server,
  • searches the web in real time for comparable failures at other companies,
  • and hands all of it to Claude, which returns ranked failure modes, each with a likelihood, an impact, a concrete mitigation, and an owner.

Its signature move is the drift to risk linkage. It doesn't just flag that single sign on got bolted onto a payments launch, it ties that addition to the specific outage it will cause. Every forecast also ships with three adversarial voices, a saboteur, a customer, and a pessimist who says the thing nobody in the room will, plus a readiness score from 0 to 100.

Crucially, every grounding source is tagged live or demo, so Omen never passes seed data off as real. That honesty been a feature, not an afterthought. Everything mirrors to a live web dashboard, a Launch Radar that ranks every launch by risk and updates in real time.

How we built it

  • Slack: a Bolt app in Socket Mode handles the slash command, App Home, and interactive buttons for accepting a mitigation or re-running a forecast. No public URL required.
  • MCP: a genuine Model Context Protocol server over stdio wraps GitHub as a tool, and the grounding engine connects as an MCP client to call it. There is also an optional mode that connects to GitHub's official remote MCP server. The engine never touches GitHub REST directly, it always speaks MCP.
  • Real time search: the Tavily API pulls comparable public failures for the launch topic.
  • Reasoning: a single Claude tool use call returns the entire structured forecast, failure modes, drift links, and personas, in one round trip.
  • Frontend: React, Vite, and Tailwind, with a live Server Sent Events feed so the dashboard updates the moment a forecast runs.
  • Persistence and deployment: SQLite so forecasts survive restarts, with the Slack and API backend on Render and the dashboard on Vercel, fully live end to end.

Challenges we ran into

  • Making MCP real, not theater. My first GitHub leg was a REST call wearing an MCP costume. I rebuilt it as an actual MCP server and client with a verified stdio round trip, then had to make it work in the compiled production build, where the subprocess must launch the built JavaScript rather than the dev TypeScript.
  • Grounding honesty. I built a provenance system so every leg reports live or demo, and fixed a subtle bug where a forecast counted its own citations as GitHub incidents. Counts now reflect what each leg actually returned.
  • Graceful degradation. A real team might not connect GitHub, so Omen had to stay genuinely useful on Slack plus search alone, and never leak one launch's demo context into an unrelated forecast.
  • Latency and reliability. Live synthesis takes real time and a free tier host is memory tight, so I bounded every call, added a hard timeout so a forecast can never hang on a spinner, and turned the wait itself into a staged view that shows each technology working.

Accomplishments that we're proud of

  • A genuinely real MCP integration, not a demo over a REST call. The GitHub grounding runs through an actual Model Context Protocol server and client over stdio, with a verified round trip, plus an optional path to GitHub's official remote MCP server. The engine only ever speaks MCP.

  • The drift to risk linkage. Omen doesn't just notice that scope crept, it ties each addition to the specific failure it will cause. As far as we can tell, nothing else on the market connects scope drift to concrete predicted outages this way.

  • Grounding you can trust. Every source is tagged live or demo, so the agent never passes seed data off as real. Building honesty into the output, rather than hiding the seams, is something we care about a lot.

  • It degrades gracefully. Three real grounding sources, and the forecast stays genuinely useful with any subset of them connected. A team on Slack and live search alone still gets a sharp, specific premortem.

  • Fully live, end to end. A Slack agent and a real time dashboard, sharing one backend, deployed on real infrastructure. Run the command in Slack and watch the forecast appear on the web dashboard the same instant.

  • Real forecasts, cited from the real web. Every failure mode is backed by evidence, including live postmortems pulled from search, with the actual source links attached. Nothing about the output is hardcoded.

What we learned

The hardest part of an AI agent is not the model call, it is the grounding and the honesty around it. Making three real data sources degrade gracefully, tagging every claim as live or demo, and connecting scope drift to concrete failures is what turns a wrapper around a language model into something a team would actually trust the day before they ship.

What's next for Omen

Per workspace GitHub authentication for true multi tenant grounding, exportable premortem artifacts, and a proactive mode where Omen watches a channel and warns as scope drifts, before anyone even runs the command.

Built With

Share this project:

Updates