Gemini Google Calendar Scheduling vs AI Group Scheduling Execution

Run the same hard-meeting test across suggestion and execution

Use one sixty-minute committee meeting with four required people, two optional observers, Google and Microsoft calendars, one unconnected external participant, three IANA time zones, one guest-list change, one stale slot, one decline, and one hidden event-write response.

1. 1

   Write the completion contract before opening Calendar

   Record the authenticated organizer, purpose, duration, bounded date range, booking deadline, required and optional participant entities, approved substitutes, IANA zones, working hours, buffers, outreach and disclosure policy, approval mode, organizer calendar, and terminal proof. Keep those rules in durable meeting state rather than relying on a prompt, draft, or attendee list to preserve them.
   • Required attendance is explicit rather than inferred from email recipients.
   • Optional people can improve a result without blocking the required group.
   • Success means one verified invitation set or one bounded exception, not four proposed slots.
2. 2

   Test Suggested times in Google Calendar on its documented job

   Create the event, add guests, request Suggested times, and inspect the grid. Google’s current help page says Gemini can search everyone’s availability, suggest times, filter guests by required or optional status, and suggest alternatives when several guests decline. Record which calendars are visible, which people are outside the visibility boundary, and whether every required role is represented by current evidence.
   • A suggested time is kept separate from organizer approval and event delivery.
   • Unavailable calendar access remains unknown rather than free.
   • Required and optional labels in the interface match the meeting contract.
3. 3

   Test Help me schedule in Gmail without hiding its handoffs

   Draft the participant message and insert the suggestion card. Google documents support for one or more people, four proposed slots by default, and up to twenty guests on one schedule. It also says the card’s guest list does not update when email recipients change after insertion. Change one required person after the card appears and verify whether the earlier proposal is withdrawn or must be rebuilt manually.
   • Every suggested slot carries the participant set and evidence version that produced it.
   • An amber conflict is treated as a conflict, not an invitation to guess.
   • A changed recipient list cannot silently preserve approval from the old group.
4. 4

   Cross the Google visibility boundary

   Keep two required people on visible Google calendars, place one on Microsoft, and leave one external participant unconnected. Read approved Google or Microsoft free/busy where available. Store provider, account identity, source time, IANA zone, freshness, permission result, and typed error. Do not infer that an email address exposes usable calendar evidence.
   • Private event titles are unnecessary when busy intervals are enough.
   • A provider denial and an empty busy result remain different states.
   • The comparison records observed behavior in the tested tenant rather than projecting from an AI label.
5. 5

   Collect bounded availability when calendar connection stays optional

   Contact the unconnected participant through an approved path. Include the organizer, approved purpose, duration, bounded dates, participant-local times, named zone, response deadline, correction path, reminder cap, and opt-out. Normalize the answer beside connected free/busy with identity, source, consent, received time, freshness, and expiry.
   • The participant can answer for this meeting without exposing a full calendar.
   • Silence blocks a required person and never becomes an opening.
   • An ambiguous phrase such as ‘Friday afternoon’ triggers one narrow clarification.
6. 6

   Expire the proposal when people or calendars change

   Move one required calendar event, correct one participant’s zone, and add a required attendee after the suggestion. A scheduling execution layer should revoke stale approval, preserve unaffected replies, refresh connected evidence, recompute required overlap, then rank optional attendance and preferences. Measure whether the tested Google surface owns that state transition or asks the organizer to rebuild it.
   • A prior green slot cannot outlive its evidence or participant set.
   • Daylight-saving conversion comes from the named zone and meeting date.
   • No-overlap returns one policy decision instead of another reply-all chain.
7. 7

   Book, hide the write response, and ingest the decline

   Approve one slot and issue one idempotent booking command. Hide the provider response, then reconcile the organizer calendar before retrying. After the event exists, have one required attendee decline and one optional attendee remain tentative. Google documents attendee response states; the execution test is whether those signals reopen only the affected policy decision and produce a controlled repair.
   • A network timeout does not prove that no event was created.
   • A required decline and an optional tentative response follow different rules.
   • A decline cannot authorize a substitute, new date range, or wider disclosure by itself.
8. 8

   Read back provider truth and count human handoffs

   Verify final URL-independent facts in the canonical event: organizer, calendar, start, end, zone, required attendees, approved optional decisions, conferencing, and invitation state. Count every time a human rebuilt the guest list, contacted an external person, interpreted a reply, refreshed stale evidence, repaired a decline, retried a write, or checked completion. Choose the product boundary that matches the outcome you need.
   • Suggested, proposed, booked, and accepted remain separate states.
   • Every required participant path ends in a verified invitation or precise exception.
   • The scorecard uses observed behavior and cited documentation, not invented timing or customer claims.

Gemini Google Calendar scheduling vs group execution

This scorecard separates documented Google scheduling surfaces from the wider cross-company completion job. Verify current behavior in your own Google Workspace environment.