Dropbox torna o Reclaim AI-native sem reescrever o produto do zero

O ponto central do texto da Dropbox é arquitetural: a Reclaim, assistente de calendário da empresa, não ganhou um caminho paralelo só para IA. Antes, as mudanças vinham de dois atores, o usuário (mover um evento, mudar uma configuração) e o scheduler automatizado, que trabalha em segundo plano com preferências e disponibilidade. Os agentes entraram como terceiro ator, e os três passam pelo mesmo tipo, o Schedule Action, que representa operações padrão como criar ou atualizar evento, mudar RSVP ou buscar disponibilidade. Validação e commit são os mesmos para todos, então a regra muda em um lugar só.

O problema que motiva isso é a variabilidade dos modelos. Um pedido como "make time for this tomorrow" pode virar um bloco livre, um evento novo ou o deslocamento de algo existente, com efeito até na agenda de outras pessoas. Daí o Preview Mode, que mostra uma versão temporária do calendário para revisar sugestões e pedidos feitos por chat antes de aplicar. Para ele ser rápido, o scheduler foi refatorado como função pura (calcula uma proposta sem gravar nada no calendário real) e os dados de agenda e disponibilidade ficam em cache no Redis, atualizados a cada evento movido no preview.

Outras decisões de engenharia: a Dropbox construiu por conta própria o agent loop, as ferramentas e a coleta de contexto, conectando direto aos provedores de modelo, porque o framework que testou ficava atrás das APIs dos provedores e trazia estrutura demais. O custo é mais código para manter, em parte compensado com agentes ajudando nessa manutenção. O mesmo sistema de ferramentas suporta Model Context Protocol (MCP): um cliente MCP dentro do loop e um servidor MCP que expõe ferramentas da Reclaim a clientes como Claude e ChatGPT.

Para quem integra agentes a um produto existente, a leitura é que o ganho não está no modelo, e sim em reaproveitar a lógica de domínio já testada e colocar uma etapa de revisão antes do efeito colateral. Funções puras e cache rápido tornam essa revisão viável em tempo de interação. A escolha de não depender de um framework de agentes também mostra o trade-off: mais controle e adoção rápida de novos recursos dos provedores, em troca de mais código próprio.