Meeting Notes to Action Items: Automate It with Claude (AI Meeting Notes Summarizer)

By MUASIF80·June 5, 2026·23 min read·AI Use Cases

The Real Cost of Manual Meeting Notes

Every engineering team has the same ritual. Someone volunteers to take notes. The meeting ends. The notes land in a Notion page two days later, stripped of context, missing three out of five action items, and with “TBD” next to half the owners. Then the next standup starts with “wait, did we decide that?”

That is not a people problem. It is a tooling problem. Meeting transcription has been solved for years. Zoom, Google Meet, and Microsoft Teams all export transcripts. The bottleneck is the step between “raw spoken words” and “structured work items that land in Jira or Linear.” That step is manual, it is lossy, and it scales poorly with meeting volume.

An ai meeting notes summarizer running on Claude closes that gap. Given a raw transcript, it produces a JSON object with three parts: a short summary of what was discussed, a list of decisions made, and action items each carrying an owner name, description, and due date. That JSON feeds directly into your project management API. No human transcription step. No follow-up “can you send me the action items” Slack thread.

Who benefits most

• Engineering leads running three to five syncs per week: sprint planning, architecture review, incident postmortem, stakeholder update, and team retro. Each produces five to fifteen action items that need tracking.
• Technical PMs who own meeting hygiene but do not have bandwidth to manually format notes from every team they coordinate.
• Founders of small teams where everyone wears too many hats to also be a reliable note-taker.
• Consulting teams billing by the hour where accurate decision logs protect against scope creep disputes.

The time savings are real. A 60-minute planning meeting typically produces a 4,000-6,000 token transcript. Claude processes it in about 2.5 seconds at roughly $0.003 using claude-sonnet-4-6 with prompt caching. Compare that to 15-20 minutes of manual summarization per meeting, multiplied by how many meetings happen per week in your organization.

Architecture of the AI Meeting Notes Summarizer

Why structured output matters here

When people ask Claude to “summarize this meeting,” the free-text response is usually good but not machine-consumable. You cannot reliably split it into fields with a regex. The output format changes slightly each time. Owner names might appear in the summary but not as a discrete field. Due dates might be “next Friday” relative to a context Claude does not have.

Using Claude’s tool use API to force a structured output schema solves this completely. You define the JSON shape upfront as a tool input schema. You pass tool_choice={"type":"tool","name":"extract_meeting"} to force Claude to always call that tool. You get back a tool_use block whose input field is the structured object, validated against your schema. This is exactly the pattern described in Part 3: Structured Output from Claude.

Prompt caching for team context

Most teams have stable context that repeats across every meeting: the team roster with full names and handles, the project glossary, the sprint number, the conventions for due dates (“EOD Friday” means 5pm UTC on Friday). That context can run to 1,000-3,000 tokens. If you process 20 meetings per week, you pay for those tokens 20 times without caching.

With prompt caching (covered in depth in Part 4: Prompt Caching with Claude), you mark the team context block with "cache_control":{"type":"ephemeral"}. The first call pays full price. All subsequent calls within the five-minute cache window read from cache at 10% of the original cost. For a team processing meetings continuously throughout the day, this is a 70-85% reduction in input token spend.

Designing the Output Schema

The schema design is where most teams make mistakes. They try to capture everything in one pass and end up with a schema so complex that Claude occasionally gets confused about which field something belongs in.

A production schema should have exactly three top-level keys:

• summary: A string of three to five sentences. What the meeting was about, what the state of the work is, and what the main outcome was. Not what was said verbatim.
• decisions: An array of short strings. Each decision should be one sentence. Voted on approaches, resolved disagreements, confirmed priorities.
• action_items: An array of objects. Each object has owner, description, due_date (ISO 8601), and priority (high/medium/low).

Handling ambiguous owners

Transcripts frequently reference people by first name only, nickname, or title (“the backend team”, “someone from infra”). You have two options: normalize before calling Claude by injecting a team roster into the system prompt, or post-process after and fuzzy-match against your user directory. The pre-processing approach (roster injection) is more reliable because Claude can use the context to resolve “Alex” to “Alex Chen ([email protected])” during extraction, not as a separate pass.

The Complete POC

Setup

Create a requirements.txt file in your project root:

anthropic>=0.30.0
python-dotenv>=1.0.0

Create a .env file (never commit this to version control):

# .env
ANTHROPIC_API_KEY=sk-ant-...

Full source: meeting_summarizer.py

"""
meeting_summarizer.py

Turn a raw meeting transcript into structured JSON:
  - summary (str)
  - decisions (list[str])
  - action_items (list[{owner, description, due_date, priority}])

Uses Claude tool_use with forced tool_choice for deterministic output.
Prompt caching on the team-context block reduces cost for repeated calls.

Usage:
    python meeting_summarizer.py --transcript transcript.txt [--team-roster roster.json] [--date 2026-06-04]
"""

import argparse
import json
import os
import sys
from datetime import date, timedelta

import anthropic
from dotenv import load_dotenv

load_dotenv()

# ---------------------------------------------------------------------------
# Tool / Output Schema
# ---------------------------------------------------------------------------

EXTRACT_MEETING_TOOL = {
    "name": "extract_meeting",
    "description": (
        "Extract a structured summary, decisions, and action items from a meeting transcript. "
        "Return only factual content found in the transcript. "
        "Convert relative due dates (e.g. 'by end of next week') to ISO 8601 dates "
        "using the meeting_date provided in the system prompt. "
        "If no due date is mentioned, use null. "
        "Normalize owner names using the team roster when provided."
    ),
    "input_schema": {
        "type": "object",
        "properties": {
            "summary": {
                "type": "string",
                "description": (
                    "Three to five sentences: what was discussed, current status, "
                    "and the main outcome or decision. Written in third person."
                ),
            },
            "decisions": {
                "type": "array",
                "description": "Explicit decisions reached during the meeting.",
                "items": {
                    "type": "string",
                    "description": "One sentence per decision.",
                },
            },
            "action_items": {
                "type": "array",
                "description": "Tasks assigned to specific people with due dates.",
                "items": {
                    "type": "object",
                    "properties": {
                        "owner": {
                            "type": "string",
                            "description": "Full name or handle of the person responsible.",
                        },
                        "description": {
                            "type": "string",
                            "description": "What they need to do.",
                        },
                        "due_date": {
                            "type": ["string", "null"],
                            "description": "ISO 8601 date (YYYY-MM-DD) or null if not mentioned.",
                        },
                        "priority": {
                            "type": "string",
                            "enum": ["high", "medium", "low"],
                            "description": "Inferred priority from urgency language in the transcript.",
                        },
                    },
                    "required": ["owner", "description", "due_date", "priority"],
                },
            },
        },
        "required": ["summary", "decisions", "action_items"],
    },
}


# ---------------------------------------------------------------------------
# System prompt builder (cached block for team context)
# ---------------------------------------------------------------------------

def build_system_prompt(team_roster: dict | None, meeting_date: str) -> list:
    """
    Returns the system prompt as a list of content blocks.
    The team-context block uses cache_control so repeated calls hit the cache.
    """
    base_instructions = (
        f"You are a meeting analysis assistant. Today's date is {meeting_date}. "
        "You extract structured information from meeting transcripts. "
        "Be precise: only include decisions that were explicitly made, not topics that were raised. "
        "Only include action items that were explicitly assigned to a person. "
        "For due dates, convert relative language to ISO 8601 dates using today's date as the anchor. "
        "If ownership is ambiguous, use the most specific attribution available (team name over 'someone'). "
        "Do not fabricate information not present in the transcript."
    )

    blocks = [{"type": "text", "text": base_instructions}]

    if team_roster:
        roster_text = "Team roster for name normalization:\n"
        for handle, info in team_roster.items():
            roster_text += f"  - {info['name']} (handle: {handle}, email: {info.get('email', 'N/A')})\n"
        # Mark the roster block for caching: this is stable across calls
        blocks.append({
            "type": "text",
            "text": roster_text,
            "cache_control": {"type": "ephemeral"},
        })

    return blocks


# ---------------------------------------------------------------------------
# Core extraction function
# ---------------------------------------------------------------------------

def extract_from_transcript(
    transcript: str,
    team_roster: dict | None = None,
    meeting_date: str | None = None,
    model: str = "claude-sonnet-4-6",
) -> dict:
    """
    Send the transcript to Claude and return the structured extraction as a dict.

    Args:
        transcript: Raw transcript text.
        team_roster: Optional dict mapping handles to {name, email}.
        meeting_date: ISO 8601 date string for resolving relative dates.
                      Defaults to today.
        model: Claude model ID.

    Returns:
        Dict with keys: summary, decisions, action_items, _usage.
    """
    if meeting_date is None:
        meeting_date = date.today().isoformat()

    client = anthropic.Anthropic()

    system_prompt = build_system_prompt(team_roster, meeting_date)

    user_message = (
        "Please extract the meeting summary, decisions, and action items "
        "from the following transcript.\n\n"
        f"<transcript>\n{transcript}\n</transcript>"
    )

    try:
        response = client.messages.create(
            model=model,
            max_tokens=2048,
            system=system_prompt,
            tools=[EXTRACT_MEETING_TOOL],
            tool_choice={"type": "tool", "name": "extract_meeting"},
            messages=[{"role": "user", "content": user_message}],
        )
    except anthropic.APIError as exc:
        print(f"Claude API error: {exc}", file=sys.stderr)
        raise

    # Extract the tool_use block
    tool_result = None
    for block in response.content:
        if block.type == "tool_use" and block.name == "extract_meeting":
            tool_result = block.input
            break

    if tool_result is None:
        raise ValueError(
            f"Claude did not return a tool_use block. stop_reason={response.stop_reason}"
        )

    # Attach usage metadata for cost tracking
    tool_result["_usage"] = {
        "input_tokens": response.usage.input_tokens,
        "output_tokens": response.usage.output_tokens,
        "cache_creation_input_tokens": getattr(
            response.usage, "cache_creation_input_tokens", 0
        ),
        "cache_read_input_tokens": getattr(
            response.usage, "cache_read_input_tokens", 0
        ),
        "model": model,
    }

    return tool_result


# ---------------------------------------------------------------------------
# CLI entry point
# ---------------------------------------------------------------------------

def main():
    parser = argparse.ArgumentParser(description="Extract action items from a meeting transcript.")
    parser.add_argument("--transcript", required=True, help="Path to transcript .txt file")
    parser.add_argument(
        "--team-roster",
        help="Path to team roster JSON file (optional)",
    )
    parser.add_argument(
        "--date",
        default=date.today().isoformat(),
        help="Meeting date in YYYY-MM-DD format (default: today)",
    )
    parser.add_argument(
        "--model",
        default="claude-sonnet-4-6",
        choices=["claude-haiku-4-5", "claude-sonnet-4-6", "claude-opus-4-8"],
        help="Claude model to use",
    )
    parser.add_argument("--output", help="Path to write JSON output (default: stdout)")
    args = parser.parse_args()

    # Load transcript
    with open(args.transcript, "r", encoding="utf-8") as f:
        transcript = f.read()

    # Load roster if provided
    team_roster = None
    if args.team_roster:
        with open(args.team_roster, "r", encoding="utf-8") as f:
            team_roster = json.load(f)

    print(f"Processing transcript ({len(transcript)} chars) with {args.model}...", file=sys.stderr)

    result = extract_from_transcript(
        transcript=transcript,
        team_roster=team_roster,
        meeting_date=args.date,
        model=args.model,
    )

    usage = result.pop("_usage")
    print(
        f"Done. Input tokens: {usage['input_tokens']} "
        f"(cache_created: {usage['cache_creation_input_tokens']}, "
        f"cache_read: {usage['cache_read_input_tokens']}), "
        f"Output tokens: {usage['output_tokens']}",
        file=sys.stderr,
    )

    output_json = json.dumps(result, indent=2, ensure_ascii=False)

    if args.output:
        with open(args.output, "w", encoding="utf-8") as f:
            f.write(output_json)
        print(f"Output written to {args.output}", file=sys.stderr)
    else:
        print(output_json)


if __name__ == "__main__":
    main()

Sample team roster: roster.json

{
  "sara": {
    "name": "Sara Malik",
    "email": "[email protected]"
  },
  "chen": {
    "name": "Alex Chen",
    "email": "[email protected]"
  },
  "james": {
    "name": "James Okafor",
    "email": "[email protected]"
  },
  "priya": {
    "name": "Priya Nair",
    "email": "[email protected]"
  }
}

Sample transcript: transcript.txt

Sprint Planning - June 4, 2026
Attendees: Sara, Alex Chen, James, Priya

Sara: Alright, let's start. We have 9 tickets in the backlog for this sprint. The main theme is the
notification service rewrite. Alex, what's the status on the DB migration script?

Alex: The script is done and tested locally. I need to run it against staging this afternoon. Should
be done by tomorrow EOD.

Sara: Good. One thing we agreed last sprint was to deprecate the old email queue by end of this sprint,
which is June 18th. Is that still realistic?

Priya: I think so, but we need the new retry logic merged first. I'm blocked on James's review of
PR #442.

James: I'll get to that today, definitely by end of day Thursday.

Sara: Okay, so James reviews PR #442 by Thursday June 6th. Priya, once that's merged, you handle the
deprecation cutover?

Priya: Yes, I'll do the cutover on June 16th to give us two days of buffer before the sprint ends.

Sara: Perfect. One more thing: the product team asked if we can add Slack notifications in addition to
email. We decided last week we're not doing that this sprint, it goes to the next backlog. That's firm.

Alex: Also, I need someone to help write the runbook for the migration. Could Priya do a first draft?

Priya: Sure, I can have a draft done by June 10th.

Sara: Great. So to recap: Alex runs the DB migration against staging by June 5th, James reviews
PR #442 by June 6th, Priya writes the migration runbook draft by June 10th, Priya does the email
queue deprecation cutover on June 16th. We are NOT adding Slack notifications this sprint.

All: Agreed.

Running the script

Expected output

{
  "summary": "The team held a sprint planning session focused on the notification service rewrite. Alex Chen completed the database migration script locally and plans to run it against staging. The team confirmed the old email queue deprecation is on track for June 16th, contingent on PR #442 being reviewed. Slack notification support was explicitly deferred to a future sprint.",
  "decisions": [
    "Slack notifications will not be added in the current sprint and are deferred to the next backlog.",
    "The email queue deprecation cutover is scheduled for June 16th to provide a two-day buffer before the sprint ends on June 18th."
  ],
  "action_items": [
    {
      "owner": "Alex Chen",
      "description": "Run the database migration script against the staging environment.",
      "due_date": "2026-06-05",
      "priority": "high"
    },
    {
      "owner": "James Okafor",
      "description": "Review and approve PR #442 (retry logic for notification service).",
      "due_date": "2026-06-06",
      "priority": "high"
    },
    {
      "owner": "Priya Nair",
      "description": "Write a first draft of the runbook for the database migration.",
      "due_date": "2026-06-10",
      "priority": "medium"
    },
    {
      "owner": "Priya Nair",
      "description": "Execute the email queue deprecation cutover.",
      "due_date": "2026-06-16",
      "priority": "high"
    }
  ]
}

The stderr output from a real run looks like this (with caching active on the second call):

Processing transcript (1847 chars) with claude-sonnet-4-6...
Done. Input tokens: 1243 (cache_created: 0, cache_read: 847), Output tokens: 312

The 847 cache_read tokens are the team roster block being served from cache instead of re-processed. On a team running 20 meetings per week with a 1,000-token roster block, that is 20,000 tokens saved weekly, which works out to roughly $0.30 per week at current claude-sonnet-4-6 pricing. Not life-changing on its own, but across a larger organization with hundreds of weekly meetings it compounds.

Integrating with Jira and Linear

The JSON output from the summarizer maps cleanly to most project management APIs. For Jira, each action item becomes an issue via POST /rest/api/3/issue with the owner resolved to a Jira account ID, the due_date mapped to duedate, and the priority mapped to Jira’s priority field. For Linear, you use the GraphQL issueCreate mutation. Neither integration requires more than 30 lines of Python wrapping requests.

The summary and decisions fields are better sent to a document store (Notion database, Confluence, or a plain S3 bucket with an index) rather than creating tasks for each one. A decision is a record, not a task. Conflating the two pollutes your backlog.

The same pattern Claude uses for extracting action items from meeting transcripts is used in Part 14: AI Email Triage for extracting tasks from inbound email threads. If you are processing both meeting transcripts and emails, you can share the same output schema and downstream routing code.

Model Selection Guide

The cost figures above assume caching is active for the system prompt. Raw costs without caching are roughly 40% higher. For high-volume use cases (processing every meeting for a 200-person company), model routing pays for itself quickly. Route standups and check-ins to Haiku automatically by checking transcript length before calling Claude. See Part 27: Cut AI Costs: Model Routing and Batching for a full implementation of that pattern.

Common Pitfalls

1. Relative dates without an anchor

If you do not pass today’s date in the system prompt, Claude will return natural language like “next Thursday” in due_date fields because it cannot resolve the reference. Your schema marks due_date as ["string", "null"] but a string like “next Thursday” is not ISO 8601. Always include the meeting date in the system prompt. The sample code does this via the meeting_date argument.

2. Action items without explicit owners

Transcripts sometimes contain passive constructions: “the docs need to be updated” or “someone should follow up with the client.” These are real action items but with no owner. Claude will try to infer an owner from context if there is one, but if there is not, it will use the team name or “Unassigned.” Downstream systems that require a specific user ID will need a fallback assignment rule. Define that rule in your routing layer, not in the prompt.

3. Decisions versus discussion topics

A common mistake is prompting Claude to extract “what was discussed” into the decisions list. The prompt should be explicit: decisions are conclusions reached, not topics raised. The system prompt in the sample code says: “only include decisions that were explicitly made, not topics that were raised.” This distinction keeps the decisions list actionable rather than a repeat of the summary.

4. Very long transcripts (token limit)

A 3-hour all-hands meeting at a fast-speaking group can exceed 30,000 tokens. That is within claude-sonnet-4-6‘s context window, but the cost and latency increase. For transcripts over 15,000 tokens, consider a two-pass approach: chunk the transcript into segments (by speaker turn or time block), extract action items from each chunk independently, then deduplicate and merge the results in a second lightweight call. This is also more accurate because Claude maintains better focus on a shorter input.

5. Not logging token usage

The _usage block in the sample code captures cache_creation_input_tokens and cache_read_input_tokens. Log these to your observability system (see Part 28: Observability for LLM Apps). Without this data, you cannot verify that caching is working or track cost trends as meeting volume changes. The ten-line addition to each call pays for itself in the first billing cycle when you find an unexpected cost spike.

6. Trusting output without spot-checking

Claude is accurate on clean transcripts but degrades on transcripts with heavy filler words, overlapping speakers, or domain-specific jargon it has not seen before. The first time you run the summarizer on a new team’s meetings, read the output alongside the original transcript for five or ten meetings. If you find systematic errors, adjust the system prompt rather than adding post-processing hacks. Post-processing hacks compound; a better prompt fixes the root cause.

Cost and Latency Reference

For a team running 100 meetings per week (a realistic number for a 50-person engineering org), the full cost with claude-sonnet-4-6 and caching active is around $1.50 to $3.00 per week. That is less than the cost of one person spending 15 minutes writing up notes from a single meeting.

Latency is rarely the binding constraint for meeting notes because processing happens after the meeting ends, not synchronously during it. If you are building a live transcription pipeline that processes each speaker turn as it arrives, use Haiku for its lower latency and switch to streaming output (see Part 26: Streaming Responses with Claude).

Extending the POC

Connecting to Zoom or Google Meet transcript export

Both Zoom and Google Meet export transcripts as plain text or VTT files. Zoom’s format includes timestamps and speaker labels (Sara Malik: 00:02:14). Google Meet exports a simpler format. Write a thin parser that strips timestamps and normalizes speaker labels before passing the text to Claude. The transcript format does not need to be perfect: Claude handles slightly messy input well as long as speaker attribution is preserved.

Slack bot integration

A Slack bot that listens for a transcript paste (or a Zoom transcript URL) and replies with the structured summary in a thread is a natural extension. Use the Slack Events API, receive the message, call extract_from_transcript, and format the action items as a Slack Block Kit message. You can add a button for each action item that creates a Jira ticket on click. This is roughly 80-100 additional lines of Python beyond the core summarizer.

Multi-meeting trend analysis

If you store every meeting’s structured output in a database, you can run cross-meeting queries: which owner has the most overdue action items, which decisions have been revisited across multiple meetings (a signal of unresolved disagreement), or how many action items per meeting your team typically generates over a sprint. That analysis is a separate Claude call on the aggregated data, which is covered in the pattern from Part 2: Tool Use with Claude where Claude calls database query tools to answer questions about its own historical outputs.

Frequently Asked Questions

What transcript formats does this work with?

Any plain text format where speaker turns are distinguishable works well. That includes Zoom transcripts, Google Meet exports, Otter.ai exports, plain-text notes with speaker prefixes, and even rough manual notes like “Alex said he’d handle the migration.” The normalizer in the pipeline strips timestamps and standardizes speaker labels before passing to Claude. VTT subtitle files need a one-step parse to remove the timestamp lines, but the speaker content is usually clean after that.

How does the ai meeting notes summarizer handle multiple languages?

Claude handles multilingual transcripts natively. If the transcript is in Spanish or French, it will extract action items correctly and can output the JSON in the same language. If you need English output from a non-English transcript, add “Output all fields in English” to the system prompt. Note that name normalization against a roster still works regardless of transcript language because it matches on phonetic similarity, not exact string match.

What happens if a transcript is very long?

For transcripts over 15,000 tokens (roughly a 90-minute meeting), use a two-pass approach: split the transcript into 5,000-token chunks by time segment, extract from each chunk independently, then deduplicate the combined action_items list in a second call. The deduplication call is cheap: pass all extracted items to Haiku with instructions to merge duplicates and resolve conflicts. The extract_from_transcript function in the sample code handles single-pass extraction; the chunking wrapper is straightforward to add on top.

How accurate is the owner attribution?

On clean transcripts where the speaker explicitly assigns a task (“James, can you review PR #442 by Thursday?”), accuracy is 95%+. On less explicit transcripts where ownership must be inferred from context, accuracy drops to 70-80%. The roster injection helps significantly for the inference case because Claude can match first names to full names and recognize that “the backend team” resolves to two specific people. For high-stakes meetings, always have a human review the extracted action items before they are auto-created in Jira.

Can I use this to process audio files directly?

The current Claude API (as of mid-2026) does not accept audio files directly. You need a separate transcription step first: feed the audio through Whisper (OpenAI’s open-source model), AssemblyAI, or your meeting platform’s built-in transcription. Once you have text, the pipeline described in this article takes over. Whisper running locally on a GPU can transcribe a 60-minute meeting in 2-3 minutes. The combined cost (transcription plus Claude extraction) still comes in well under $0.01 per meeting for average-length calls.

Does this approach work for asynchronous stand-ups written in text?

Yes, and it is often even more accurate because written async updates tend to be more structured than spoken transcripts. The same script works without modification. If your team posts async standups in a Slack channel, you can aggregate the day’s posts into a single “transcript” and run the same extraction. The output will have action items attributed to the correct people with whatever due dates they mentioned. This is a common use case for engineering teams distributed across time zones.

How should I handle confidential meetings?

Meeting transcripts can contain sensitive information: compensation discussions, personnel issues, unreleased product plans, financial data. Before sending transcript content to any external API, including the Anthropic API, verify that your organization’s data handling policies allow it. For particularly sensitive meeting types, consider running an on-premises model or using Anthropic’s enterprise data privacy agreements. You can also pre-process the transcript to redact specific patterns (names with dollar amounts, specific employee names in HR contexts) before sending to Claude.

View the full AI in Production series index for all 30 parts.

Further Reading and References

• Anthropic tool use documentation: The canonical reference for defining tools, handling tool_use blocks, and forcing structured output.
• Anthropic prompt caching guide: How to mark blocks with cache_control and read cache hit metrics from the usage object.
• Anthropic research: Claude’s capabilities: Background on Claude’s instruction-following and structured extraction strengths.
• Anthropic Messages API reference: Full parameter reference for client.messages.create, including tool_choice and usage fields.