AI-first scheduling is actually API-first scheduling

Every scheduling tool on the market is shipping an AI feature. Most of them are the same feature: a chat box in the corner that lets you type "book me with Anna on Thursday" and has the model fill in a form.

This is fine. It is also not interesting.

The reason it's not interesting is that the value isn't in the chat box. It's in everything the assistant can reach. If the assistant can only reach what one team's designers wired into one product's sidebar, you've replaced a form with a slightly friendlier form. The assistant you actually use — Claude, ChatGPT, Cursor, whatever's next — doesn't live inside that product. It lives somewhere else, and it's better.

Two models of "AI scheduling"

Call them embedded and agent-addressable.

Embedded AI is what most of the category is doing. The vendor hosts a model, trains it on the app's internal vocabulary, and exposes it through a panel. The model can only do what the vendor exposed. If you want it to also talk to your CRM, your notes, your repo, your coworker's booking page — well, you don't. That's a separate product.

Agent-addressable is the inverse. The vendor does not ship an AI. The vendor ships a clean, documented surface — a REST API, an MCP server, webhooks — and lets whichever agent the user already trusts operate on it. The model is not a feature of the app. The app is a feature of the model's world.

The second one wins for anyone who already has a favorite assistant. And the overlap between "person who would use AI scheduling" and "person with a favorite assistant" is large and growing.

The test

A good test for whether a scheduling tool is actually AI-first: can an agent do something useful with it from outside the app?

For an embedded-AI product the answer is almost always no. You can use the chat panel they built. You can't have your own agent read your bookings into a weekly report, correlate them with your CRM, check conflicts before a proposed deep-work block, or book on your behalf through a workflow you wrote yourself. The vendor's assistant is the only assistant.

For an agent-addressable product the answer is yes. If there's an API with enough surface to represent the user's real intent — "what's on my calendar", "does this conflict", "create this" — any agent can drive it. Today that means Claude, ChatGPT, Cursor. Tomorrow it means whatever people move to. The tool doesn't need to guess.

What this means for WhenToMeet

We don't have a chat panel in WhenToMeet and we're not planning to build one. It would work; it would demo well; it would make the next funding round slide easier. But it would be the less interesting version of this.

Instead we ship a REST API at /api/v1/ and an MCP server at /api/mcp. Both use the same keys. Both cover the surface an assistant actually needs: list events, get one, create a new one, list bookings, pull the unified calendar feed, check conflicts, read your own profile.

An agent with those seven capabilities can do most of what anyone has ever asked a "scheduling assistant" to do. And it can do it inside the conversation the person is already having, with the context that conversation already has.

What the category still gets wrong

Two things.

First, most "AI scheduling" features optimize for novelty demos — "watch the model book a meeting from an email!" — instead of the boring reliability a person actually needs. If the agent sometimes creates the event on the wrong day, you stop trusting it, and then the feature is dead. Boring reliability comes from narrow, well-defined tools, not from prompting the model to guess.

Second, the industry keeps building assistants that live in one app. The user's assistant lives across apps. Those are different things, and the second one is what people want.

Where we're going

The short version of the roadmap: expand what the API and MCP tools cover, don't add an AI panel. Close the gaps where the agent can read but not write, read but not edit. Make the surface complete enough that nobody ever has to open our app to get scheduling work done, unless they want to.

If you want to try it today, grab an API key, point your MCP client at the endpoint, and ask it to look at your calendar. Setup is at docs.whentomeet.io.

The interesting AI isn't the one we'd build. It's the one you already use, pointed at a clean surface. That's the only version of "AI-first" worth shipping.