Move One Meeting, Not the Series: A Calendar Agent Change Contract

A small sentence can authorize a surprisingly large edit

“Move Friday's review to the afternoon” sounds simple. For a calendar agent, it hides several decisions: which calendar, which Friday, which time zone, what duration, and whether the request concerns one meeting or the entire recurring series.

The safe operational goal is not to eliminate every clarification. It is to ask only for the missing decision that could change somebody else's schedule. An agent should turn the request into a small, reviewable change contract before making the edit.

Methodology and intended use

This workflow is for developers and operators building Google Calendar scheduling integrations. We reviewed the official recurring-event guide and the event get and update references on September 12, 2026.

The proposal below is an original control and acceptance workflow, not a calendar operation we executed. We did not send invitations, modify a real event or test a connector. Other calendar providers may represent recurrence differently; do not copy the Google-specific fields into another API without checking its documentation.

Identify the occurrence before editing

Google distinguishes a recurring parent event from its instances. An instance carries a recurringEventId and an originalStartTime; the latter identifies its original position in the series even if its actual start has moved. Editing one retrieved instance creates an exception. Google recurring-event guide

Our recommendation is to show the calendar name, meeting title, selected occurrence date and current local time together. The title alone is insufficient: a team can have several reviews with the same name. If the request says “Friday” and multiple occurrences are plausible, ask which date rather than selecting the first search result.

Keep the original identity in the change record. A moved occurrence should not become unrecognizable just because a later search uses its new time.

Make the change contract concrete

Before writing, have the agent produce a short preview:

• Scope: one occurrence only.
• Target: calendar and event identifiers, plus the human-readable date.
• Current schedule: start, end and displayed time zone.
• Proposed schedule: exact new start and end.
• Protected fields: attendees, title, location and other unrelated details.
• Notification choice: who should receive the update.
• Open questions: any information still missing.

These are our proposed review fields, not a special API object. Their purpose is to expose accidental scope expansion. If the user asked to move a meeting by an hour, adding guests or rewriting its description should be visibly outside the contract.

Do not infer a precise time from “afternoon” when that choice matters. Offer a concrete option or ask for the time. If a standing instruction already resolves the ambiguity, record which instruction supplied the answer.

Fetch fresh state and preserve unrelated information

The events.get method retrieves an event by its Google Calendar identifier. An iCalendar identifier is a different lookup path, and the response time zone can be specified. That distinction matters when an agent receives identifiers from different integrations. Google events.get reference

The update method replaces the event resource rather than applying patch semantics. Google recommends a get-then-update approach with etags for partial changes. The method also exposes sendUpdates for controlling the intended notification audience. Google events.update reference

Our operational rule is to treat a stale preview as a reason to reconcile, not to overwrite. If another person changed the event after the preview, retrieve the current state and rebuild the proposed edit. Preserve unrelated fields according to the current API requirements rather than constructing a minimal replacement from the meeting title and time alone.

Credentials belong in the authorized connector. Neither a meeting description nor an attached document should be able to tell the agent to change its authorization rules.

Do not turn a one-off request into a series operation

Google warns against changing every occurrence separately to implement a series-wide change. Its documented “this and following” procedure splits the series, and future exceptions can be reset. This is materially different from editing one instance. Recurring-event modification guidance

For the request in this article, stop at the single occurrence. If the user subsequently asks to move all future reviews, create a new preview that exposes the larger scope and existing exceptions. Do not silently reuse the one-meeting approval.

A useful operator exercise is to place three synthetic meetings in a test calendar: a recurring parent, a previously moved occurrence and an unrelated meeting with the same title. Ask the agent to identify one target without writing anything. Check whether its preview distinguishes them. This is a suggested exercise, not a result we observed.

Verify the result without guessing after a timeout

After an authorized change, our recommendation is to retrieve the selected event again and compare it with the contract. Check the new schedule, the preserved fields and the instance identity. Report the actual returned state, not just the outgoing request.

If the update response is uncertain, do not immediately create a replacement meeting. First read the existing target. It may already contain the intended change. If the result still cannot be established, report an unresolved operation and retain the identifiers needed for a later check.

The user-facing receipt should say what changed, which occurrence changed and which notification option was requested. It should not claim that every attendee read an email or that every external calendar has synchronized unless separate evidence supports that statement.

Limitations and selecting a scheduling skill

This contract cannot guarantee that a connector preserves every provider-specific field or that all attendees receive an update instantly. Access rights, organizer status and integration behavior remain important. Test on a disposable calendar before allowing writes to a shared production schedule.

When browsing the OpenAgentSkill directory, evaluate scheduling workflows by how clearly they expose edit scope and recovery states—not just whether they advertise calendar support. Our agent workflow placement guide explains why standing constraints and executable capabilities deserve separate treatment.

A trustworthy calendar assistant does more than find a free slot. It makes the smallest authorized change and leaves a receipt that another person can verify.