You have an AI notetaker in every meeting. Ten minutes after the call ends, there is a transcript and a summary in your inbox. And then, for most teams, nothing else happens. The action items live in a summary email nobody reopens. The decision made in minute 34 exists in exactly one place: the memory of the people who were there. The thing you promised a customer is written down, technically, in a transcript nobody will ever search. PMs describe exactly this on r/ProductManagement: the post-meeting chaos of turning calls into actual work, and ending a day of back-to-back calls with "14 pages of disorganized notes" and no system for what happens next.

Can you build the "what happens next" with Claude Code? Yes. This playbook is the complete build: a daily scheduled run that picks up new transcripts, extracts decisions, actions, open questions, and customer commitments, routes each one to where it belongs, and, the part no notetaker does, checks whether last week's actions actually closed.

What you're building

Every morning, without you touching anything:

Actions filed in your tracker. Each internal action from yesterday's meetings becomes a Linear or Jira ticket with an owner, a due date if one was stated, and a verbatim quote from the transcript as evidence.
Decisions logged. Every decision lands in a committed, append-only decision log with a link back to the meeting it came from. Searchable forever.
Customer follow-up drafts. Anything promised to a customer becomes a drafted Slack or email follow-up waiting for your approval. Never auto-sent.
An aging-actions digest. Each run checks the tickets filed by prior runs and reports what closed, what moved, and what has been sitting untouched for two weeks.

Transcription is solved. Routing is not.

The obvious move is to paste a transcript into a chat and say "summarize this and pull out the action items." It works, once, and it does not compound, for three reasons:

No destinations. A summary is not a ticket. An action item in a chat window still needs a human to open the tracker, pick a project, find the owner, and file it. That is the exact manual step you were trying to delete.
No dedupe. The chat does not know that "fix the onboarding email timing" already exists as ENG-482 from last Tuesday's meeting. It will cheerfully produce the same action again, and if you wire naive auto-filing, your tracker fills with duplicates. Duplicate tickets are how trust in an automated system dies.
No follow-through memory. The chat has no record of what it extracted last week, so it can never tell you which commitments closed and which are quietly rotting. Continuity is not something you get from a summarizer; it is something you engineer with committed state, which is exactly what this playbook does.

Compared to the conversation-intelligence build, this is a low-volume, high-consequence workflow. You are not fighting 27 million tokens a week; ten meetings of transcript fit in a context window with room to spare. The difficulty is entirely in the routing: getting the right item to the right place with the right approval gate, every day, without human babysitting.

Phase 0: Prerequisites

Claude Code installed (npm install -g @anthropic-ai/claude-code) and authenticated, on a Pro, Max, Team, or Enterprise plan for the scheduling and publishing steps.
Transcript access. If you use Fireflies, there is a community MCP server; for Gong there is a community server as well. Both vendors also have export APIs a script can hit directly, which is the sturdier path for a scheduled pipeline. Community servers are community-maintained; read the code before giving them credentials.
Tracker access. Linear ships an official MCP server (mcp.linear.app/mcp); Atlassian ships an official server covering Jira and Confluence.
Slack delivery. No official Slack MCP server exists; the community korotovsky/slack-mcp-server works, or a plain incoming-webhook script, which is all a digest needs.
A dedicated git repo. The routing rules, decision log, and run-to-run state all live in git. This is not a style preference; the recurring design below depends on it.

Phase 1: The repo (rules, log, and watermark)

meeting-router/
├── CLAUDE.md
├── .mcp.json                  # tracker + notetaker connections
├── .claude/
│   ├── agents/
│   │   ├── extractor.md       # transcript → structured items
│   │   ├── router.md          # items → destinations
│   │   └── critic.md          # judge loop before anything files
│   └── skills/
│       └── meeting-router/
│           └── SKILL.md
├── routing/
│   └── rules.yaml             # committed routing rules
├── decisions/
│   └── log.md                 # append-only decision log
├── state/
│   ├── watermark.json         # last processed transcript timestamp
│   └── actions.json           # every filed action + ticket ID + date
├── drafts/                    # customer follow-ups awaiting approval
└── runs/                      # committed: one folder per daily run

Three files carry the design.

routing/rules.yaml is the committed answer to "where does this go and who approves it":

meeting_types:
  eng_standup:
    actions: { destination: linear/ENG, gate: auto_file }
  product_review:
    actions:   { destination: jira/PROD, gate: auto_file }
    decisions: { destination: decision_log, gate: auto_file }
  customer_call:
    actions:      { destination: linear/CS, gate: auto_file }
    commitments:  { destination: drafts/, gate: draft_for_approval }
defaults:
  unknown_meeting_type: { gate: draft_for_approval }
  customer_commitment:  { gate: draft_for_approval }   # never overridden

The gate levels are the safety architecture. Internal actions auto-file; anything shaped like a promise to a customer never auto-sends, no matter what meeting it came from. It lands in drafts/ and waits for a human. Because the rules are a file in git, changing who approves what is a reviewed PR, not a setting someone toggled and forgot.

decisions/log.md is append-only markdown: date, decision, who was in the room, a verbatim quote, and a link to the source meeting. It looks unglamorous. Give it six months and it becomes the answer to every "wait, why did we decide X?" thread, with receipts. That archive is the quietly compounding asset of this whole system; no meeting tool builds it for you.

state/watermark.json and state/actions.json are the memory. The watermark makes every run incremental (only transcripts newer than the last run get processed). The actions ledger records every ticket this system ever filed, which powers the follow-through loop in Phase 4. Both are committed, so every scheduled run inherits them by cloning the repo.

CLAUDE.md states the rules the model must never improvise: what counts as a decision versus an action, that customer commitments always gate, and that every routed item must carry its transcript quote.

Phase 2: Ingestion and extraction

The daily run starts by pulling every transcript newer than the watermark, via the notetaker MCP or an export script. Then the extractor agent reads each transcript once and produces structured items:

{
  "type": "action | decision | question | customer_commitment",
  "text": "Ship the onboarding email fix",
  "owner": "priya",
  "due": "2026-07-10",
  "context": "raised after churn review of trial cohort",
  "quote": "Priya, can you take the onboarding email fix by Friday?",
  "quote_timestamp": "00:34:12",
  "meeting_id": "fireflies/abc123",
  "quote_is_verbatim": true
}

Two rules earn their keep here. First, the four-way type split is the product decision: an action has an owner and lands in a tracker; a decision has no owner and lands in the log; a question is unresolved and lands in the digest; a customer commitment is a promise made outward and always gates. Collapsing these into one "action items" bucket is why notetaker summaries feel mushy. Second, every item carries a verbatim quote and timestamp. Anything this system files anywhere arrives with its evidence attached, so a skeptical owner can click through to minute 34 and hear it said. Models paraphrase; the quote_is_verbatim flag exists so the critic can check.

Extraction is classification plus quoting, not reasoning, so a small model handles it. At ten meetings a week this fits inside a session anyway; the cost section has the math.

Phase 3: Routing and dedupe (the judge loop)

.claude/agents/router.md takes each extracted item, classifies the meeting type against rules.yaml, and resolves the destination and gate. Before creating any ticket, it must dedupe:

Before filing any action:
1. Search the destination project for open tickets matching the
   action title (tracker MCP search; compare titles and summaries).
2. Check state/actions.json for a prior filing from an earlier
   meeting on the same subject.
3. Match found → comment on the existing ticket with the new
   quote and meeting link. No new ticket.
4. No match → create the ticket with owner, due date, quote,
   and meeting link. Record it in state/actions.json.

Title matching over the tracker's search covers most of it; if your tracker is large, embedding similarity over open-ticket titles is a small script away. Either way, the invariant is the same: a repeated discussion updates the existing ticket instead of spawning a twin.

.claude/agents/critic.md grades everything before it leaves the run:

For every routed item:
1. Owner present and a real person from the attendee list?
   Actions without owners → FAIL.
2. Destination valid per routing/rules.yaml for this meeting type?
3. Any customer_commitment routed anywhere except drafts/ → FAIL,
   unconditionally.
4. Quote verifiable: grep the quote against the source transcript.
   Not found verbatim → FAIL.
Return PASS, or FAIL with the specific items to fix. Max 2 loops.

Check 3 is the one you never relax. A system that files a duplicate ticket embarrasses you; a system that auto-sends a wrong promise to a customer ends the experiment.

Phase 4: The follow-through loop

This is the part no notetaker ships, and it is fifteen lines of skill prompt. Each run, after routing the new items:

Read state/actions.json.
For every action filed in the last 30 days, query its ticket status via the tracker MCP.
Mark closures, note movement, and flag anything open and untouched past its due date or past 14 days.
Emit an aging-actions digest: closed since yesterday, newly filed today, and the aging list with owners and original meeting links.

Meetings generate promises; this loop is what makes the promises load-bearing. It is also deliberately a digest, not a nag bot: the system reports aging to the channel, and a human decides whether to chase. Keep it that way (see Maintenance).

Phase 5: Scheduling

The /meeting-router skill strings it together: read watermark and prior state, ingest, extract, route with critic, run the follow-through loop, write the run folder, update state, commit.

Managed path: create a daily cloud routine with /schedule ("weekdays 7am: run /meeting-router"). The routine clones the repo's default branch, which is exactly how it inherits the watermark, the rules, and the actions ledger; its commits come back on a claude/-prefixed branch, and runs draw on your plan usage. Put the notetaker and tracker credentials in the routine's environment variables; the cloud session does not have your laptop's .env.

Self-hosted path: system cron running headless mode (claude -p "/meeting-router" --allowedTools scoped to the pipeline), or a GitHub Actions cron with the official claude-code-action, whose docs include a scheduled daily-report example.

Either way, add a Stop hook that posts run status to Slack. A router that silently stopped filing on Tuesday is worse than none, because everyone assumes the tracker is complete.

Phase 6: Sharing with the team

The daily Slack digest is the product most people see: filed today, drafts awaiting your approval, and the aging list. Small, scannable, every morning.
The decision log is itself the shared asset. It is a markdown file in a repo; link it from your team wiki and it needs no tooling to read. The habit shift, "check the log before relitigating," is cultural, but the log existing is what makes the habit possible.
A weekly actions page. Have Claude Code publish the week's digest as an artifact: a hosted page on claude.ai with a stable URL, org-scoped visibility on Team and Enterprise plans. One caveat to plan around: artifact publishing works from the CLI and desktop app, not from every automated surface, so in a fully autonomous setup the weekly publish may be the one step a human triggers, or you skip it and let Slack carry the weight.

Phase 7: Maintenance (what you own now)

Routing-rules upkeep. Teams reorganize, projects rename, approvers change roles. rules.yaml goes stale the way any org chart artifact does. Put it in the PR path for reorg checklists, because a stale rule quietly files tickets into a dead project.
Meeting-type classification drift. New recurring meetings appear and get classified as unknown, which gates everything to drafts. That is the safe failure, but if nobody adds the new meeting type to the rules, the "automated" system degrades into a drafts queue. Review the unknowns weekly.
Transcript coverage gaps. The system only routes what the notetaker heard. People forget to invite it, decline recording, or make the real decision in the hallway afterward. Track a simple coverage number (meetings on calendars versus transcripts processed) so gaps are visible instead of silent.
Aging-actions etiquette. The digest names people whose tickets are stale, in public, daily. Calibrate this with the team before it runs, keep it factual and quote-linked, and route escalation through a human. An automated system that reads as a surveillance bot gets its meetings un-recorded, which kills coverage, which kills the system.

What this costs

Assumptions to check against your calendar: 10 meetings a week at 45 minutes each. A 45-minute transcript runs roughly 7-9K words, call it 10-12K tokens, so the whole week is on the order of 100-120K input tokens of transcript. That is two orders of magnitude below the conversation-intelligence workload, and it shows in the bill:

Extraction is small-model work over a small volume. Whether it runs inside the daily session or through a metered API call, the token spend rounds to noise next to your subscription.
The daily session is the skill overhead, the extractor and router passes, a critic loop, and a handful of tracker queries for dedupe and follow-through. This fits comfortably in a Pro or Max plan's included usage; routines draw on plan usage like any session, so a daily run is the thing to watch in /usage, not any per-token line item.
Plan tier: cloud routines and artifact publishing are subscription features, and org-scoped artifact visibility needs Team or Enterprise.
The line that never hits an invoice: someone wrote the routing rules, tuned the critic, negotiated the aging-digest etiquette, and reviews the unknown meeting types weekly. This system is cheap in tokens and real in ownership.

The four practical challenges

Setup at scale: not token scale here, but destination scale. The routing rules, gate levels, and dedupe logic (Phases 1-3) are the real engineering, because "extract action items" was never the hard part.
Sharing with the team: the Slack digest, the decision log as a linkable asset, and the weekly artifact page (Phase 6), with the publish-surface caveat.
Maintenance: rules upkeep, classification drift, coverage gaps, and escalation etiquette (Phase 7). The social maintenance is as real as the technical.
Cost: minimal in tokens, mostly your existing subscription; the spend is the owner's attention, daily in small doses.

The managed alternative

The notetakers themselves are the adjacent products: Fireflies, Fathom, and Granola all ship action-item detection, and some ship integrations toward trackers and Slack. If detection inside the meeting tool is all you need, they are the fastest path. The fair trades: detection is not routing, so getting each item to the right project with the right owner and the right approval gate remains your job; dedupe against your existing tickets and follow-through tracking on what actually closed stay manual; and the rules live in each vendor's settings screens rather than in a file you version, review, and diff when the org changes.

Doing this with Second Axis

Everything above is the do-it-yourself path. On Second Axis, meeting routing is a workflow in the marketplace: connect your notetaker, your tracker, and Slack, choose the workflow, and set the goal ("file actions with owners, log decisions, draft customer follow-ups for my approval, chase aging actions weekly"). It runs daily from there, with the extraction schema, routing gates, dedupe, and follow-through ledger built in, and it monitors itself: missing transcripts, failed runs, and routing errors get found and alerted instead of silently piling up in a queue nobody checks.