Building a Reliable AI Calendar Assistant That Actually Works

You spend too much time shuffling meetings, dealing with time‑zone mix‑ups, and chasing down confirmations. After reading this you’ll have a working AI calendar assistant that can propose slots, send invites, and reschedule when conflicts appear.

How do you stop the AI from double‑booking overlapping meetings?

The core problem is that most naive prompts ask the model to “find a free slot” without checking existing events. The model then hallucinates availability. The fix is to give the assistant read‑only access to your calendar and force it to query before proposing.

First, set up a read‑only token for Google Calendar. Most providers let you create an OAuth scope that only lets the app list events. Keep the token secret; treat it like a password.

Next, give the model a tool that returns a list of busy intervals for a given day. In pseudo‑code:


def get_busy(start_iso, end_iso):
events = calendar_service.events().list(
calendarId='primary',
timeMin=start_iso,
timeMax=end_iso,
singleEvents=True,
orderBy='startTime').execute()
return [(e['start'].get('dateTime', e['start'].get('date')),
e['end'].get('dateTime', e['end'].get('date'))) for e in events.get('items', [])]


Now the assistant’s prompt becomes:


You are a scheduling helper. You have access to a tool called get_busy that returns busy intervals for a day.
When the user asks for a meeting, first call get_busy for the requested date range.
Then propose up to three 30‑minute slots that do not intersect any busy interval.
Return each slot as ISO start and end times.


This simple loop eliminates most double‑bookings. I’ve seen assistants cut conflicting bookings from 20% of requests to under 2% after adding the busy‑check step.

What most guides get wrong about AI calendar assistants

Many tutorials treat the AI as a replacement for the calendar UI. They tell you to let the model write directly to the calendar. That’s risky because a hallucinated event can overwrite a real one.

The better pattern is to keep the AI in an advisory role: it suggests, you confirm. Only after you approve does the assistant call the create‑event endpoint. This adds a safety net and still saves you the mental work of hunting for slots.

Another common mistake is ignoring recurrence rules. If you ask for “every Tuesday at 2 pm”, the model might generate a single event and forget to set RRULE. The result is a cluttered calendar and missed future meetings.

To handle recurrence, ask the model to output an iCalendar snippet or a JSON object with freq, count, and interval. Then feed that to the calendar API’s recurrence field.

How to debug when the assistant misses a time‑zone shift

Time‑zone bugs are the silent killers of scheduling tools. You’ll notice them when a meeting shows up an hour off in your phone but looks fine on the web.

First, log the raw ISO strings the assistant receives and sends. If you see something like “2026-04-05T14:00:00” without a zone offset, assume UTC and convert incorrectly.

Second, make sure your get_busy tool returns times in the same zone you use for proposals. I store all times in UTC internally and only convert to the user’s local zone at the very last step, right before displaying.

Third, test with a known edge case: schedule a meeting during a DST transition. In the U.S., the second Sunday in March clocks jump forward. If your assistant still proposes a slot that falls in the missing hour, you’ll see the error.

When I first ran this test, the assistant happily booked a meeting at 02:30 local time on the day the clocks jumped from 02:00 to 03:00. The event appeared as 02:30 on the calendar but actually occurred at 03:30 UTC, causing a one‑hour shift. Adding a zone‑aware conversion step fixed it.

Concrete named example: a prompt that works with Claude 3

Here’s the exact prompt I use with Claude 3 via the Anthropic API. It assumes you have exposed the get_busy tool as described earlier.


You are a scheduling assistant. You have access to a tool named get_busy that takes an ISO start and end time and returns a list of busy intervals.
When the user asks for a meeting, do the following:
1. Ask for the desired date, duration, and any preferred time window.
2. Call get_busy for that day (or the window).
3. Generate up to three candidate slots of the requested duration that do not overlap any busy interval.
4. Present each slot in the user’s local time zone, formatted as "Weekday, Month Day at HH:MM AM/PM".
5. Wait for the user to pick a slot or suggest alternatives.
6. Once confirmed, call the create_event tool with the chosen start and end times.


I run this on a $0.008 per 1k tokens plan. For a typical scheduling turn (user request + assistant response + tool calls) I spend about $0.004. Over a month of 150 interactions that’s under $1.

I think the price is fair for the time saved—roughly five minutes per meeting avoided.

Concrete gripe: the missing docs for custom recurrence

One thing that annoyed me was the lack of clear examples for setting RRULE via the Google Calendar API in the official docs. The reference page shows a JSON schema but omits how to handle week‑day masks.

After digging through community forums I found that you need to pass an object like {“recurrence”: [“RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=TU,TH”]}. Without the BYDAY part the series defaults to every week on the same weekday, which is fine, but if you want Tuesday and Thursday you must specify it.

If you’ve tried Zapier, you know what I mean: the UI hides the raw fields and you end up guessing.

Concrete love: instant alternative slots

The feature I actually use every day is the assistant’s ability to propose three alternatives in under a second when the first choice conflicts. It feels like having a hyper‑efficient secretary who never gets tired.

Because the assistant checks busy intervals before suggesting, the alternatives are always real openings. I’ve cut the back‑and‑forth email chain from three messages to one.

One‑sentence paragraph: This alone saves me about an hour each week.

Putting it all together: a minimal working flow

You don’t need a fancy framework. A simple serverless function (AWS Lambda, Cloudflare Workers, or a cheap VPS) can host the logic.

1. Expose an HTTP endpoint that receives a JSON payload with user request.
2. Call get_busy (your calendar read‑only token).
3. Run the prompt logic (you can hard‑code the steps or call an LLM API).
4. Return the proposed slots.
5. On user confirmation, call the create_event endpoint.

I’ve run this on a $5/mo VPS with zero‑downtime for six months. The only recurring cost is the LLM API calls, which stay under $2/mo for light use.

For more on this exact angle, AI meeting tools coverage.

If you’d rather skip the build and deploy a working version in an afternoon, we’ve packaged this workflow as a blueprint at deepusecase.com/vault.