AI-first-Scheduling ist eigentlich API-first-Scheduling

Jedes Scheduling-Tool auf dem Markt liefert gerade ein KI-Feature aus. Die meisten davon sind dasselbe Feature: eine Chat-Box in der Ecke, in die du „buch mir was mit Anna am Donnerstag" tippst und das Modell dann ein Formular ausfüllt.

Das ist in Ordnung. Es ist auch nicht interessant.

Der Grund, warum es nicht interessant ist: Der Wert steckt nicht in der Chat-Box. Er steckt in allem, was der Assistent erreichen kann. Wenn der Assistent nur das erreichen kann, was das Design-Team eines Produkts in dessen Seitenleiste verdrahtet hat, hast du ein Formular durch ein etwas freundlicheres Formular ersetzt. Der Assistent, den du tatsächlich nutzt – Claude, ChatGPT, Cursor, was auch immer als Nächstes kommt – lebt nicht in diesem Produkt. Er lebt woanders, und er ist besser.

Zwei Modelle von „AI Scheduling"

Nenn sie embedded und agent-addressable.

Embedded AI ist das, was die meisten in der Kategorie gerade bauen. Der Anbieter hostet ein Modell, trainiert es auf das interne Vokabular der App und stellt es über ein Panel bereit. Das Modell kann nur das, was der Anbieter exponiert. Wenn es zusätzlich mit deinem CRM, deinen Notizen, deinem Repo, der Booking-Page einer Kolleg:in reden soll – tja, das tut es nicht. Das ist ein eigenes Produkt.

Agent-addressable ist das Gegenteil. Der Anbieter liefert keine KI aus. Der Anbieter liefert eine saubere, dokumentierte Oberfläche aus – eine REST-API, einen MCP-Server, Webhooks – und lässt den Agenten, dem der Nutzer ohnehin vertraut, darauf operieren. Das Modell ist kein Feature der App. Die App ist ein Feature der Welt des Modells.

Das zweite gewinnt für alle, die schon einen Lieblingsassistenten haben. Und die Schnittmenge aus „Person, die AI Scheduling nutzen würde" und „Person mit Lieblingsassistenten" ist groß und wächst.

Der Test

Ein guter Test dafür, ob ein Scheduling-Tool tatsächlich AI-first ist: Kann ein Agent von außerhalb der App etwas Nützliches damit machen?

Bei einem Embedded-AI-Produkt ist die Antwort fast immer nein. Du kannst das Chat-Panel nutzen, das sie gebaut haben. Du kannst nicht deinen eigenen Agenten deine Bookings in einen Wochenbericht lesen, sie mit deinem CRM korrelieren, Konflikte vor einem vorgeschlagenen Fokus-Block prüfen oder dich über einen selbst geschriebenen Workflow buchen lassen. Der Assistent des Anbieters ist der einzige Assistent.

Bei einem agent-addressable Produkt ist die Antwort ja. Wenn es eine API mit genug Oberfläche gibt, um die echten Absichten eines Nutzers abzubilden – „was steht in meinem Kalender", „kollidiert das", „leg das an" – kann jeder Agent sie fahren. Heute heißt das Claude, ChatGPT, Cursor. Morgen heißt es, was auch immer die Leute als Nächstes nutzen. Das Tool muss nicht raten.

Was das für WhenToMeet bedeutet

Wir haben kein Chat-Panel in WhenToMeet und wir planen auch keines zu bauen. Es würde funktionieren; es würde sich gut demoen; es würde den nächsten Pitch Deck-Slide einfacher machen. Aber es wäre die weniger interessante Version davon.

Stattdessen liefern wir eine REST-API unter /api/v1/ und einen MCP-Server unter /api/mcp aus. Beide nutzen die gleichen Keys. Beide decken die Oberfläche ab, die ein Assistent tatsächlich braucht: Events auflisten, eines lesen, eines neu anlegen, Bookings auflisten, den vereinheitlichten Kalender-Feed abrufen, Konflikte prüfen, das eigene Profil lesen.

Ein Agent mit diesen sieben Fähigkeiten kann das meiste von dem, was irgendjemand je von einem „Scheduling-Assistenten" erwartet hat. Und zwar innerhalb der Konversation, die die Person ohnehin schon führt, mit dem Kontext, den diese Konversation schon hat.

Was die Kategorie immer noch falsch macht

Zwei Dinge.

Erstens optimieren die meisten „AI Scheduling"-Features auf Demo-Neuigkeit – „schau, wie das Modell aus einer E-Mail ein Meeting bucht!" – statt auf die langweilige Verlässlichkeit, die jemand tatsächlich braucht. Wenn der Agent das Event manchmal am falschen Tag anlegt, vertraust du ihm nicht mehr, und dann ist das Feature tot. Langweilige Verlässlichkeit kommt aus schmalen, gut definierten Tools, nicht aus dem Hoffen, dass das Modell richtig rät.

Zweitens bauen in der Branche alle weiter Assistenten, die in einer App leben. Der Assistent der Nutzer:in lebt quer über Apps. Das sind zwei verschiedene Dinge, und das zweite ist das, was die Leute wollen.

Wohin wir gehen

Die Kurzfassung der Roadmap: Wir erweitern, was API und MCP-Tools abdecken, und bauen kein KI-Panel. Wir schließen die Lücken, wo der Agent lesen, aber nicht schreiben kann, lesen, aber nicht bearbeiten. Wir machen die Oberfläche vollständig genug, damit niemand unsere App öffnen muss, um Scheduling-Arbeit zu erledigen – es sei denn, sie oder er will.

Wenn du es heute ausprobieren willst, schnapp dir einen API-Key, richte deinen MCP-Client auf den Endpoint und frag ihn, deinen Kalender anzuschauen. Setup unter docs.whentomeet.io.

Die spannende KI ist nicht die, die wir bauen würden. Es ist die, die du schon nutzt, gerichtet auf eine saubere Oberfläche. Das ist die einzige Version von „AI-first", die es wert ist, ausgeliefert zu werden.