--- name: reclaim-ai-meeting-scheduling description: Find a time that works for a set of attendees and book it on the user's Reclaim.ai calendar, checking availability, looking up contacts, weighing suggested times against focus and working-hours constraints, and asking for explicit approval before any invite or event is created. Use when the user asks to schedule, book, set up, find a slot for, or find time with people, or asks whether they have room for a call or a meeting. --- # Schedule a meeting with other people This job ends in one of two states: a meeting that is booked with the user's approval, or a clear statement that no acceptable slot exists and what the options are. Finding a slot is read-only and cheap. Booking is the step that sends invitations to other people, so it is never done silently. ## 1. Pin down the request before searching Establish these from the user's message, and ask once for anything missing: - **Who:** the attendees, resolved to real contacts (see step 2). Ask if a name is ambiguous. - **Length:** a 25-minute call and a 90-minute workshop need different gaps. - **Window:** a date range or "this week". Vague windows like "soon" get a concrete proposal, not a search of the whole year. - **Purpose and format:** video call, in person, recurring or one-off. A recurring series changes the decision, so confirm it explicitly. - **Constraints:** timezone of each attendee, things that must not move (a standing focus block, a child pickup). Do not guess the timezone of an attendee. If the contact data does not give one, ask. ## 2. Resolve attendees before checking time Use `search_contacts` for each name. Work through the results in this order: 1. Exact match on the email or full name the user gave. 2. A single clear first-name match with the same organisation or domain as other attendees. 3. More than one plausible match: list them and ask which one, rather than picking. Booking the wrong person is the most expensive mistake in this job. If a person cannot be found as a contact, say so and ask for their email address. Do not invent one. ## 3. Check availability in two passes Start with the user's own calendar using `get_schedule` for the window, then `find_open_time` for gaps of the required length. Only then look at what the other attendees can see, if that data is available through the tools you have. If attendee availability is not visible, say that the slot is free on the user's side only and that the others must confirm. Filter candidate gaps by judgement, not only by raw emptiness: - Reject gaps that start or end flush against another meeting when a 5 to 10 minute buffer is possible. Two back-to-back calls are usually a hidden cost. - Prefer slots that do not cut into a protected focus block or the user's stated working-hours edges. - Prefer earlier in the day for decisions and later for deep discussion, unless the user's preferences say otherwise. - Avoid the first and last slot of a day for anyone in a different timezone, as they often land at night for one party. Use `suggested_times` when the open gaps are poor or when the user asks for a recommendation, and treat its output as a ranked suggestion you still check against the constraints above. ## 4. Present two or three options with reasons Give the user a short ranked list. Each option states the time in the timezone the user is working in, the length, what it displaces (nothing, or a named focus block), and any attendee-side caveat. Lead with the best option and say why. Do not present ten slots. If nothing fits, say so plainly and offer the next best: a shorter length, a different day, a 30-minute move of an existing event if the user is willing (this is a change, so it needs its own approval). ## 5. Book, but only after an explicit yes Creating the event with `add_event` sends invitations to real people. Before calling it, show the user the exact title, start and end with timezone, attendees, format and whether it is recurring, then wait for the user's explicit yes to this specific booking. A general "sounds good" to the options in step 4 does not count as approval to send invites; restate the final details and ask. If a video link is wanted, add it with `add_video_conference` after the event exists, and again confirm it has been done. For a change to an event that already exists, such as moving it with `reschedule_event` or cancelling it with `cancel_event`, the same rule applies: state the change, its effect on attendees, and wait for the user's explicit yes. ## 6. Confirm what happened After booking, read the event back with `get_event_details` and check that the time, timezone, attendees and any video link match what was approved. Report any mismatch immediately rather than assuming the tool did what was asked. ## Common patterns and traps - **Same name, different people.** Two "Alex"es in the contacts list is common. Confirm by email before booking. - **Timezone drift.** A slot that reads 9:00 to the user can be 2:00 for an attendee in another region and 23:00 for another. State the timezone on every proposal. - **Free for you is not free for them.** Gaps on the user's calendar say nothing about attendees' availability unless that data is visible. Say which side you checked. - **Buffer blindness.** Booking 2:00 to 3:00 directly after a 1:00 to 2:00 call looks fine on a grid and is exhausting in practice. - **Recurring surprises.** A "weekly" meeting booked without confirming the series will fill the calendar for months. Always state the recurrence and how long it runs. - **Booking over a focus block.** Suggested times may ignore protected time the user cares about. Check the schedule, not only the suggestion. - **Approval drift.** After a long back-and-forth, the user may have approved the time but changed the attendee list or title. Re-confirm the final version, not an earlier one. ## Output ``` Request: Attendees resolved: Options (timezone: ): 1. — 2. <…> Recommended: