What is a multi-agent calendar collision?

Definition. A multi-agent calendar collision is the failure mode that occurs when two or more independent scheduling agents — operated by different vendors, principals, or processes — each commit a booking to the same calendar slot without coordinating with one another. The underlying calendar API accepts both writes because it has no notion of "the other agent that was about to write here," and the human ends up with overlapping events that each system believes is canonical.

This post defines the term, names the four canonical patterns, surveys what today's tools actually solve, and lists the three properties a real coordination layer has to guarantee. It is intended as a reference companion to the longer narrative and the engine deep-dive.

Why this happens

Calendar APIs were designed for one writer at a time — a human, or a single product acting on the human's behalf. None of the consumer or enterprise calendar APIs in use today expose a compare-and-swap primitive at the slot level. The agent's "check availability" and the agent's "commit booking" are two separate network calls, and any number of other agents can slip into the window between them.

Cal.com's own AI-agents documentation captures the current state of the art with one sentence: "Always check slots before attempting to create a booking to avoid conflicts." (cal.com/docs/agents) That guidance is correct for a single agent. It is exactly the race condition when two agents follow it at the same time. The check is stale by the time either of them writes.

This is not a Cal.com problem specifically — it is the universal shape of the calendar API surface. Google Calendar, Microsoft Graph, Apple CalDAV, and every booking platform built on top of them have the same property. A coordination guarantee, if it exists, lives somewhere else.

The four canonical patterns

When you instrument the problem in a multi-agent pilot, the failures sort into four reproducible buckets:

1. Hold-vs-hold. Two agents both place a tentative hold on the same slot; neither has committed; both ask the human to confirm. The loser never gets told it lost.
2. Hold-vs-commit-inside-bump. Agent A holds; Agent B commits seconds later. Whichever the calendar accepted last appears canonical, which is usually the wrong answer.
3. Commit-vs-frozen. Both agents successfully commit. The calendar now has two events at the same time, each believed to be the real one by its respective system.
4. External-event-overlap. The human types a manual event onto the calendar. An agent's hold for that slot is now stale, but the agent is not told until its next poll — by then it has already emailed the counterparty with the time.

Each of these is described in more detail, with timing diagrams, in the agents-collide post.

What existing tools do and don't solve

It's tempting to look at this list and assume one of the mainstream scheduling tools must already handle it. They don't, because they're solving a different problem.

Cal.com and Calendly are the gateway through which an AI agent reaches a calendar. They check availability against the underlying calendar at booking time, and they expose well-designed agent APIs. They explicitly do not coordinate between multiple agents racing for the same slot — the relevant docs section recommends best-effort slot-checking by the agent itself (source).

Motion, Reclaim, and Clockwise are AI calendar planners for one user. They auto-schedule that user's own tasks against the user's own calendar. They are excellent at this — but the failure mode they solve is "the human can't decide what to focus on," not "two agents are racing." If a user installs both Motion and Reclaim, the two products do not coordinate with each other.

The academic work that exists is similarly scoped. ScheduleMe: A Multi-Agent Calendar Assistant (arxiv 2509.25693) uses a graph-structured supervisor pattern to coordinate sub-agents inside one system against one user's Google Calendar. That solves the intra-system case. The cross-principal case — different vendors, different incentives, writing to the same calendar — remains open in the literature.

MCP servers for calendars are now appearing in the ecosystem (community projects for Cal.com, Google Calendar via n8n, and others). MCP is a transport for exposing tools to AI agents; it is not a coordination protocol. An agent connected via MCP to a calendar tool faces exactly the same race against any other agent doing the same.

The shape of the gap: every layer above the calendar coordinates within itself. Nothing coordinates between layers. That's the problem definition.

What a coordination layer must guarantee

Once the problem is named, the requirements for a real fix are short and specific:

1. Atomic compare-and-swap at the slot level. The check that a slot is free and the write that claims it must be one indivisible operation. Anything that separates them reintroduces the race. In practice this means storage-level conditional writes — not application-level locks, not "check, then write."
2. Explicit priority, configured by the calendar owner. Two agents reaching for the same slot need a deterministic tiebreaker, and that tiebreaker must be a per-user policy, not a vendor-baked global rule. (Sales calls outrank personal time for an enterprise rep; personal time outranks everything for a consultant.)
3. An append-only audit log readable by both parties. Every collision is a question — "why didn't I get the slot?" — and the answer must be inspectable by the winning and the losing agent. This is what makes the protocol trustworthy across organizational boundaries.

A system that has all three properties is a coordination layer. A system missing any one of them is not a fix — it is at best a hint for the next race.

FAQ

Is this the same as a calendar conflict?

No. A "calendar conflict" usually means a human typed two overlapping events into their own calendar. A multi-agent collision is two independent automated systems writing to the same slot without any shared view of pending state.

Why doesn't "check before write" fix it?

Because the check and the write are two separate network calls. Between them, another agent can complete its own check-and-write. The race condition exists at the boundary between reading availability and claiming the slot. Closing it requires those two operations to be atomic at the storage layer — a guarantee no consumer calendar API provides.

Is this an MCP problem?

No, but MCP makes it more visible. As more AI agents move from custom REST glue to MCP-based calendar tools, the number of agents writing to any given calendar goes up, and the collision surface grows.

How is this different from what Motion or Reclaim do?

Motion and Reclaim coordinate one user's tasks on one user's calendar. They don't coordinate between different agents operated by different principals. Two users who each install Reclaim are fine; one user who installs both Motion and Reclaim hits a multi-agent collision the moment both products try to book the same slot.

Does Google Calendar prevent this?

No. Google Calendar (and Microsoft Graph, and CalDAV) will accept two overlapping events from different writers without complaint. They are not the wrong shape for this — they are the storage layer. The coordination guarantee has to live above them.

Related reading

• Multi-agent calendar collision — glossary entry — the short reference definition.
• Why AI scheduling agents collide — and what a coordination layer looks like — the longer narrative.
• How a deterministic conflict engine resolves 8,217 collisions — the engineering detail of how the atomic guarantee is actually implemented.
• The protocol spec — the public surface of the coordination layer.

— agentdraft.io · v0.1