Once AI Finds a Free Slot, a Person Decides Whether to Send the Invite

Larry

Mina wants to have dinner with two friends and asks the AI assistant in her calendar: “Find a weekday evening when the three of us are free.” A few seconds later, the AI finds Thursday at seven. The next moment, both friends’ phones light up with a meeting invitation titled with the placeholder name Mina had given the event in her calendar. One of them wanted to check with family first before committing, and now has to click “Accept” or “Decline” on a formal invite.

The AI didn’t pick the wrong time. The problem is that “find us a time” was treated as one job. It’s really three: checking shared free slots, holding time for yourself, and sending invitations to others. The first two disturb nobody; the third does. In a work setting, the people disturbed might be a client and a manager, and the invite title might be an internal code name. So AI should stop at proposing candidate slots by default, and before any invitation goes out, a person should confirm a preview that lists every detail of this particular invite.

Finding a time doesn’t mean sending the invite

From the user’s point of view, finding a time and sending an invite are one step apart, so letting AI finish both seems natural. From the system’s point of view, the two are entirely different kinds of action.

Checking free slots only requires reading which times are busy; it doesn’t even need the meeting names. Sending an invitation means putting something into other people’s calendars and inboxes on someone’s behalf. Microsoft’s calendar API documentation is explicit: when you create an event that includes attendees, the server sends invitations to all of them, and this can’t be turned off. Google’s calendar API lets a program choose to notify all guests, only external guests, or nobody, but the same documentation warns that choosing no notifications can stop the event from syncing to guests’ calendars.

In other words, once AI creates an event with guests, the outward effect has already happened. It isn’t one more field on a form. It’s a commitment made on someone’s behalf.

Three jobs, three kinds of permission

Since these are three jobs, the permissions AI receives should be separate too.

Checking free slots: read-only. Look only at busy and free times, return two or three candidates, read no meeting content, and create nothing.

Holding time for yourself: write to your own calendar only. Create a hold marked “pending” on the user’s own calendar, with no guests added and no notifications sent.

Inviting others: approval every time. This is the only action that affects other people, so each time it needs a preview, confirmed by a person, before it runs.

This split has to be built into the tools AI can use, not just written in the prompt. An AI that only finds times shouldn’t have the tool that sends invitations at all. The AI Agent Security Cheat Sheet from OWASP, an open community focused on application security, recommends the same: scope tool permissions as read-only or write, offer action previews before execution, and bind human approval to the exact action, so that any change to the target or parameters requires new approval.

The preview must show who will be affected

“Create this meeting?” is too vague; the person clicking yes doesn’t know what they’re agreeing to. A preview fit for approval should at least list:

which account and which calendar act as the organizer;
who each guest is;
start and end times, time zone, and whether it repeats;
the title, description, and location, which is what guests will see;
who will receive notifications.

The approval is tied to this set of details, not to the intention of “setting up a meeting.” If anything changes after approval, such as moving the time back half an hour or adding a guest, it goes back to the preview for confirmation.

One more detail is easy to miss: a network timeout doesn’t mean the first attempt failed. If AI retries directly when it isn’t sure the invite went out, guests may receive two invitations. Microsoft’s API allows a transaction ID to be attached when creating an event to reduce unnecessary duplicates on the server. If the system can’t confirm whether the first attempt succeeded, it should stop and hand over to a person.

When confirming every invite is too slow

Previewing every invite slows scheduling down. For an assistant setting up a dozen meetings a day, confirming each one may be too tedious. You can relax this within clear limits: for example, allow AI to send in batches after a preview only when the guests are fixed internal colleagues, the time falls within working hours, and the meeting is no longer than an hour. Invitations outside those limits, especially ones involving external clients, HR, health matters, or anything not yet public, still need confirmation each time.

And if users don’t want to give AI permission to write to their calendar, don’t force it. AI can produce a meeting draft or an “add to calendar” link and let the person do the last step. With a bit less automation, the coordination still gets done.

As a next step, have your team’s AI scheduling do only one thing at first: read busy times, propose two candidate slots with time zones, and stop. Once time zones, cross-midnight cases, and existing holds are handled correctly, consider letting it write to calendars. The receiving end has the same issue: an invitation in an AI daily brief doesn’t mean you’ve agreed to it; see The Item AI Ranks First Isn’t Necessarily Today’s Commitment. To apply the same layering to email, files, and payment tools, see An Always-On AI Assistant Should Learn to Stop Before It Joins Your Main Accounts.

AI handoff card

I want to check whether my team's AI scheduling flow sends invitations on people's behalf right after finding a free slot.
The method comes from this article: https://boosterminiclass.com/en/posts/ai-calendar-proposal-invitation-boundary/
Its view: "find us a time" is three jobs: checking shared free slots, holding time for yourself, and inviting others. The first two disturb nobody; the third does. AI should stop at proposing candidate slots by default. Before an invitation goes out, a person should confirm a preview listing the organizer account, guests, time, time zone, title, and who gets notified, and confirm again if any detail changes.

Ask me 3 questions first:
1. Which actions can this AI scheduling tool currently take (read busy times, read meeting content, create events, add guests, send notifications)?
2. When a user says "find us a time," how far does it actually go?
3. What confirmation screen does the user see before an invitation is sent?

Based on my answers, give me:
- Each action assigned to one of the three jobs, flagging any tool that spans two jobs and so has permissions that are too broad;
- A minimal version that proposes two candidate slots (with time zones) and then stops;
- The fields a preview should contain before sending an invitation, and which are missing today;
- Conditions under which batch confirmation could be allowed, and cases that must always be confirmed one by one.
Don't create or change any events for me. If information is missing, ask me first. Finally, remind me that whether to allow sending is up to the person responsible for this flow.