Meeting scheduling & calendar agent

Finding a slot that works for several people, in several time zones, around existing commitments is a classic email ping-pong. A calendar agent reads availability, applies the owner's rules, proposes or books times, handles reschedules and protects focus time. The agent acts on a personal calendar, so the design questions are permissions, transparency and what it may do without asking.

Problem & value

• Today: assistants or the people themselves exchange emails ("Does Tuesday 14:00 work?"), juggle time zones, and manually move meetings when conflicts appear. Calendars fill with low-value meetings and leave no time for deep work.
• AI value: automatic availability matching, natural-language requests ("move my 1:1s with the team to Friday afternoon"), rule-based accept/decline, and continuous replanning when something changes.
• Evidence: Microsoft describes Calendar agentic capabilities in Microsoft 365 Copilot (rolled out April-May 2026) that accept, follow, decline or remove cancelled meetings by user-defined natural-language rules and show an activity history with explanations [1]. No reliable independent time-saving figures were found; measure your own baseline.
• Market note: Clockwise shut down on 27 March 2026 (team moved to Salesforce Agentforce) and pointed users to Reclaim.ai [2] - a reminder to avoid lock-in on a single scheduling start-up.

Variants

• Executive/assistant support: agent drafts, assistant approves; handles VIP rules and travel buffers.
• Inbound booking: public booking pages with routing (sales, support, recruiting interviews).
• Task-and-time planning: tasks with deadlines are auto-scheduled into free slots and re-planned (Reclaim, Motion).
• Team scheduling: find a common time across many attendees and rooms.
• Private use: family calendar, appointments with doctors/authorities, sports clubs; see AGENT-019.

How it works

1. trigger (email / chat request / booking-page submit / calendar change)
2. intent extraction (attendees, duration, window, urgency, time zones)
3. availability lookup (free/busy of all reachable calendars + rooms)
4. policy check (user rules, working hours, buffers, VIP / no-go lists)
5. slot ranking (LLM or heuristic; fairness, time-zone friendliness, focus-time protection)
6. action: propose slots by email | book directly | decline/reschedule
7. confirmation + invite + video link + logging

• Core logic is deterministic. Availability search is done by calendar APIs (Google Calendar freebusy.query [3], Microsoft Graph findMeetingTimes [4]); the LLM parses messy requests, drafts replies and explains decisions, but should not do time arithmetic itself.
• Tool access: calendar functions are exposed as tools, increasingly via Model Context Protocol (MCP) servers [5], so any agent framework can call them.
• Human-in-the-loop: tiered autonomy - read-only suggestions first; auto-book only for internal, low-stakes meetings; anything involving external VIPs, deletions of others' meetings or sensitive topics needs confirmation. Every action is logged and reversible.

Data preparation

Little classic data preparation is needed because the main data, calendars, already lives in Microsoft 365, Google Workspace or a CalDAV server. The agent works on free/busy information, meeting titles, attendee lists, room resources and mails with scheduling requests.

Typical gaps: calendars that are not maintained (private appointments not entered), meetings without clear duration or purpose, room and resource calendars missing or duplicated, different time zones and working hours not set, delegate and sharing rights too broad, and no written scheduling rules (VIP lists, focus time, buffers).

Preparation steps: 1. Write down scheduling rules in 10-15 lines per role: working hours, buffers, no-go times, who may book directly. 2. Clean up room and resource calendars and set working hours and time zones for every user. 3. Review sharing and delegation rights; grant the agent only least-privilege OAuth scopes (PREP-023, PREP-024). 4. Mark which calendar details (titles, private flags) the agent may read. 5. Collect 20-30 typical scheduling mails as test set (PREP-018).

Tools: admin consoles of M365 or Google, a spreadsheet for rules. Expect roughly 10 percent of the effort in data preparation; rules and permissions matter more than data volume. See GUIDE-003.

Implementation paths

Which path for whom

• SMB: Path A, because Microsoft 365 Copilot, Google Gemini, Reclaim or the EU tool meetergo cover standard scheduling at low cost.
• Enterprise: Path A, because calendar scheduling is a commodity function that suite-native agents handle with existing identity and compliance controls.
• Developer: Path C, because Cal.com, CalDAV and a small local model on HW1 are enough to build and customise it.
• Private: Path A, because built-in assistants and booking tools in the calendar a person already uses are simplest.

Path A - Buy (recommended)

• Built into suites: Microsoft 365 Copilot (Outlook calendar agent, chat-assisted scheduling) [1], Google Workspace with Gemini in Calendar.
• Dedicated tools: Reclaim.ai (Dropbox-owned, Google and Outlook) [2], Motion, Calendly and its AI features, Cal.com (open core), meetergo (German/EU booking and routing tool), Doodle.
• Choose A when: one calendar ecosystem, standard rules. Check EU data residency, sub-processors, admin-consent scope of the OAuth permissions and the vendor's continuity (see Clockwise).

Path B - Build on cloud APIs

• LLM with tool calling (Claude, Gemini, GPT, Mistral - EU provider; EU-region endpoints where offered), calendar access via Google Calendar API [3] or Microsoft Graph [4] with least-privilege OAuth scopes.
• Orchestration with n8n, Power Automate or an agent SDK; email intake via Gmail/Graph mail.
• Choose B when: custom policies (round-robin, resource rules), embedding in your own product, or a mailbox-driven "assistant you cc" workflow.

Path C - Self-host (open source)

• Scheduling: Cal.com (self-hostable, AGPL core) [6], plus CalDAV servers (Nextcloud, Radicale, SOGo) for fully on-prem calendars.
• Models: small open-weight instruction models (e.g. Qwen3, Mistral Small, Llama family) suffice for intent extraction; run via Ollama or vLLM. Hardware: HW1 (CPU or small GPU).
• Orchestration: self-hosted n8n. Effort: low to medium; main work is calendar-protocol integration.

Path D - Custom training

Rarely justified. Preference learning (which slots a person accepts) can be done with simple ranking models on accept/decline history; no model training is needed for the language part.

State of the art (2026)

• Calendar agents moved from "find a slot" assistants to rule-following autonomous agents inside suites (Microsoft's accept/decline-by-rule model [1]) and auto-scheduling planners (Reclaim, Motion).
• Tool standardisation: MCP servers for calendars let general assistants (Claude, ChatGPT, Gemini, Copilot) manage calendars without bespoke integrations.
• Limits and failure modes: time-zone and DST errors when the LLM computes times itself; misreading ambiguous requests ("next Friday"); double bookings across multiple calendars; over-eager declines of important meetings; prompt injection through invitations and emails (an invite description can contain instructions aimed at the agent); leaking calendar details (titles, attendees) in replies to outsiders. Multi-party negotiation between two agents is still brittle.

Shared resources & combinations

• Shared stack: llm-general + tool calling + workflow-automation, same as AGENT-001 (inbox triage) and AGENT-002 (workflow automation); one MCP gateway can serve all.
• Combines with: AGENT-001 (requests arrive by email), AGENT-010 (travel blocks and bookings), AGENT-009 (onboarding meeting series), AGENT-007 (booking links for sales outreach), AGENT-019 (personal admin), and meeting-notes tools after the meeting.

Effort, cost & KPIs

• Path A: hours to days; per-seat subscription (Copilot, Reclaim and similar tools are priced per user per month; verify current prices).
• Path B: 2-6 weeks incl. OAuth app review and security assessment; low token cost per request.
• Path C: 1-2 months; modest hardware, ongoing maintenance of integrations.
• KPIs: scheduling round-trips per meeting, time-to-confirmed-slot, share of auto-booked meetings, override/undo rate, no-show and reschedule rate, protected focus hours per week, user trust (survey).

People & change

Involve: management and executives (the first users), assistants and end users, IT for tenant settings and OAuth consent, IT security for scopes and mailbox access, the DPO, and the works council if one exists.

Works council: depends. Calendar data shows who meets whom and when, and agent actions are logged. Tools such as M365 Copilot are suited to monitor behaviour, so §87(1) no. 6 BetrVG will usually apply (objective suitability suffices per BAG). A pure personal booking page without evaluation may not trigger it. Inform under §90(1) no. 3; agree that calendar data is not used for performance control.

Data protection: calendars reveal contacts, health appointments and private life. Need an AVV (Art. 28 GDPR) with the provider, a DPO check, and a DPIA only if systematic analysis of staff behaviour is planned (GUIDE-005). Third parties receive mails from an AI system, so label them transparently (Art. 50).

AI literacy: support users with a short introduction to what the agent may decline or book (GUIDE-006).

Communication and pilot: start with a few volunteers in suggestion-only mode, then auto-book internal meetings. Typical concerns are loss of control and privacy; answer with tiered autonomy, a visible action log and a switch-off option, so humans stay in control (GUIDE-008, GUIDE-013).

Risks, regulation & compliance

• EU AI Act: minimal risk for scheduling of one's own meetings; AI literacy duty (Art. 4) applies. Transparency (Art. 50) is relevant if the agent writes to outsiders as if human - disclose it. Becomes sensitive if scheduling is used to evaluate or monitor employees (calendar analytics for performance assessment can touch Annex III employment use) - keep it out of scope. No Art. 5 issue unless used for emotion inference or covert monitoring, which this use case does not require.
• GDPR: calendars contain personal data of attendees and can reveal special categories (medical appointments, union meetings). Need a legal basis, processor agreements, data minimisation (free/busy rather than full details where possible), retention limits on logs, and works-council involvement in Germany (BetrVG section 87) when deployed for employees.
• Security: OAuth scopes limited to calendar; no write access to others' calendars beyond invitations; prompt-injection hardening; audit trail; kill switch.
• Mitigations: tiered autonomy, confirmation for external or sensitive meetings, private events shown as "busy".

Getting started

1. Pick one calendar ecosystem and list the rules you actually apply (hours, buffers, VIPs, focus time).
2. Start with Path A suggestions-only mode for two weeks; review the activity log.
3. Enable auto-accept/booking for internal low-stakes meetings only.
4. If building: use freebusy/findMeetingTimes for slot search, let the LLM only parse and draft.
5. Review privacy (visibility of titles, sub-processors) and inform employees/works council.

Sources

1. Microsoft Message Center MC1296874, Calendar Agentic capabilities in Microsoft 365 Copilot - https://mc.merill.net/message/MC1296874
2. Reclaim.ai blog, Clockwise shutdown news (19 Mar 2026) - https://reclaim.ai/blog/clockwise-shutdown-news
3. Google Calendar API, Freebusy: query - https://developers.google.com/workspace/calendar/api/v3/reference/freebusy/query
4. Microsoft Graph, user: findMeetingTimes - https://learn.microsoft.com/graph/api/user-findmeetingtimes
5. Model Context Protocol specification - https://modelcontextprotocol.io/specification
6. Cal.com open-source scheduling - https://github.com/calcom/cal.com
7. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj