How to automate meeting scheduling with an AI agent

To automate meeting scheduling properly you have to be honest about what booking links already solved. If someone can pick a slot from your calendar, that’s done — an agent adds nothing. The unsolved half is everything around it: the thread where three people negotiate a time, the reschedule that cascades, the request that shouldn’t be a meeting at all.

What the agent actually adds

Three jobs, in descending order of value.

Multi-party coordination. Finding a slot that works for five people across three timezones is a constraint problem with fuzzy preferences. This is where the time actually goes, and where a booking link stops helping entirely.

Reading intent from a thread. “Can we sync early next week about the migration?” contains a duration, a rough window, a topic and an implied attendee list. Extracting that reliably is the input to everything else.

Protecting the shape of your week. Not just finding a slot, but a good one — not fragmenting a focus block, not the fourth consecutive call, not 8am for the person in Sydney.

That third one is the difference between a scheduler and a good scheduler, and it’s almost entirely rules rather than intelligence.

Write the rules down first

Before connecting anything, write your scheduling policy explicitly. Most people have never articulated it, and the agent will schedule badly until it exists.

• Working hours, per day. Fridays may differ.
• Buffers. Minimum gap between meetings — 10 or 15 minutes stops the back-to-back day.
• Focus blocks. Windows that are never bookable, treated as hard constraints.
• Daily cap. After N meetings, propose tomorrow.
• Timezone fairness. For recurring cross-timezone meetings, rotate who takes the awkward hour rather than always defaulting to the organiser.
• Meeting types and default durations. 1:1 is 25 minutes, not 30 — that gap is the buffer.

The 25-minute default is the single highest-return rule in the list. It converts an unbroken wall of calls into a day with gaps, and nobody objects.

Connect calendars read-only first

Start with read access and let it propose without acting, for a week.

You’re checking two things: whether it reads availability correctly (recurring events, declined invites, all-day events and out-of-office are all easy to get wrong), and whether the slots it proposes are ones you’d actually pick.

Watch for the classic errors. A declined invite still blocking time. An all-day “PTO” treated as free because it has no busy status. A recurring meeting whose exceptions aren’t applied. Each of these produces confident, wrong availability, and each is worth catching before anything is on a real invite.

Timezones are where this breaks

More scheduling bugs come from timezone handling than from everything else combined.

Store and compute in UTC, display in each attendee’s local zone, and never do arithmetic on a wall-clock string. The specific trap: DST transitions. A recurring meeting at 9am London and 10am Amsterdam stays aligned — until the two zones shift on different dates and the meeting is an hour off for a fortnight. Compute each occurrence in the zone it was defined in rather than adding a fixed offset.

For a first meeting with someone new, prefer overlap windows that are civil for everyone — 15:00–17:00 CET is a reasonable Europe/US bridge — rather than technically-free-at-7am.

Draft the invite, don’t send it

This is the line worth holding. Finding the slot is a read; sending the invite is an outbound action that reaches other people, and it’s not reversible in any way that matters — an unsent invite is nothing, a retracted one is an email everyone got.

So the agent prepares: attendees, time, duration, title, agenda from the thread, video link. You glance and confirm. That’s two seconds against the thirty minutes of thread it replaced.

The approval must show the concrete details — “Thursday 14:00 CET with Ana, Ben, Chidi, 25 min” — not “send a meeting invite”. A vague prompt gets rubber-stamped, which defeats the point.

Rescheduling is the harder half

Cancellations get treated as an afterthought and they’re where the value compounds.

When something moves, the agent should notice what’s now affected: the prep block before it, the follow-up after it, the person who flew in for it. Propose the cascade, don’t just move one event.

Two rules keep this safe. Never move a meeting you don’t own without asking. And never silently drop attendees when a slot changes to accommodate fewer people — surface it, because that’s a social decision, not a scheduling one.

The setup, step by step

1. Write the policy — hours, buffers, focus blocks, caps, default durations.
2. Connect calendars read-only and let it propose for a week.
3. Fix availability bugs — declined, all-day, recurring exceptions, OOO.
4. Enable thread reading so requests become proposals automatically.
5. Turn on drafting with approval on every invite.
6. Add reschedule cascades, still approval-gated.
7. Auto-accept invites that fit policy — the one thing safe to fully automate.

Step 7 is worth calling out: accepting a meeting that already satisfies your rules is reversible and low-stakes, and it removes a surprising amount of daily clicking.

Velaris connects Google Calendar and Outlook this way — see the approval step in the demo. See also: the same pattern applied to email.