Matt's post-meeting automation system, and how to build your own

This note was drafted by Claude Code on 2026-11-02 from the notes and code of the system it describes, which is why it talks about Matt in the third person. It is a description for someone who wants to build their own, not an essay.

This is a description of what happens on Matt Handzel's computer after a meeting ends, written for someone who has never seen his setup. The first half is the design: what the system does, in what order, and the rules that keep it safe. The second half is how to build a version of it with off-the-shelf tools in an afternoon, and what the full version is made of. Nothing here needs you to use the same apps he does.

The idea behind all of it, in his words from the day the processing routine was first built (2026-10-06; the per-meeting notes and the transcript sync came earlier): "Identify what things Claude can do at the end of every single meeting, and make a [skill] to process a meeting." A meeting only pays off if what was said becomes something you do. Most of what is said in a meeting is lost within a day, and the part that survives is whatever someone remembered to write down. This system exists so that nothing said in a meeting has to be remembered, typed up or chased by hand.

1. The whole thing in one paragraph

Matt records a meeting with Wispr Flow, a dictation app with a built-in meeting notetaker. Within about 15 minutes the transcript is copied into his notes and tied to the calendar event it belongs to. A few minutes after that, a Claude session starts on its own, with nobody watching, and processes the meeting. It works out who the meeting was with, labels who said what, reads every earlier meeting and message with that person, adds notes to the shared document the two of them keep (without rewriting anything), sorts every action into mine / theirs / waiting on me, checks which ones are already done, does the ones a computer can do (research, memos, calendar holds), drafts every follow-up in his voice, puts each draft where it will be sent, puts his own actions on his task list or calendar, writes a dated line into the page he keeps for that person, and ends with one line in his daily note and a notification naming the one thing he has to do. Nothing is ever sent and nothing irreversible is ever done. Every action then sits in one list that re-checks itself against his real sent mail and messages until it is done.

His side of it is about two minutes per meeting.

2. What you get, and what you do

Everything else in this document is machinery. This is the surface.

What arrives after a meeting:

• A notification that the meeting was processed, or that the run has one question, or that it failed.
• A one-page summary per meeting. Its first line is "The one thing to do:" with a one-click link (the email draft, the shared doc, the calendar block). Below it: who the meeting was with and how that was worked out, what was read (which earlier meetings, which messages), mine / theirs / waiting on me, proposed changes to the meeting template, the other person's open comments, what could not be found or done, and a table of every next action with what was done about it.
• Drafts where they get sent. Email follow-ups are drafts in Gmail. Chat follow-ups land as unsent drafts inside the right chat. You read, edit if you want, and press send.
• The shared running doc, for recurring 1:1s: a new entry under your own notes, with the recording link, the next actions, and "Notes from the call", plus the next meeting's section already made and pre-filled.
• Your calendar and task list. Anything with a time or place is a block on your own calendar with the steps in its description. Anything for today is on today's task sheet. Anything for another day is in a "later" list that the end-of-day routine carries forward.
• One list of every open action from every meeting, with the latest verdict on whether it is done, in sections Yours / Waiting on them / Claude's / Done this week / Stale.
• The person's page, with a dated line for every meeting.

What you do, about two minutes per meeting:

1. Read the summary, click the one thing.
2. Send the staged drafts, or don't.
3. Answer the one question, if there was one.
4. Tick off anything you did in person or by phone that the system cannot see.
5. Say yes or no to the template changes it proposed.

Everything that can run on its own runs on its own. The rule Matt set on 2026-10-21: "it should not be manual for me."

3. The timeline of one meeting

4. Before the meeting: what the after-meeting run inherits

Three things exist before the recording starts, and the after-meeting run depends on them.

A note and a Doc per meeting. A background job reads the calendar every 30 minutes and, for every event in the next 7 days with at least one other attendee or a video link, writes a note from a template (purpose, prep, discussion points, action items per person, debrief) and makes one Google Doc from it, shared by link so the attendee can take notes in it too. The job never makes a second Doc for the same event, and it never overwrites what someone typed into the Doc.

The rule this creates: that Doc is visible to the attendees. Nothing private ever goes in it: no transcript, no prep about the person, no notes on your other options. The transcript lives in its own file for this reason.

Commands for the parts you start yourself. One command opens the right Doc before a meeting and, if its prep section is empty, starts a background session that fills it. Another starts a meeting now: a calendar event with a video link, the note and Doc, the notetaker, and live sync between the note and the Doc for the length of the meeting. A small job keeps the meeting's title in step across the calendar, the Doc and the note: whichever side you renamed wins.

Meeting types. The prep depends on the kind of meeting. Matt's 25-minute calls helping people at AI safety organisations use AI more (booked through a scheduling link) get a private per-call template prefilled with the booking answers; everything else gets the default brief. The same type test decides what extra work happens after the call (section 12).

The prep brief reads the person's page, the full message and email history with them, earlier meetings, anything they sent, and what your own project notes say you want from them, and writes one page you can read standing up. The rule Matt set after the first one: "the meeting is the context." History older than about two months collapses to one line unless it bears on this meeting.

5. During the meeting: a live assistant

Until this piece, every part of the system started after the meeting ended. The live assistant is a small local web page that runs while Wispr Flow records. It reads the transcript Wispr writes to disk during the call, about 5 to 10 seconds behind speech, and every 45 seconds asks a small, cheap model to turn the new lines into at most three cards: a request addressed to Claude ("Claude, look up…"), something worth looking up, a question aimed at Matt, a to-do, a commitment. Requests and lookups run in a read-only session that can search his notes, his message history and the web, and show the answer as a card. It has buttons for "what should I say?", "ask about the conversation", "recap" and "follow-ups".

What matters for the after-meeting run: the live assistant keeps a hand-off file (summary, to-dos, commitments, requests, answered lookups) and the after-meeting session reads it first, so nothing spoken has to be rediscovered. It never sends or writes anything outside its own folder.

6. Minutes after: the transcript reaches your notes

The transcript copy. Every 15 minutes a job reads Wispr Flow's local database and writes one note per recording into the notes folder: Wispr's summary plus the full speaker-attributed transcript, with the meeting id, the calendar event id, the share link and whether the speakers were identified. It then adds a "Recording" section to the meeting's note (which the Doc sync carries into the shared Doc) and a list of the day's meetings to the daily note. Both sections are marked and replaced in place; nothing else in those notes is touched. It polls rather than watching the file, because Wispr writes a rough transcript during the call and a refined one later, and a file watcher would copy the worst version.

Two things to know about transcripts. A recording where the app could not identify the speakers comes through as "Speaker 1 / Speaker 2", and the numbers are not stable within one recording. One early call swapped them halfway, which is how the app's own summary gave Matt's action items to the other person. And a meeting recorded in two takes gets two files rather than the second overwriting the first.

Tying recordings to the calendar. A second job matches every recording to a calendar event: the app's own link if the notetaker was started from the event, else the event that shares the most time with the recording (with guards so a 4-day workshop or an 11-hour conference does not swallow every session inside it), else a new event on your calendar spanning the recording, titled with the recording's title. Matt's ask, which this implements word for word: if there is an event, the notes stick to it; if there is nothing on the calendar, a new meeting appears for the time the notes were taken. Before this, no in-person conference 1:1 ever got its recording linked.

The recording's share link goes into shared places (the Doc, the running doc, the event description) because the notes app answers that link with "not found" to anyone who is not logged in as Matt, unless he shared that one recording on purpose. Check your own notes app before copying this.

7. The listener: the trigger

A script runs every 2 minutes and decides whether a meeting is ready to process. Ready means: the recording is finalized, the refined transcript is done and uploaded, 4 minutes have passed since both, and the meeting ran at least 5 minutes. (If the refined transcript never arrives, the rough one is processed an hour after the meeting ends.) Only meetings that ended after the listener was installed count, so there was never a backlog to clear.

For each ready meeting, in order:

1. Refresh the transcript copy for that one meeting, so the processing session reads the refined version instead of waiting for the next 15-minute tick.
2. Gate. One call to a small, cheap model (about a tenth of a cent) classifies the transcript as one-on-one, group where Matt took part, audience, solo, or test. Only the first two go on. Tested on nine past recordings: it kept the 1:1s, a group session and a dialogue Matt presented in, and skipped a workshop he only watched.
3. Label the speakers and, for his AI uplift calls, grade the call (section 12).
4. Process. One background Claude session at a time, with the processing routine (section 9) and a brief that adapts it for nobody watching. Meetings that finish back to back queue up, oldest first. One at a time keeps two sessions from editing the same task sheet or calendar at once.
5. Heal. A session can die on something unrelated to the meeting: not logged in, no network, the service overloaded, the laptop asleep. Each pass reads the running session's log; if its last message is one of those errors, the listener resumes the session after 5, 15 and 45 minutes, then every 2 hours, and gives up after 72 hours with a notification. Before anything starts it checks that the network is up and the account is logged in; offline it waits quietly, and logged out it sends one notification per outage. Before this was added, four meetings in a row sat unprocessed on a login error and nobody noticed for days.

A session ends by marking the meeting done, asked (it has one question for Matt), skipped or failed. One that stops without marking is flagged for a look rather than retried.

8. Who was it with, and who said what

Two different questions, two different tools.

Who the meeting was with. In-person meetings reach the notetaker with no attendees, and video calls often carry only an email handle. Matt's instruction: "it should look on the calendar to see if there was a meeting with someone, or we / i may say their names during the meeting." A small script weighs four signals and prints the evidence for each: calendar events within 45 minutes (title, attendee emails, notes); names said in the transcript (known names, self-introductions); the candidate's company, role and city found in what was said, fuzzy-matched because transcription mishears names; and messages with the candidate around the meeting time. Checked against 78 stored transcripts: it named the right person on every one where the app knew the attendees, and picked the right person over the overlapping calendar slot on the one where it didn't.

When that is not enough, the run has a fixed list of things to try before it asks: rule candidates out by their own recent messages (someone who had texted him good luck for the conference was not at the conference), score the event roster's bios against what the person said about themselves, check earlier contact with each candidate, and look at what Matt did in the 30 minutes after (who he messaged, which profile he opened). It writes one line per step. Only if that leaves it open, and the answer changes whose page the meeting goes on or who a draft is addressed to, does it ask one question, with numbered guesses, best first, one line of evidence each. This list exists because an early run offered three people with the same first name and stopped; the evidence to settle it was two searches away.

Every attendee is then matched to their page by one shared resolver, never by eye. It handles people who share a name, usernames, and email addresses, scoring on when Matt was in touch with the person, who else was in the meeting, what the transcript mentions, and messages arranging to meet in the days before. An unsure match is held for Matt to confirm, never written to anyone's page. Writing a meeting to the wrong person's page is worse than writing nothing.

Who said what. Most recordings arrive with unresolved speakers. A labelling step reads every turn and labels it as Matt, a named person, other, or unclear, with a confidence and the cue it used. It recognises Matt from a rolling model of who he is right now, rebuilt every morning from his last three weeks of notes, his own words in earlier meetings, his bios, his calendar, his active projects and the phrases he dictates. Every fact in that model carries dates and a decaying weight, so a new job or a program ending follows within a day, and nobody edits a profile by hand. The labeller first lists anchors (turns whose own words identify the speaker, such as naming their own job or where they live), then stretches where one mapping holds, then labels every turn; a turn is only marked high confidence when a strong anchor nearby agrees.

The output goes in a sidecar file plus a summary table at the end of the transcript note. No existing line of the transcript moves, because other tools cite transcript lines by number. The rule every downstream reader follows: trust only the high-confidence labels; everything else is unknown until checked against the content. Cost: about 26 cents per meeting, and about 45 cents a day for the self-model when its inputs changed.

9. The processing routine: what the session actually does

This is the core. It is a written procedure, about 300 lines, with the reason behind each rule recorded beside it. Matt runs it by hand sometimes; the listener runs it after every meeting.

Classify. A recurring 1:1 with a running doc gets every step. A high-stakes one-off (an interview, a funder, a first meeting with someone senior) gets most of them plus a longer written debrief. A group or social meeting gets the transcript, the calendar and the drafts only. The tier depends on who it was with, so identification comes first.

Get the full transcript and the context. The transcript copy first, checked for completeness: the last timestamp should be near the meeting's length and the last lines a goodbye, because a copy made mid-call stops mid-call. The other person's notes if they sent any (section 13). The meeting note, with the reminder that its Doc is shared. The running doc, read by section, with the other person's open comments noted. What was promised last time. The doc is read twice, at the start and again right before writing, because both people keep editing after the call; an early run missed a bullet Matt added after it had read the doc. Every earlier meeting with the person, searched by name and by date rather than by title, because titles are often wrong, plus the person's open items in the action list. Messages since the last meeting and after this one, because a commitment made in chat counts and the texts right after a call often carry the real feedback. And a search for an existing tool before planning one, because one run planned a newsletter setup that already existed.

Fill the running doc without rewriting it. Never push a whole document over one that someone else comments on: it orphans their comments and can wipe what the other person typed during the call. A small script only appends to the end of a section, inserts above a named paragraph, or adds a new section, and it refuses to write if the document changed since it read it. The entry goes under your own notes: the recording link first, then the next actions with who and which day, then "Notes from the call", with the other person's key feedback quoted word for word. Their comments are listed for you, never answered on your behalf.

Sort every action. From every source, not just the transcript: every section of the doc entry including the agenda items never reached, all comments and replies, bullets added after the call, texts and emails from either side after the call, and what is still open from earlier meetings. Each item is mine, theirs, waiting on me (someone outside the meeting now waits on you because of it), advice rather than action, or something a computer can do. Before anything is listed, it is checked against the record: a search over sent mail, sent messages, calendar invites and shared files answers done / partly / not done / can't see. This rule exists because a run once asked Matt to send someone a recording he had already shared. The computer-doable items are then done in the session, with background agents for anything long.

Find every next action, then work each one. The promises are only the start. The run reads the transcript a second time with one question, "what would a good chief of staff start on tonight because of this conversation?", and lists candidates in nine kinds: promises; questions raised and left open; things to look up; intros implied; decisions you now owe; prep for the next touchpoint; material the conversation produced; facts that changed; agenda items never reached. Each survivor is worked to the last reversible step: the staged message, the written memo or brief, a real answer with sources read, a calendar hold on your own calendar, a pre-filled task, and only then a one-line item for you saying exactly what to do and why the computer could not. The budget is about the meeting's own length, up to twice that for a funder, an interview, a hire or a promised deliverable, down to 10 to 15 minutes for a hallway chat; drafts first, research last. This step was added after a lunch where the run found one promise, gave a question Matt had raised a single web search, and waited on the other person's email before preparing the thing the email was for.

Put your actions where you will do them. Today's go on today's task sheet, with the meeting's quotes as the reason. Another day's go in a "later" list. Anything with a time or place goes on the calendar in the same pass, at its anchor (the train, the flight, the meeting), with a description that needs no other app: line 1 the action with a one-click link, then the steps or the draft text inline, a done-when and a why. Matt's words after a train review was left unscheduled: "You should have scheduled that in my calendar so that, on the train to DC, I know that I'm doing a weekly review."

Draft the follow-ups. Every message the meeting created, in your voice, checked against past messages to that person for tone. No commitments you did not make: an offer that might be welcome goes in [brackets] as your choice. This rule came from the other side of a meeting, by text, within the hour: the person asked that the assistant stop making commitments on Matt's behalf. Every email goes through a second, adversarial read before it is staged. Then each draft is staged where it gets sent (section 10). Never sent.

Turn what the meeting taught about meetings into the template. What did the other person have to ask for, correct or dig out that a better page would have given them up front? Each answer becomes a proposed change to the meeting template, with the quote and the date. These are proposals; the summary names each one so you can veto it.

Prep the next meeting with the same person. A new section from the template (never a copy of the last one, which once kept the old date), filled with this meeting's actions, the days to fill in, what was cut short, and draft actions per goal marked as drafts. A 15-minute prep block goes on the calendar right before the meeting with the section's link as line 1.

Write to the person's page. Mandatory: one dated line per meeting, linking the summary and the transcript, for every attendee. A meeting without this line is not processed. New facts about the person go on their page; a procedure you taught during the processing goes in the assistant's memory.

Report. For a headless run, the report is the "Summary for Matt" at the top of the summary file: how the person was identified, when the doc was re-read, how many earlier meetings and which messages were read, that every section and comment was covered, which actions are done and which are still running, which time-bound actions are on the calendar, and a line naming what could not be read and why. A failed fetch is a hole, never "they didn't mention it".

What changes when nobody is watching. No questions mid-run (one question at the end, after the meeting is marked "asked"); no driving the browser, the clipboard or the screen, because you may be using them; shared Docs through the append-only script only; no sends; a missing connector is written into the summary rather than stopping the run. The brief also makes the run check first that you did not already process the meeting by hand, and read the live assistant's hand-off.

10. Follow-ups: staged where they are sent

A run never leaves a draft in the summary as "paste this into the app". Matt's friction audit, 2026-10-22, retired that pattern.

• Email becomes a Gmail draft, on the thread if it is a reply. The summary links it.
• Chat, on any network, goes into a queue: one record per draft with the person, channel, text, source and status.
• Chat drafts land on their own. Every 10 minutes a job writes each pending draft into its chat as an unsent draft, with no window focus and no questions. Matt: "it'd be good if they were to run on their own automatically. Of course, it should never send anything automatically." The chat app refuses a draft over one already in the chat, so your own half-written messages are never overwritten. A staged draft turns "sent" on the next pass once you have posted in that chat, or "skipped" if you cleared it. A notification goes up only when something was staged.
• One conference app has no way to stage a draft without a browser, so those wait for a one-click command that copies the text, opens the chat and asks Sent / Skip / Later.

Matt uses Beeper, which puts every chat network in one app and exposes each chat's draft to local scripts. Any app that lets a script set a draft without sending will do.

11. After the run: the list that keeps checking

Before this piece, every processed meeting left a summary file and nothing read them again, so nobody knew which items got done.

Every 30 minutes a job keeps one list of every action from every meeting. For each new summary file, a model extracts the items: text, owner (me / them / the assistant), counterpart, due date, status, and the matching staged draft. An item linked to a chat draft closes when the draft was seen sent. Open items are re-checked against sent mail, sent messages and the calendar, each at most every 6 hours, and only while they are under 45 days old. "Done" closes an item; "partly" marks it; "not done" and "can't see" leave it open with the reason shown. The list is rendered in sections: Yours / Waiting on them / Claude's / Done this week / Stale. Matt ticks a box for done or drop, and the next pass reads his ticks first and never overrides them. "Can't see" is common for things done in person or by phone; ticking is the fix. On the day this was written the list held 261 open items from 46 meetings.

The processing routine reads this list for the person at the start of every run, and closes items the new transcript shows were done.

12. Meeting types with extra work: the AI uplift calls

For Matt's 25-minute calls helping people at AI safety organisations use AI in their own work, the listener does two extra things, because the follow-up is the call's real deliverable.

Grading. A script scores the transcript against a 27-item rubric of what a very good call is from the client's side and from Matt's: measured numbers (talk share, long monologues, how much of the first three minutes he spent talking, whether it ran over) plus a model's judgement on the rest, every score with a timestamped quote, and the biggest miss. The scorecard is emailed to him. The first one scored badly (47% of the words were his, four turns over 100 words), which is the point.

The follow-up pack. Four sections, researched in parallel with a budget of about twice the call's length: every question the person asked, with what Matt said live and the real answer with its source, plus a correction where he was wrong; every place he hedged or guessed, with the right answer and one thing to read before the next call (only he sees this); the person's main tasks, how they do each one now, and how AI could do each one much better; and a setup document the person can get through in one sitting with their own Claude walking them through it, made into a Google Doc. The follow-up message is then: thanks, their questions answered, the setup doc, the one task from the call, and a feedback form. It delivers the write-up instead of promising one.

13. What other people send you

When someone sends a transcript or notes from the same meeting (a Granola link, a Plaud transcript by email, Google Meet's notes), a job that runs every 5 minutes finds it in your mail and chats, fetches it, stores it next to your own transcript with who sent it and when, links it from the person's page and the meeting note, and makes it searchable. A link it cannot open on its own (a sign-in wall) is put in front of you once, in the daily note and the end-of-day routine: you say save or drop, and never run a command. The processing routine reads these at the start: with no recording of your own, the other person's file is the transcript; with one, it is a second view with their summary and their action items.

14. The hard rules

These hold for every run, by hand or headless. Each one came from a specific day.

• Never send. No message, email, reply, reaction or comment that others can see. You press send. Drafts are staged, never sent, even by the 10-minute job.
• Nothing irreversible. No payments, RSVPs or subscriptions; no calendar events with other attendees and no invites; no sharing or permission changes; no deletes of anything the run did not create; nothing pushed to a shared branch. When a step needs one of these, the run stops one step lower and writes the exact remaining click for you.
• Shared documents are append-only. Never overwrite a document someone else comments on.
• Nothing private in the attendee-shared Doc. Transcripts, prep and your options live elsewhere.
• No commitments you did not make in any draft; offers go in [brackets].
• Check the record before listing an action. A done item never appears in a draft or a question.
• Try before asking. Every step of the "before you ask" list, written down, before one question, and only when the answer changes what gets written.
• Trust only high-confidence speaker labels. Quotes are verbatim and attributed to the right speaker, checked against the content.
• Every attendee gets a line on their page. Otherwise the meeting is not processed.
• Paraphrase other people's messages in anything you keep; never paste their text into shared or long-lived files.

15. Building your own: three levels

You do not need any custom code for most of the value. The design transfers; the tools are up to you.

Level 1: one scheduled task (an afternoon). You need a notetaker with a connector your assistant can read (Wispr Flow and Granola both have one for Claude), your email and calendar connected, and a place to keep notes (a folder in Google Drive is enough). Then one scheduled task, every weekday at the end of the day, with a prompt that does the core of section 9: find today's meetings with other people; work out who each was with; read the whole transcript, your last meeting with them and any mail since; sort what was said into mine / theirs / waiting on me / advice, with the quote for each; drop what you already did; go through the transcript again for questions left open, things to look up, intros implied and decisions you owe, and do that work; put your actions in your task tool and fixed-time ones on your calendar as holds; draft the follow-up as an email draft in your voice, with any offer you did not make in [brackets]; add a dated entry to a per-person notes document (named "Notes: " plus their name); and report one block per meeting, "the one thing to do" first, with at most one question. Rules at the end: never send, never delete or rewrite what you did not create today, never touch a shared doc except to add to its end, never create anything others can see.

That one task gives you perhaps 70% of what Matt's system gives him. Claude's scheduled tasks run even when your laptop is asleep.

Level 2: a few more tasks (a weekend). A morning task that re-checks every open action from the last 45 days against your sent mail and calendar and keeps one list. A prep task that runs an hour before any meeting with one outside attendee and writes a brief from the person's notes document, your mail with them and your own project notes. A per-person notes document that both tasks read and append to. A template for recurring 1:1s that the end-of-day task appends to rather than rewrites. At this level you have most of sections 4, 9 and 11.

Level 3: the full version (weeks, and a reason to want it). Everything runs from a recording ending rather than from a clock, so a meeting is processed minutes after it ends. The speaker labelling, the live assistant, the chat-draft staging, the grading for a meeting type you care about, and the record of everything you have sent so the done-check is reliable. This is where custom code starts: background jobs on your computer, a local copy of your messages and mail, and an assistant that can run scripts. Build it only when Level 2 is in use every day and you can name the thing it still makes you do by hand.

16. Running it after each meeting, not at the end of the day

The end-of-day task in Level 1 is the right first step. The reason to go further is timing: a follow-up drafted while the conversation is fresh, and before the other person sends theirs, is worth more than the same draft at 5:30. Three ways, cheapest first. All three use the same task text; only its first sentence changes.

A. Run the task every hour. Both kinds of Claude scheduled task offer hourly as a preset (the Cowork ones and the Claude Code ones), and both run in the cloud, so your laptop can be closed. Change the task's first instruction to: "Process every meeting that ended more than 10 minutes and less than 2 hours ago and that has no entry dated today in its Notes doc; if there is none, stop." The 10 minutes is for the notetaker to finish its transcript. The Notes-doc entry is the marker that stops a meeting being processed twice. Most hourly runs find nothing and end in a few seconds. Latency: up to an hour.

B. Fire the task when a calendar event ends. A Claude Code scheduled task can have an API trigger: its own URL and a token, and an HTTP POST to that URL starts a run and hands the task whatever text you send (the endpoint). Make the task at claude.ai/code/routines (New task, Set up manually), paste the task text as its instructions, change the trigger from Schedule to API, leave Repository as None under Advanced settings (an API task needs no repository), and on the Connectors tab keep only the connectors it needs (notetaker, Gmail, Calendar, Drive, your task tool). The token is shown once when you click Create; copy it with the URL. Then something has to make that POST a few minutes after each meeting. Two options:

• Free, 30 lines: a Google Apps Script on a 5-minute timer that looks for calendar events that ended 10 to 25 minutes ago with at least one other guest, and POSTs each one once. Paste the script below into a new Apps Script project, put the task's URL and token in its Script properties, add the time-driven trigger, and authorize Calendar and external requests when asked.
• No code, paid: a Zapier Zap with the Google Calendar "Event Ended" trigger and a Webhooks by Zapier POST action (a premium app on Zapier) with the same URL, headers and body as the script.

Why those numbers. The 10-minute floor is for the notetaker: it finalizes the recording and uploads a refined transcript a few minutes after the call, and Matt's own listener waits 4 minutes after that before it starts. The timer interval only adds jitter on top of the floor: a 5-minute timer fires 10 to 15 minutes after the meeting, a 15-minute timer 10 to 25. Apps Script timers can run as often as every minute and this run takes about two seconds, so a 5-minute timer costs about ten minutes of script time a day, well inside the free quota. The window stays 25 minutes wide on purpose: Google's timers start at slightly randomized times and can run late, a wide window means a later tick still catches the meeting, and the "fired:" key the script stores stops a second tick firing it again. To go below 10 minutes, add to the task text: "If the recording has no transcript yet, wait two minutes and check again, up to ten minutes." Then a 5-minute floor with a 5-minute timer gives 5 to 10 minutes.

Setting it up, as it actually went (2026-11-02, Matt's account).

1. At claude.ai/code/routines: New task, Set up manually. Name, instructions, Trigger row changed from Schedule to API ("Token will be generated when you save"). Advanced settings: General tab shows Repository: None ("Picking a repository makes this a Claude Code task"), so an API-triggered task needs no repository; Connectors tab lists every connected connector by default, each with a remove button. For the test every connector was removed and the prompt was "reply with the trigger text you received and stop".
2. Create opens an "API token" dialog with the token and a Copy button. It is shown once. If the dialog gets closed first, the task's edit dialog has Regenerate next to the API trigger (docs). The fire URL is the task's id in the path: https://api.anthropic.com/v1/claude_code/routines/<task id>/fire.
3. A POST from the command line with Authorization: Bearer <token>, anthropic-version: 2026-10-21, Content-Type: application/json and a {"text": "..."} body returned 200 with a session id and URL in under a second. The run's log shows the saved prompt as the first message and the POSTed text as a second message, wrapped as routine-fire-payload with a note that it is data, not instructions. So the task's own prompt has to say what to do with the trigger text, which is what the sentence above does. The run echoed the text back word for word and finished in 4 seconds.
4. At script.google.com: New project, paste the script, rename, save. Project Settings, Script properties: Add script property twice (FIRE_URL, FIRE_TOKEN), Save script properties. Running the function once from the editor opens Google's authorization (choose the account, Advanced, go to the project, Allow): the scopes are Calendar and external requests.
5. A nine-minute test event with one guest was put on the calendar, ending 14 minutes before the manual run. The run took 1.8 seconds and the task's run list showed a new session 1.5 seconds after the script started, with the title, ISO start and end times and the guest exactly as the script built them. The script also stored its fired:<event id>:<end time> key as a new script property, which is the double-fire guard.
6. Triggers (the clock icon), Add Trigger: function, Head, Time-driven, Minutes timer, Every 5 minutes, Save. Saving opens a second Google authorization popup. When the page is driven by automation the popup is blocked and the page says "Script authorization failed. Please check your pop-up blocker settings"; a real click on Save worked. The trigger then shows as "Time-based" on the Triggers page, and its first run on its own appeared on the Executions page 10 minutes after it was saved ("Time-Driven", 1.1 seconds, Completed), finding nothing to fire because the test event was by then outside the window. The Executions page lists every run with its duration and status, and is where to look when a meeting was not processed. In the second test, later the same day, saving a new trigger opened no popup at all, because the project was already authorized: expect the popup the first time only.
7. The event source menu in that dialog also offers "From calendar", which fires when a calendar entry is created or changed, not when one ends, so it does not replace the timer.

Second test, the whole pipeline (2026-11-02, 11:45 to 12:23 PT, Matt's account). The first test used a task that did nothing but echo the trigger text. The second used the real task text from section 15, with the Wispr Flow, Gmail, Google Calendar and Google Drive connectors attached, and a calendar event that mirrored a real recording (a 25-minute AI uplift call from the previous week, re-dated to today; one line at the end of the task text said so).

1. The task was created through the routines API with the connectors, then switched to the API trigger in its edit dialog (Trigger: Schedule to API). The token is made with "Generate token" in that dialog, shown once with a copy button, and nothing needs saving afterwards: the Fire URL turns "Active" on its own, and "Regenerate" and "Delete token" sit next to it from then on.
2. The Apps Script got the new task's URL and token as script properties, and the 5-minute timer was added again. This time the trigger saved without any popup, because the project had been authorized earlier in the day.
3. The test event ended at 12:07:00. The timer ticked at 12:11:38 and 12:16:38 (the event was then 9 min 38 s old, under the 10-minute floor) and fired at 12:21:38. The run started at 12:21:40, 14 minutes 40 seconds after the meeting ended, and finished at 12:22:37: 57 seconds, 14 turns, on Sonnet 5.5.
4. What the run did: found the recording in Wispr by title, read the whole transcript (two pages, about 60,000 characters), searched Gmail for mail to or from the person (none sent, so no promise counted as done), looked for their Notes Doc (none yet), created the Gmail draft (unsent, to the person's work address, which it took from the booking invite), created the Notes Doc with a dated entry (five lines on what was discussed, what each side owes, the draft's name, and what was shared in confidence and must not be repeated), sent a push notification to the phone with the one thing to do, and reported in the format the task text asks for: the one thing first, then mine / theirs / waiting / advice, the open items from the second pass, what it could not do, and one question (which dates to put in the draft) with its own guess.
5. What it got right against the real run of the same meeting (Matt's local version from section 9, which took about an hour): the same four promises, the same two things the other person owes, the same open question, the confidentiality note, no sends, nothing irreversible.
6. What it missed: depth. The draft was a skeleton, four promised items each with a "[date?]" bracket and no content, where the real run wrote the six suggested next steps, the tools list and the blurb into the draft itself. It did no research on the open questions ("none called for outside sources", it said; the real run looked up four of them with sources). Two causes, both fixable in the task's settings and text: the run used the default model (Sonnet, though the edit dialog labels the default as the top model), and nothing in the task text set a time budget. The brief now names the model and adds a budget line: spend about as long as the meeting lasted, drafts first, research last, and write the answers into the draft, not a placeholder.
7. Latency: 14 min 40 s here, because the event ended 22 seconds after a tick. With a 5-minute timer the range is 10 to 15 minutes. A 1-minute timer would give 10 to 11 minutes for about 50 minutes of script time a day, still inside the free quota.

What this costs. Each fire is one Claude session on your plan's usage. The script and the timer are free. The task was left with no repository, so each run starts in about 5 seconds.

// Fires your Claude scheduled task for every meeting that ended 10 to 25 minutes ago.
// Run it every 5 minutes: clock icon in the left bar (Triggers), Add Trigger, Time-driven, Minutes timer, Every 5 minutes.
// Put the task's URL and token in Project Settings > Script properties as FIRE_URL and FIRE_TOKEN.
function fireForEndedMeetings() {
  var props = PropertiesService.getScriptProperties();
  var url = props.getProperty('FIRE_URL');
  var token = props.getProperty('FIRE_TOKEN');
  var now = new Date();
  var from = new Date(now.getTime() - 25 * 60 * 1000);
  var to = new Date(now.getTime() - 10 * 60 * 1000);
  var events = CalendarApp.getDefaultCalendar().getEvents(from, now);
  events.forEach(function (e) {
    var end = e.getEndTime();
    if (end < from || end > to) return;                              // did not end in the window
    if (e.isAllDayEvent() || e.getGuestList().length === 0) return;  // nobody else was invited
    var key = 'fired:' + e.getId() + ':' + end.getTime();
    if (props.getProperty(key)) return;                              // already fired for this one
    var guests = e.getGuestList().map(function (g) { return g.getEmail(); }).join(', ');
    var text = 'A meeting just ended. Title: "' + e.getTitle() + '". From ' +
      e.getStartTime().toISOString() + ' to ' + end.toISOString() + '. Guests: ' + guests + '.';
    UrlFetchApp.fetch(url, {
      method: 'post',
      contentType: 'application/json',
      headers: { 'Authorization': 'Bearer ' + token, 'anthropic-version': '2026-10-21' },
      payload: JSON.stringify({ text: text })
    });
    props.setProperty(key, '1');
  });
}

C. Watch the recording itself. This is Matt's version (section 7): a job on his own computer reads the notetaker's local database every two minutes and starts the run when the transcript is final, so a meeting that was never on the calendar, or that ran long, is still processed within about five minutes of ending. It needs a computer that stays on and a script to maintain, and it is the step at which you also get the speaker labelling and the chat drafts. Build it after B is running every day and you can name what B still misses.

17. What the full version is made of

For the curious, in plain terms. Matt's version is about fifteen small background jobs on his Mac, each a script of a few hundred to a thousand lines, plus one written procedure the assistant follows.

• The notes are a folder of plain-text files. Meetings, transcripts, summaries, the per-person pages and the action list are all files in it, so every tool can read and write them and nothing is locked inside an app.
• The assistant is Claude Code, started in the background by the listener with the procedure and a brief as its instructions. One session per meeting, one at a time. A smaller, cheaper model does the classification and scanning jobs; a mid-sized one labels speakers and extracts actions; the large one does the processing.
• The record is a local database that copies every message from every chat network, every email, every calendar event, every recording, and what was on screen, every few minutes. The done-check, the person matching and the "who was it with" search all run against it; the searches are local, and a done-check's verdict is one small-model call of 5 to 20 seconds. The store itself never leaves the machine; what does leave it is the handful of matching rows, or the transcript passages, sent to a Claude model for a verdict or a label.
• The connectors are the stock ones: Gmail for drafts, Google Calendar for holds and events, Google Docs for the shared documents, the notetaker for transcripts.
• The costs, at list price: about a tenth of a cent per meeting to classify it, about 26 cents to label speakers, about 45 cents a day for the self-model when its inputs changed, around a dollar a day in done-checks at a few hundred open items, and one large-model session per meeting on top. On a subscription these count against usage rather than billing.

18. What went wrong, and the rule each failure made

The system is mostly a list of mistakes with a rule attached. The ones that transfer:

• The run read the shared doc once, early, and missed what the other person added afterwards. Rule: read the doc again right before writing.
• It never searched earlier meetings and so missed about fifteen open items from the previous month. Rule: every earlier meeting with the person, searched by name and date.
• It skipped the pasted messages and the agenda items the call never reached. Rule: every source, not just the transcript; unreached items carry forward, never vanish.
• It missed the texts sent right after the call, one of which was the other person asking that the assistant stop making commitments. Rule: messages after the call count, and drafts contain no commitments you did not make.
• It listed actions it could have done itself. Rule: do the doable ones in the session.
• It planned a system that already existed. Rule: search for the tool before planning one.
• It guessed the wrong person from the calendar slot, twice, and later stopped at three candidates. Rule: four signals with evidence, then a fixed list of things to try before asking one question.
• It asked to send someone a recording that had already been shared. Rule: check the record before listing any action.
• It left a train review unscheduled. Rule: anything with a time or place goes on the calendar in the same pass.
• It left drafts as "paste this into the app". Rule: stage every draft where it will be sent.
• It found one promise in a lunch and stopped. Rule: enumerate every next action and work each to the last reversible step, with a budget sized to the meeting.
• Nothing re-read the summaries, so nobody knew what got done. Rule: one list that re-checks itself.
• Four meetings sat on a login error for days. Rule: the listener checks the account and network first, and retries with growing waits.

19. Known gaps, honestly

• Dropdown menus in Google Docs cannot be made through the API, so the next meeting's section arrives without them and one browser step is left for a human.
• Speaker labels are machine-made; only the high-confidence ones are trusted, and the rest are checked by reading.
• The action list only knows meeting actions. Commitments made in chat or email that never came up in a processed meeting are not in it.
• "Can't see" is common for things done in person or by phone.
• The notetaker keeps about six weeks of recordings locally; older ones need its own search.
• Two improvements on the list and not built: a pass that fixes misheard names in a transcript before any tool reads it, and a short "unexpected feedback on how you ran the meeting" section in every summary.