Evaluate scheduling agents for constraints and confirmation

Write the event contract before searching slots

Google Calendar’s event-creation guide documents event fields including times and attendees. Rubrex recommends extracting those fields into an inspectable proposal before creation. The intended day, zone, duration, participants, meeting type, and notification policy should be explicit rather than hidden in a conversational interpretation.

Use a synthetic request for a thirty-minute planning meeting between two test calendars. One participant says morning in their local zone; the other gives a bounded working-hours window. Define how ambiguity is resolved, and keep a draft proposal separate from an instruction to create the event.

Evidence: Google Calendar: Create events [1]

Create time and identity ambiguities deliberately

Test a date written without a year, two participants with similar names, and a slot near a daylight-saving transition in a zone that observes one. Supply the relevant zone data through the actual calendar system rather than asking the model to calculate offsets from memory.

Add a recurrence request with one exception and a reschedule request that refers to an existing event. The agent should distinguish a new series from editing one occurrence. Inspect the chosen calendar and event identifier so a correct-looking time does not conceal an update to the wrong meeting.

Test the gap between availability and commitment

Hold the agent after it finds an available slot, then insert a synthetic conflict before creation. Observe whether the workflow rechecks the required availability or produces an explicit conflict according to the product contract. Do not score any available-looking suggestion as a completed booking.

Capture the created event fields, attendees, response status, and notification behavior. Include a permission-denied case and a normal valid creation control. Report wrong-zone events, unintended invitations, duplicate events, and useful clarification separately, since they require different corrections even when all appear as scheduling failures.

Release the smallest reliable scheduling scope

Accept the workflow when the stored event matches the approved proposal and changed or ambiguous constraints produce a clear next step. Require a stable operation identifier or reconciliation path for creation retries so a delayed response cannot create duplicate meetings.

Retain the proposal, availability snapshot, final event identifier, and actual fields. Re-run the transition, recurrence, and reschedule cases after changing parsing or calendar adapters. A narrow assistant that proposes valid slots and asks one precise clarification may be more useful than one that always returns a confident but incorrectly committed meeting.

Common questions