A bot's one real skill was punctuality

A meeting bot's one genuine talent was showing up on time. It joined the call at the right minute, sat in the corner, captured audio, and left. The transcript and the summary were real work, but that work can happen anywhere and at any hour. The scarce, load-bearing thing a bot actually did was arrive.

The claim of this post is small. You can record meetings from Google Calendar without inviting anything to the call, and it stays about as effortless as a bot ever was. We argued elsewhere that the best meeting bot is no bot, and taking the bot out leaves one fair objection. If a bot was convenient because it knew when to appear, then a person recording by hand has to remember to appear, and the effort seems to move from the machine back to you.

The effort does not actually move back to you, and the reason is almost boring. The app records against your calendar, and the calendar already knows the start time. A bot's headline feature was reading your schedule and acting on it. You have the schedule. The app has the schedule. None of that requires a guest on the call.

So this is not a post about consent, or audio, or the ethics of recording, all of which we take seriously and cover in their own right. It is a post about launch ergonomics: the small mechanics of starting a recording at the right moment, and how those mechanics come out of your calendar instead of out of a bot.

To record meetings from Google Calendar, you open the event

The design choice is one sentence: recording lives on the calendar event. There is no separate record screen, no floating capture button off to the side, no standalone list of meetings that duplicates the calendar you already keep. You find the event, you open it, and you start the recording from inside it.

Concretely, that means opening the event's detail drawer and pressing Start recording there. It is not a one-tap control stamped onto the calendar grid cell, and that was a deliberate choice. A grid cell is a summary. Starting something that captures a room deserves a real open, a glance at who and what and when, and then a press.

Putting the control on the event is what makes everything downstream work. The event carries a title, attendees, a start, and usually an end. A recording that begins from the event inherits that context instead of asking you to retype it. The thing you are recording and the thing on your calendar are the same object, not two records you reconcile later.

Opening the drawer is not friction for its own sake, either. It is the moment you get to glance at the attendee list, confirm this is the meeting you think it is, and see the same details the recording will carry. The extra tap buys a small, honest checkpoint before anything starts capturing, which is the opposite of a bot that joined whether you were paying attention or not.

It is also why there is no clock-watcher hovering in the background. You are never asked to configure a recording in advance and hope it fires. You go to the meeting the way you already do, by looking at your calendar, and the control to record is sitting right there on the meeting when you arrive.

The button knows what time it is

A record button that lived on every event forever would be clutter. A meeting from last spring does not need one, and showing it there is just noise that makes the useful case harder to find. So the affordance is time-aware.

The record button is present before a meeting, during it, and for a while just after it ends. That window covers every honest reason you would start a recording: you are early and getting set up, you are live, or the meeting ran long and you began capturing a few minutes late. Across that whole span, the control is exactly where you expect it.

The just-after part matters more than it looks. Meetings do not end cleanly on the minute the calendar claims, and the most common late start is the one where you meant to record from the top and only reached for it once someone said something worth keeping. Leaving the button live for a stretch past the scheduled end is what turns that near-miss into a save.

Once a meeting belongs to a prior day, the button is gone. Yesterday's standup is history, not something you are about to record, so the affordance retires itself. This keeps the calendar honest. A record button is a promise that something can still happen, and past days cannot.

There is one deliberate edge. When an event has no reliable end time, the affordance fails open and stays available rather than guessing wrong and vanishing on you. A meeting with a fuzzy end is exactly the kind that runs long, and the worst outcome would be the button disappearing while people are still talking. Given a choice between tidy and useful at the moment you need it, the button chooses useful.

One stream, whichever calendar it came from

Most people do not keep a single calendar. Work lives in Google, a personal or shared household calendar lives in Apple, and any given week is a mix of both. If recording lives on the event, then the app has to agree with you about what an event is, no matter where it came from.

Savory merges Google and Apple calendar events into one stream. It does this with a cross-source natural key, which is a way of recognizing that the same real meeting, seen through two different calendar systems, is one meeting and not two. A real event resolves reliably regardless of source.

Practically, that key is why you do not see the same meeting twice with two competing record buttons. If a standup lands in both your Google and your Apple calendar, the app treats the underlying instance as one event rather than a coincidence of two. You get a single place to start recording, attached to that one shared identity.

It is also why there is no separate meetings database quietly drifting out of sync with your calendar. The stream is your calendar, merged and de-duplicated, not a second copy the app maintains off to the side. That is one less thing to reconcile, because there is nothing to reconcile it against.

This reliability is the quiet foundation under everything above. The time-aware button, the context a recording inherits, the absence of a duplicate meeting list: all of it assumes that when you open an event, you are opening the real thing. And it is why the phrase record meetings from Google Calendar is shorthand, not a limit. Google is the common case, but the same event-first flow covers an Apple event sitting in the same stream.

Nothing to arrange the night before

The bot model carried a hidden tax that nobody printed on the box. To get a bot into a meeting, you generally had to arrange it in advance: invite it as a guest, or connect it to your calendar and let it auto-join everything, or remember to paste a link before the call. The convenience of it showing up was paid for the day before, in setup.

An event-first flow has no forward configuration at all. You do not schedule a recording. You do not pre-authorize a specific meeting the night before and hope nothing changed. The record button is a property of the event, so it simply exists whenever the event does, for as long as the time-aware window says it should.

This inverts where the effort sits. With a bot, you did a little work early so the machine could act automatically later, and then you accepted whatever it captured, including the meetings you would rather it had skipped. With Savory, you do no work early and make one deliberate choice in the moment. Auto-join is convenient right up until it records the one conversation you did not want on tape.

Zero setup ahead of time is the part that actually answers the objection. Recording by hand only sounds like more work than a bot if you picture the person also doing the bot's advance setup. Remove the setup, put the button on the event, and the by-hand path turns out to be shorter than the bot path ever was.

An optional nudge, and where it stops

Some people want a little more than a button waiting on the event, and that is fair. On macOS, Savory offers an optional reminder you can arm on a meeting so it prompts you when the meeting starts. It is opt-in and it is macOS-only. If you never want it, you never see it.

Be clear about what that reminder does when it fires. Tapping it defaults to opening the event, not silently starting a recording. The nudge brings you to the meeting with the record control in reach, and the decision to capture is still a press you make on purpose, in the moment. A reminder that started recording on its own would just be a bot with a friendlier name.

iOS has its own small convenience: a live now-and-next glance that shows what is happening and what is coming up. It is genuinely handy for orientation, but it is worth saying plainly what it is not. It navigates, it does not record. Tapping through takes you to the event, where the same event-first flow applies.

The honest version of the macOS story needs one more line. The menu-bar next-meeting row is not wired to live calendar data, and it does not start a recording of your next meeting. Neither the macOS row nor the iOS glance is a shortcut around opening the event. They are ways in, and the way in always ends at the event.

The pattern across both platforms is the same, and it is intentional. Every convenience Savory offers around timing points you at the event and then hands you the control. None of them pull the trigger for you. That keeps a bright line between the app helping you get to the meeting and the app deciding to record it, which are very different powers to hand a piece of software.

What this does not do yet

A post about ergonomics owes you the rough edges too. The event-first flow assumes a connected calendar, because without one there are no events to hang recording on. That connection is the price of admission and it is the whole mechanism, so it is not optional.

Two pieces are gated as we head toward launch. Live Google connect and Apple signing are pre-launch, which means the smooth end-to-end path of linking your real Google account and recording against it is not something we are going to overstate today. When we say record meetings from Google Calendar, we are describing the design as it is built, and being straight about which parts sit behind the launch gate.

There is also a real platform limit on iOS. If you background an in-progress recording, the recording ends. The meeting row survives and you keep what was captured, but from that point it is transcript-only, not a recording that quietly continued while you checked another app. On a phone, capture wants the foreground, and we would rather tell you that than let you assume otherwise.

None of this is hidden behind cheerful language. A feature that is opt-in, or macOS-only, or gated, or foreground-bound is more useful when it is described accurately than when it is dressed up. You can plan around a limit you can see.

Everything above is about when and how a recording starts. It says nothing about whether it should, and that separation is on purpose, because launch ergonomics and consent are different questions that each deserve to stand on their own.

Removing the bot did not remove the fact that a call has two sides. Making the record button convenient does not make the decision to record any less yours to own, or any less something the other people in the room have a stake in. Savory keeps recording on-device and treats consent as its own concern, handled through per-person recording consent rather than folded quietly into the convenience of a button.

The audio boundary sits exactly where it always did. What gets captured, where it lives, and who it belongs to are not questions the calendar answers. The calendar answers a smaller, more mechanical one: when is the meeting, so the record control can be there at the right time and then get out of the way.

If you want to feel how the event-first flow actually works, the place to look is Meetings mode. Open an event, find the record button that knows what time it is, and notice what is missing from the call. Nothing showed up, because nothing needed to.