What is a meeting notetaker?

A small serverless system that turns a meeting recording into useful notes. You drop an audio or video file into a Drive folder; it transcribes the meeting, writes a short summary, and pulls out the decisions and the action items (who owns what, by when). Then it emails everyone a clean recap. It only summarizes what was actually said, and it flags any unclear owner or date for a human to confirm before the recap goes out.

How much does it cost to run?

About $4/month at typical small-business volume (around 40 meetings a month, roughly 30 minutes each). The fixed cost is essentially zero. The variable cost is dominated by transcription (Amazon Transcribe is billed per minute of audio), with a small sliver for Bedrock to write the summary and pull out action items. At 200 meetings a month the bill lands around $18.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with a Function URL for the approve-and-send button, Amazon Transcribe for speech-to-text, DynamoDB on-demand, S3 (with versioning), SES outbound for the recap email, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference, Sonnet 4.6 for long meetings) for the summary and the action-item extraction. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.

Where do the recordings live?

In a Google Drive folder you control, or dropped straight into an S3 bucket. One file per meeting, plus an optional sidecar text file listing who was in the room and the meeting title. A small drive-sync Lambda mirrors new files from Drive to S3 every few minutes; the pipeline reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.

Does the notetaker make things up?

No, by design. The summary and the action items are written only from the transcript. The model is told to quote or cite the transcript line behind every decision and every action item, and to never invent an owner or a due date that wasn't said out loud. Anything the model is unsure about — a vague owner, a fuzzy date, a decision that was only half-made — is marked as needs-confirm and held for a human to check before the recap is sent.

Who confirms the recap before it goes out?

The meeting organizer. The pipeline emails them a draft recap with every needs-confirm item highlighted. They can approve as-is, fix an owner or a date inline, or drop an item entirely. Only after they approve does the clean recap go to the whole attendee list. If the draft has no needs-confirm flags, the organizer can turn on auto-send for routine meetings — but the default is always a human in the loop.

What does the recap actually contain?

A short paragraph summary of the meeting, a list of decisions made, and a table of action items with an owner and a due date for each. Every action item links back to the moment in the transcript where it was said. Unclear items are listed under a needs-confirm heading until the organizer resolves them. Each recap is logged in the mn-runs DynamoDB table with timestamp, meeting id, attendees, and a snapshot of what was sent, so the trail is auditable later.

Series · 7 parts Published May 22, 2026

Meeting notetaker

A serverless notetaker that turns a meeting recording into useful notes. You drop in an audio or video file; it transcribes the meeting, writes a short summary, and pulls out the decisions and action items — who owns what, by when. Then it emails everyone a clean recap. It only summarizes what was actually said, and flags unclear owners or dates for a human to confirm. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A meeting notetaker on AWS for a few dollars a month

The whole system on one page — a recording intake, a notes engine, and a recap step, plus the rule that every line of notes traces back to something actually said.
02

How a meeting recording comes in

Three ways a recording enters the pipeline — a Drive folder you drop files into, a direct upload link, and an email-forwarding lane — plus the small sidecar file that names the attendees and the meeting.
03

How the transcript becomes notes

Amazon Transcribe turns the audio into text with speaker labels; then Bedrock writes a short summary and pulls out the decisions and action items, each tied back to a transcript line. Two passes, both grounded.
04

How the notes stay grounded

The four checks that keep the notes honest — cite-or-drop, owner resolution, date sanity, and a needs-confirm queue for anything the model isn’t sure about. Nothing invented ever reaches the recap.
05

How the recap reaches everyone

The organizer gets a draft to approve, fix, or trim; only then does the clean recap go to the whole room. Three actions on the draft: approve, edit, discard — each one logged.
06

What the meeting notetaker costs

A few dollars a month at SMB volume. Transcription is billed per minute of audio; Bedrock fires twice per meeting for the summary and the action items. No always-on compute.
07

Engineering reference: the meeting notetaker architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the Transcribe job config, EventBridge wiring, and the DynamoDB schemas.

What is a meeting notetaker?: A small serverless system that turns a meeting recording into useful notes. You drop an audio or video file into a Drive folder; it transcribes the meeting, writes a short summary, and pulls out the decisions and the action items (who owns what, by when). Then it emails everyone a clean recap. It only summarizes what was actually said, and it flags any unclear owner or date for a human to confirm before the recap goes out.
How much does it cost to run?: About $4/month at typical small-business volume (around 40 meetings a month, roughly 30 minutes each). The fixed cost is essentially zero. The variable cost is dominated by transcription (Amazon Transcribe is billed per minute of audio), with a small sliver for Bedrock to write the summary and pull out action items. At 200 meetings a month the bill lands around $18.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with a Function URL for the approve-and-send button, Amazon Transcribe for speech-to-text, DynamoDB on-demand, S3 (with versioning), SES outbound for the recap email, Secrets Manager, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference, Sonnet 4.6 for long meetings) for the summary and the action-item extraction. No API Gateway, no NAT Gateway, no always-on compute, no Knowledge Base.
Where do the recordings live?: In a Google Drive folder you control, or dropped straight into an S3 bucket. One file per meeting, plus an optional sidecar text file listing who was in the room and the meeting title. A small drive-sync Lambda mirrors new files from Drive to S3 every few minutes; the pipeline reads from S3 to keep Drive API calls predictable and to get S3 versioning for free.
Does the notetaker make things up?: No, by design. The summary and the action items are written only from the transcript. The model is told to cite the transcript line behind every decision and every action item, and to never invent an owner or a due date that wasn’t said out loud. Anything the model is unsure about — a vague owner, a fuzzy date, a decision that was only half-made — is marked as needs-confirm and held for a human to check before the recap is sent.
Who confirms the recap before it goes out?: The meeting organizer. The pipeline emails them a draft recap with every needs-confirm item highlighted. They can approve as-is, fix an owner or a date inline, or drop an item entirely. Only after they approve does the clean recap go to the whole attendee list. If the draft has no needs-confirm flags, the organizer can turn on auto-send for routine meetings — but the default is always a human in the loop.
What does the recap actually contain?: A short paragraph summary of the meeting, a list of decisions made, and a table of action items with an owner and a due date for each. Every action item links back to the moment in the transcript where it was said. Unclear items are listed under a needs-confirm heading until the organizer resolves them. Each recap is logged in the mn-runs DynamoDB table with timestamp, meeting id, attendees, and a snapshot of what was sent, so the trail is auditable later.

All posts

Frequently asked questions

Other series