A calendar event is an external effect with an identity. Before creating one, review title, start and end instants, time zone, organizer, attendee list, location, and notification behavior. After creation, keep the returned event ID and version. A later request to move a meeting should update that event rather than create a near-duplicate. Read current state before applying a change, especially when another organizer may have edited it. Cancellation is distinct from deleting a local hold. If the API response is ambiguous, reconcile against the calendar by event ID and expected version before retrying. Prompt wording cannot substitute for the provider's effect receipt.
Calendar prompts: distinguish create, update, and cancellation
Operational case
After the Aster owner selects a conflict-free slot, the assistant prepares a 45-minute invite titled '20-site pilot review' for three checked attendees. The user reviews the details and authorizes creation. The calendar returns event E-47 and version V-1. The vendor later asks to move it by 30 minutes; the assistant checks E-47, recomputes the interval, reviews changed notifications, and updates the same event. If an update times out, it reads E-47 before sending another request. It does not create E-48 by assumption.
Proposed event: 20-site pilot review, 45 minutes, three attendees.
Create approved -> event E-47, version V-1.
Move request -> read E-47, check new interval, update E-47.
Timeout -> reconcile E-47 before retry.
Cancellation -> explicit scope and guest-notice review.Performance and operating cost
A keyed event read is O(1) average at the application level, though network latency can dominate. Rechecking A attendee calendars adds O(A) logical availability checks per proposed change. Version matching and receipts add a small amount of state but prevent duplicate events and lost updates. Review notification behavior because editing an event can message guests even when the prompt describes the edit as minor.
Common Mistakes
- Do not create a second event to move an existing one.
- Do not assume a timeout means the create or update failed.
- Do not cancel an entire event when the user meant one tentative hold.
Connected lessons
- Production prompt engineering
- Prompt Engineering
- Tool effects: reconcile receipts before retrying
- Browser effect recovery: resolve ambiguous submissions before retrying
- Recurring prompts: survive retries without duplicate effects
- Email prompts: reconstruct the thread before drafting
- Email prompts: keep sender identity and message text separate
- Email prompts: verify attachment version and coverage
- Email prompts: review To, Cc, Bcc, and reply scope
- Email prompts: separate drafted commitments from sent messages
- Calendar prompts: resolve availability, zone, and duration
- Calendar prompts: scope recurrence changes to the right instances
- Project: review an Aster vendor reply and invite
- Email and calendar prompt decisions
