Can two people's AI assistants schedule a meeting with each other?

An OAuth-based integration answers the question “what may this assistant do as this user?” That is the correct model for managing your own account, and it is precisely why it cannot reach across to someone else. Your assistant holding a token for your Calendly account tells it nothing about mine, and there is no mechanism for it to ask.

The usual workaround is a human step: someone pastes a booking link, the other person opens it in a browser and picks a slot. That works, but the assistant is not scheduling — it is drafting a message with a URL in it.

One caveat, because it cuts against the tidy version of this argument: the limitation is a property of the MCP surface, not of the underlying data. A public booking page is public availability by definition, and Cal.com will serve another user's open slots over its REST API with no credentials. What is missing there is not access — it is a tool an assistant can reach for. Calendly is stricter and does require a token.

Three conditions, in order:

• The other person publishes availability a stranger can read. Not their calendar — a derived list of open slots. Without this nothing else is possible.
• It is readable without credentials. If reading requires an account or a token, you are back to the account-scoped problem.
• A write path exists with the same properties. Finding a mutual time is useless if booking it still requires a human in a browser.

Lucie Sync satisfies all three: check_availability is an unauthenticated read against any handle, book_meeting is an unauthenticated write into an open slot, and find_group_timesintersects several people's availability at once. Cal.com meets the first two through its REST API, though not as agent tools. The third has no equivalent there, and it is the part that takes real work.

Concretely, when someone tells their assistant “find 30 minutes with @taylor next week”:

• The assistant calls check_availability for @taylor and gets open slots plus the booking rules — minimum notice, how far ahead, buffer between meetings.
• It reconciles those against its own user's constraints, in that user's time zone.
• It proposes a specific time to its user and, on confirmation, calls book_meeting. Availability is re-verified at that instant, so a slot taken in the meantime is refused rather than double-booked.

Taylor never approved this assistant, and never had to. The endpoint is public because it only ever discloses open slots.

• It is asymmetric, not a negotiation. One agent reads and books; the other party's agent is not involved. There is no counter-proposal, no preference exchange, no bargaining. Calling it “agent-to-agent” oversells what the mechanism does.
• The other person needs a live endpoint. In practice a Lucie handle with bookings enabled. Someone without one can still be polled, but not queried.
• Group booking is gated.Reading common times across several people is free; booking one event onto everybody's calendar requires Sync Pro and a personal connector URL, so an assistant cannot claim to be an organiser it isn't.
• The mechanism is not proprietary. None of this needs technology another vendor lacks, and the gap narrows whenever one of them decides to expose slot reads as an agent tool. What makes it useful in practice is that the people you need time with already have live handles — a property of the network, not of the protocol.
• There is no standard. This works because a specific product exposes a specific endpoint. No cross-vendor protocol for availability negotiation exists, so it does not generalise to whatever tool the other person uses.

Mechanics are in the connector docs, and the trade-off against account-scoped servers is in the comparison.