Google Calendar AI agent: check the account and proposed change

Confirm the Calendar account and available operation

Start with the intended account and calendar. A connected-account label does not establish that the current task can read that calendar, that the connection still works, or that it has permission to edit events. Check the connection through the supported setup flow and inspect an appropriate permitted read.

Datagran-backed Calendar data integrations require the appropriate Datagran account and connection when enabled. Groovy's structured Wiki is separate from optional Datagran-backed semantic Memory. Check the requirements for the specific workflow, including its permissions and current licensing terms.

Available operations depend on the connection and enabled setup. This guide does not establish that every Groovy account can create, edit, cancel, or reschedule recurring events. If the requested operation is unavailable, keep the proposal for review and use the authorized person's normal Calendar workflow. A connection check does not enable another operation.

Identify the event and the requested scope

Use the actual calendar and event identifiers from current source data. A title such as weekly check-in can match several meetings or calendars. Confirm the organizer, date, attendees, and current start and end before choosing the event.

Google distinguishes a recurring series from one occurrence. Its recurring-event documentation describes recurringEventId and originalStartTime; the original start identifies an occurrence even after it moves. A request to change this meeting still needs a confirmed occurrence and scope. Access to recurring-event data does not establish that the selected product workflow supports editing it.

• Which connected account and calendar own this event?
• Which event or occurrence does the request identify?
• Does the person intend one occurrence, the series, or another explicitly supported scope?
• What source evidence resolves an ambiguous date, organizer, or attendee set?

Keep anything unresolved in the proposal. Do not change a series because a single occurrence was ambiguous, or assume two events with the same title are interchangeable.

Preserve the time zone and all-day meaning

Review the current and proposed start and end together, with the named time zone. All-day dates and timed event values are different representations. Google documents an exclusive end for an all-day event, so its end date does not identify an additional included day.

For a hypothetical weekly 9 a.m. meeting in America/New_York, October 30, 2026 corresponds to 13:00 UTC and November 6 corresponds to 14:00 UTC. The local meeting time stays the same while the offset changes. These dates illustrate a time-zone check; they are not customer events or a Calendar change executed by Groovy.

Preserve the named time zone and recurrence meaning instead of copying one fixed UTC offset across the series. Verify any proposed occurrence date and time against the current Calendar source before approving an available operation.

Review the exact proposal before authorizing a change

A hypothetical customer email asks to move Thursday's meeting to the afternoon. Read the current thread and Calendar evidence. If no source establishes an agreed time, keep the time unresolved and ask for clarification. A plausible afternoon slot is not a confirmed appointment.

• The account, calendar, event, and supported occurrence or series scope.
• The current event details and the source version or review time.
• The exact proposed start, end, time zone, attendees, and other changed fields.
• Any intended attendee notifications and the people who should receive them.
• The unresolved questions and the person who can approve the proposal.

An email reply and a Calendar update are separate actions. Review a rescheduling email through the Gmail draft-approval process and check the Calendar proposal independently. Approval to send one message does not establish permission to change an event.

If the event or proposal changes after approval, inspect the current details and review the revised proposal. Google documents conditional modification with resource versions; a stale-version rejection is a reason to read and review again. Provider documentation does not establish that every Groovy connection exposes that mechanism.

Verify the event result and notification evidence

After an authorized, supported operation, inspect the observed event in the intended calendar. Check its identity, scope, times, time zone, attendees, and changed fields against the approved proposal. A queued task or an agent saying done is not that evidence.

Google's event-update API has a sendUpdates parameter for attendee notifications. Review notification behavior with the proposed edit, particularly when adding or changing attendees. A changed event, a notification request, a recipient reading a message, and an attendee accepting an invitation are different outcomes. Do not report the later outcomes from the event response alone.

If the update response is lost, leave its outcome unresolved. Reconcile the current event and available change evidence before another write. Creating a new event to compensate for an uncertain update can leave two meetings. Retain the operation reference and give the unresolved result a next action and owner.

Start with an inspectable Calendar review

Use controlled, non-customer examples to evaluate the actual connection and permitted operations. This is a proposed acceptance checklist, not a report of completed product qualification.

• Two calendars contain events with the same title; the intended account and event must be resolved.
• A request refers to one occurrence of a recurring event; the proposal keeps that scope explicit and checks operation availability.
• A local weekly meeting crosses an offset change; the named time zone and intended local time remain visible.
• An all-day event is read without turning its exclusive end date into another included day.
• An attendee or event version changes after approval; the reviewer sees the changed proposal.
• An update has an uncertain result; the current event is reconciled before another attempt.

Keep the output small enough to inspect: source reference, proposed change, approval, observed result, and any remaining question. Expand the workflow only after its supported operations and these review cases are verified.