El scheduling AI-first en realidad es scheduling API-first
Cada herramienta de scheduling en el mercado está lanzando una feature de IA. La mayoría son la misma feature: un cuadro de chat en la esquina que te deja escribir "resérvame con Anna el jueves" y que el modelo rellene un formulario.
Está bien. Tampoco es interesante.
La razón de que no sea interesante es que el valor no está en el cuadro de chat. Está en todo lo que el asistente puede alcanzar. Si el asistente solo puede alcanzar lo que los diseñadores de un producto cablearon en la barra lateral, has reemplazado un formulario por un formulario un poco más amable. El asistente que realmente usas — Claude, ChatGPT, Cursor, lo que venga después — no vive dentro de ese producto. Vive en otro sitio, y es mejor.
Dos modelos de "AI scheduling"
Llámalos embedded y agent-addressable.
Embedded AI es lo que la mayoría de la categoría está haciendo. El proveedor hospeda un modelo, lo entrena en el vocabulario interno de la app y lo expone en un panel. El modelo solo puede hacer lo que el proveedor expuso. Si quieres que además hable con tu CRM, tus notas, tu repo, la booking page de tu compañero — pues no. Eso es un producto aparte.
Agent-addressable es el inverso. El proveedor no entrega una IA. El proveedor entrega una superficie limpia y documentada — una API REST, un servidor MCP, webhooks — y deja que el agente en el que el usuario ya confía opere sobre ella. El modelo no es una feature de la app. La app es una feature del mundo del modelo.
El segundo gana para cualquiera que ya tenga un asistente favorito. Y el solape entre "persona que usaría AI scheduling" y "persona con asistente favorito" es grande y creciente.
La prueba
Una buena prueba para saber si una herramienta de scheduling es de verdad AI-first: ¿puede un agente hacer algo útil con ella desde fuera de la app?
Para un producto embedded-AI la respuesta casi siempre es no. Puedes usar el panel de chat que construyeron. No puedes hacer que tu propio agente lea tus bookings en un informe semanal, los correlacione con tu CRM, revise conflictos antes de un bloque de enfoque propuesto, ni reservarte a través de un workflow que escribiste tú. El asistente del proveedor es el único asistente.
Para un producto agent-addressable la respuesta es sí. Si hay una API con suficiente superficie para representar la intención real del usuario — "qué hay en mi calendario", "esto choca", "crea esto" — cualquier agente puede manejarla. Hoy eso significa Claude, ChatGPT, Cursor. Mañana significa lo que la gente use después. La herramienta no tiene que adivinar.
Qué significa para WhenToMeet
No tenemos un panel de chat en WhenToMeet y no planeamos construir uno. Funcionaría; haría buena demo; haría más fácil la siguiente diapositiva de una ronda. Pero sería la versión menos interesante de esto.
En su lugar enviamos una API REST en /api/v1/ y un servidor MCP en /api/mcp. Ambos usan las mismas claves. Ambos cubren la superficie que un asistente realmente necesita: listar events, obtener uno, crear uno nuevo, listar bookings, tirar del feed de calendario unificado, revisar conflictos, leer tu propio perfil.
Un agente con esas siete capacidades puede hacer la mayor parte de lo que alguien alguna vez le ha pedido a un "asistente de scheduling". Y puede hacerlo dentro de la conversación que la persona ya está teniendo, con el contexto que esa conversación ya tiene.
Qué sigue haciendo mal la categoría
Dos cosas.
Primero, la mayoría de features de "AI scheduling" optimizan para demos de novedad — "¡mira al modelo reservar una reunión a partir de un email!" — en lugar de la fiabilidad aburrida que alguien realmente necesita. Si el agente a veces crea el evento en el día equivocado, dejas de confiar, y la feature se muere. La fiabilidad aburrida viene de tools estrechos y bien definidos, no de cruzar los dedos para que el modelo adivine.
Segundo, la industria sigue construyendo asistentes que viven en una sola app. El asistente de la usuaria vive a través de apps. Son cosas distintas, y la segunda es lo que la gente quiere.
A dónde vamos
La versión corta del roadmap: ampliar lo que cubren la API y los tools MCP, no añadir un panel de IA. Cerrar los huecos donde el agente puede leer pero no escribir, leer pero no editar. Hacer la superficie lo bastante completa como para que nadie tenga que abrir nuestra app para hacer trabajo de scheduling, salvo que quiera.
Si quieres probarlo hoy, consigue una API key, apunta tu cliente MCP al endpoint y pídele que mire tu calendario. Setup en docs.whentomeet.io.
La IA interesante no es la que construiríamos nosotros. Es la que ya usas, apuntada a una superficie limpia. Es la única versión de "AI-first" que vale la pena enviar.