Cursor Revelou as Lições do Ano de Desenvolvimento de Agentes AI em Nuvem

Quando Cursor lançou agentes em nuvem há um ano, pareciam uma extensão direta de agentes locais. Agora ficou claro: agentes em nuvem funcionam em um paradigma diferente — são executados em máquinas virtuais próprias, funcionam em paralelo e resolvem tarefas que se estendem por horas e dias. Isso requer uma abordagem completamente diferente para infraestrutura.

O Ambiente é o Produto

A descoberta principal do ano: a qualidade do ambiente de desenvolvimento é o fator principal para a produtividade do agente em nuvem. Em uma máquina local, o agente herda seu ambiente gratuitamente — todo o histórico de instalações, configurações, variáveis. Na nuvem, é preciso recriar tudo do zero.

Quando algo não funciona, o agente não falha com um erro óbvio — degrada silenciosamente. A saída parece simplesmente pior do que antes, e é fácil culpar o modelo. Mas na prática, o culpado é o ambiente: dependências ausentes, caminhos incorretos, falta de ferramentas de verificação.

Um ano atrás, isso não era notado — os modelos não conseguiam usar o ambiente de forma eficiente. Agora, que a família GPT ficou mais inteligente, o ambiente se tornou o fator determinante para o desempenho completo do agente.

Um ambiente em nuvem completo requer uma quantidade surpreendentemente grande de infraestrutura:

• Ferramentas para construir e configurar o ambiente do agente
• Mecanismos de hibernação e retomada rápida de VM entre mensagens
• Pipelines para checkpoint confiável, restauração e fork de imagens de VM
• Integração rigorosa com harness e cliente — para que o agente e a pessoa leiam e ajam igualmente no ambiente

Além disso, agentes em nuvem precisam de acesso de rede controlado: abrir PRs, fazer pull de dependências, fazer pesquisa. Resultado é toda uma direção — algo como TI empresarial para agentes, com proteção de credenciais, políticas de rede e gerenciamento de segredos.

De Um Nove para Dois Noves

Agentes em nuvem abriram uma nova classe de problemas de confiabilidade. Cada agente funciona em sua própria VM isolada, o que permite executá-los em paralelo e delegar tarefas de muitas horas. Mas isso cria vulnerabilidade a interrupções do provedor de inferência, substituição de pods e falha de nós.

Inicialmente, Cursor construiu agentes em nuvem com arquitetura work-stealing: nós de trabalho captavam tarefas e as conduziam até a conclusão. Esse modelo funcionou localmente, mas na nuvem se mostrou frágil — a beta anterior fornecia cerca de um nove de confiabilidade (90% de tempo funcionando). Quando os agentes amadureceram, o time percebeu que estava reinventando primitivos de execução durável que Temporal já resolvia bem: mecanismos de retry, agendamento de trabalho entre máquinas, durabilidade em caso de falha de nós. Decidiram migrar todo o agent-loop para Temporal. Resultado: confiabilidade aumentou para dois noves (99% uptime).

Agora Temporal processa mais de 50 milhões de ações por dia em 7 milhões de fluxos de trabalho. Internamente, mais de 40% de todos os PRs no Cursor são gerados por agentes em nuvem — isso é em si um indicador de que o sistema funciona.

O que Isso Significa

Um ano de trabalho com agentes em nuvem mostrou: não é simplesmente portar código local para a nuvem. É construir uma camada operacional completa em torno do agente — com ambiente de desenvolvedor completo, entrega confiável de tarefas e acesso de rede controlado. À medida que os agentes assumem cada vez mais trabalho, a tarefa de engenharia se torna cada vez mais clara: fornecer à máquina exatamente o que o desenvolvedor tem e garantir que ela não o quebre.