Follow-Through is a NitroStack MCP server that pulls commitments out of meeting transcripts, then checks Slack, email, and Linear for real proof of completion before it nudges anyone or tells a manager. Built by independent developer ionfwsrijan, it treats a spoken promise as an unverified claim, not a task that is automatically true.
What this enables
- Extracts who promised what, to whom, and by when directly from a raw transcript.
- Grades each promise as committed, hedged, or aspirational, so wishes never get chased.
- Waits for a real Slack or email signal before marking anything done.
- Escalates to a manager only after nudges and a stale Linear ticket line up.
- Compresses a multi-day follow-up cycle into a few seconds for testing or demos.
What Follow-Through actually is
Follow-Through is a TypeScript MCP server built on the NitroStack SDK. In the builder's own demo, it runs as a local MCP server wired into Antigravity, a coding agent, and connected to Slack, email, and Linear. A meeting transcript goes in. The server extracts commitments, opens a Linear ticket for each one, then keeps working on its own: polling for evidence, sending nudges, and escalating when a promise goes quiet. Nobody has to re-prompt it between steps.
Why meeting commitments quietly die
Most action items from a meeting live in a transcript nobody reopens. Someone says they will ship a report by Friday, the call ends, and the promise has no home. It is not in a tracker, it is not assigned, and the only proof it ever happened is buried in a call recording.
The harder problem is not capturing the promise. It is deciding, later, whether it was kept. A bot that nags everyone on a fixed schedule regardless of what actually happened trains people to ignore it. A bot that assumes a task is done because someone mentioned the topic in Slack is worse: a false "done" hides a problem that a false nudge would have caught. Follow-Through's design treats that asymmetry as the whole point.
Why MCP is the right boundary here
Capture, evidence-checking, nudging, and escalation are naturally separate operations, and MCP tools give each one an explicit, callable boundary instead of burying them inside one chat prompt. extract_commitments only extracts. search_slack_evidence only searches. linear_escalate only escalates. That separation is what lets the same server run inside a dev client like Antigravity for testing and still expose the identical tool surface to a production host later, with no rewrite of the underlying logic.
How the build works
Follow-Through registers 14 MCP tools across six modules: ingestion, store, evidence, nudge, linear, and scheduler. The runtime sequence looks like this:
- A transcript is passed to
extract_commitments, which parses it into structured commitment records (owner, promise, due date, confidence tier) using an LLM provider or a fully offline deterministic parser. - Each commitment is persisted and a Linear ticket is created through
linear_create_ticket. - A scheduler polls due commitments and, for each one, checks
search_slack_evidence,search_email_evidence, andlinear_get_statusbefore doing anything else. Proof beats nagging. - If there is no evidence and no completed ticket,
send_nudgefires, moving the commitment along an escalation ladder: open, then nudged_1, then nudged_2, then escalated. - An escalated commitment triggers
linear_escalate, which adds a manager watcher and a contextual comment to the actual ticket, not just a side notification.
Confidence tiers change the pacing. A committed promise gets nudged right at its due date; a hedged one gets a longer grace period; an aspirational one, like "we should probably track error budgets," is never chased at all. A demo control, simulate_days_passing, advances a virtual clock and runs a full poll cycle in seconds, which is how a week-long chase becomes watchable in one sitting. Slack, email, and Linear currently sit behind swappable service interfaces returning fixed mock data, so wiring in real API clients later would not require touching the tool schemas.
Where NitroStack fits
The server is structured as six NitroStack modules wired together through one root module, using the SDK's decorator-based classes and dependency injection to keep ingestion, storage, evidence-checking, nudging, and Linear logic in separate, testable units rather than one large handler. The live commitment board is a NitroStack widget: query_commitments is auto-attached to a Next.js component that renders owner, due date, confidence, status, and nudge history whenever the tool runs inside a compatible MCP host, without a separate frontend deployment step.
The design choice that matters
The interesting part is not the nudging. It is where the bar for "done" gets set. scoreEvidence() combines three signals: how many of the commitment's key terms show up in a message, whether the message contains a completion word like sent or shipped, and whether it actually came from the commitment owner. A score of 0.6 or higher marks the commitment done. A message that only repeats the right keywords, with no completion signal or owner match, caps out at 0.55, deliberately below that line. The build treats a false "done" as more expensive than an extra nudge, and bakes that judgment into a number instead of leaving it to a prompt.
What this build demonstrates
Follow-Through has no production customer and no deployed team behind it. What it does show, backed by a 30-plus-assertion end-to-end smoke test run against the live MCP protocol, is that an evidence-gated follow-up loop can run end to end, from transcript to escalation, without a human re-prompting it at any step, and that the same evidence logic works whether the underlying LLM extraction is paid, free-tier, or fully offline.
Reusable takeaway
The pattern worth borrowing is not "AI reads meetings." It is separating a completion claim from a completion decision, and giving the decision its own threshold instead of trusting the model's confidence. Any workflow that turns spoken or written intent into tracked work, not just meeting notes, can use the same shape: capture the claim as a tool call, verify it against an independent signal, and only escalate once both the claim and the silence have held up over time.
Explore the Follow-Through source on GitHub, or start from the NitroStack SDK if you want to build a similar evidence-checking MCP server.