Scheduling AI-first é, na verdade, scheduling API-first

Cada ferramenta de scheduling no mercado está a lançar uma feature de IA. A maior parte é a mesma feature: uma caixa de chat no canto onde escreves "marca-me com a Anna na quinta" e deixas o modelo preencher um formulário.

Está bem. Também não é interessante.

O motivo para não ser interessante é que o valor não está na caixa de chat. Está em tudo aquilo que o assistente consegue alcançar. Se o assistente só consegue alcançar o que os designers de uma equipa cablaram na barra lateral de um produto, substituíste um formulário por outro um pouco mais simpático. O assistente que realmente usas — Claude, ChatGPT, Cursor, o que vier a seguir — não vive dentro desse produto. Vive noutro sítio, e é melhor.

Dois modelos de "AI scheduling"

Chama-lhes embedded e agent-addressable.

Embedded AI é o que a maioria da categoria está a fazer. O fornecedor aloja um modelo, treina-o no vocabulário interno da app e expõe-no num painel. O modelo só pode fazer o que o fornecedor expôs. Se queres que também fale com o teu CRM, os teus apontamentos, o teu repo, a booking page de um colega — pois não. Isso é outro produto.

Agent-addressable é o inverso. O fornecedor não envia uma IA. O fornecedor envia uma superfície limpa e documentada — uma REST API, um servidor MCP, webhooks — e deixa que o agente em que o utilizador já confia opere sobre ela. O modelo não é uma feature da app. A app é uma feature do mundo do modelo.

O segundo ganha para quem já tem um assistente preferido. E a sobreposição entre "pessoa que usaria AI scheduling" e "pessoa com assistente preferido" é grande e a crescer.

O teste

Um bom teste para saber se uma ferramenta de scheduling é mesmo AI-first: consegue um agente fazer algo útil com ela, a partir de fora da app?

Para um produto embedded-AI, a resposta é quase sempre não. Podes usar o painel de chat que eles construíram. Não podes fazer com que o teu próprio agente leia os teus bookings para um relatório semanal, os correlacione com o teu CRM, verifique conflitos antes de um bloco de foco proposto, ou te marque por um workflow que tu escreveste. O assistente do fornecedor é o único assistente.

Para um produto agent-addressable, a resposta é sim. Se há uma API com superfície suficiente para representar a intenção real do utilizador — "o que há no meu calendário", "isto colide", "cria isto" — qualquer agente consegue conduzi-la. Hoje isso significa Claude, ChatGPT, Cursor. Amanhã significa o que quer que as pessoas adotem. A ferramenta não precisa de adivinhar.

O que isto significa para o WhenToMeet

Não temos um painel de chat no WhenToMeet e não planeamos construir um. Funcionaria; faria boa demo; tornaria o próximo pitch mais fácil. Mas seria a versão menos interessante disto.

Em vez disso, enviamos uma REST API em /api/v1/ e um servidor MCP em /api/mcp. Ambos usam as mesmas chaves. Ambos cobrem a superfície que um assistente realmente precisa: listar events, ler um, criar um novo, listar bookings, puxar o feed de calendário unificado, verificar conflitos, ler o próprio perfil.

Um agente com estas sete capacidades consegue fazer a maior parte do que alguém alguma vez pediu a um "assistente de scheduling". E consegue fazê-lo dentro da conversa que a pessoa já está a ter, com o contexto que essa conversa já tem.

O que a categoria continua a fazer mal

Duas coisas.

Primeiro, a maior parte das features de "AI scheduling" otimiza para demo de novidade — "olha o modelo a marcar uma reunião a partir de um email!" — em vez da fiabilidade aborrecida que uma pessoa realmente precisa. Se o agente às vezes cria o evento no dia errado, deixas de confiar, e a feature morre. Fiabilidade aborrecida vem de tools estreitas e bem definidas, não de cruzar os dedos para que o modelo acerte.

Segundo, a indústria continua a construir assistentes que vivem numa só app. O assistente da utilizadora vive entre apps. São coisas diferentes, e a segunda é o que as pessoas querem.

Para onde vamos

A versão curta do roadmap: aumentar o que a API e as tools MCP cobrem, não adicionar um painel de IA. Fechar as lacunas onde o agente consegue ler mas não escrever, ler mas não editar. Tornar a superfície suficientemente completa para que ninguém tenha de abrir a nossa app para fazer trabalho de scheduling, a menos que queira.

Se queres experimentar hoje, apanha uma API key, aponta o teu cliente MCP ao endpoint e pede-lhe para olhar para o teu calendário. Setup em docs.whentomeet.io.

A IA interessante não é a que construiríamos. É a que já usas, apontada para uma superfície limpa. É a única versão de "AI-first" que vale a pena enviar.