Quando lançamos os agentes na nuvem pela primeira vez, há um ano, eles pareciam uma extensão natural dos agentes locais. Desde então, os agentes na nuvem evoluíram bastante.

Agora, os agentes na nuvem rodam em suas próprias máquinas virtuais dedicadas, com ambientes, dependências e acesso à rede próprios. Eles podem trabalhar em paralelo, operar sem supervisão e assumir tarefas mais longas do que um agente local rodando no seu laptop.

Essas capacidades trazem desafios de configuração de ambiente, confiabilidade e orquestração que são menos evidentes quando um agente está rodando no seu laptop.

Nesta postagem, queremos compartilhar as principais lições que aprendemos desenvolvendo agentes na nuvem e por que esse trabalho se parece cada vez menos com portar um agente local para um servidor e mais com desenvolver uma camada operacional ao redor dele.

#O ambiente de desenvolvimento é o produto

No último ano, aprendemos que o fator isolado mais importante para a qualidade dos resultados de um agente na nuvem é garantir que ele tenha um ambiente de desenvolvimento completo, como o de um desenvolvedor.

Isso não é algo em que você precise pensar tanto no ambiente local, porque os agentes locais herdam automaticamente, do seu laptop, o ambiente de desenvolvimento em que você já trabalha. Na nuvem, é preciso reconstruir tudo isso do zero — e é surpreendentemente difícil perceber quando isso não foi feito perfeitamente.

Em vez de uma falha ou de uma mensagem de erro, muitas vezes o único sinal é uma sutil queda na qualidade dos resultados. Talvez você nem perceba isso de imediato ou, se perceber, acabe atribuindo ao modelo.

Mas, repetidas vezes, chegamos ao mesmo diagnóstico: o agente na nuvem não tem o ambiente de que precisa para executar ou verificar o próprio trabalho. Há um ano, isso importava menos, porque os modelos ainda não conseguiam aproveitar muito bem o ambiente. Mas, à medida que ficaram mais inteligentes, a configuração do ambiente passou a ser o fator determinante para que operem em todo o seu potencial.

Hoje, chegar a um "ambiente completo" exige reconstruir uma quantidade surpreendente de infraestrutura:

• Ferramentas melhores para os usuários desenvolverem o ambiente do agente
• Métodos para hibernar e retomar VMs de agentes com eficiência entre mensagens
• Pipelines para criar checkpoints, restaurar e bifurcar imagens de VM de forma rápida e durável
• Integrações estreitas entre harness e cliente para que agentes e humanos possam interpretar o ambiente e interagir com ele

E, à medida que os agentes na nuvem assumem mais trabalho, precisam de acesso controlado à rede para criar PRs, baixar dependências e fazer pesquisa. Com o tempo, acabamos desenvolvendo o que é, na prática, uma TI empresarial para agentes, com ocultação de segredos, políticas de rede e gerenciamento de credenciais.

#Agentes de longa duração precisam de execução durável

Agentes na nuvem apresentam um tipo diferente de desafio de confiabilidade em relação aos agentes locais. Em vez de competir por recursos locais no seu laptop, os agentes na nuvem são executados em suas próprias VMs isoladas. Isso facilita que desenvolvedores executem muitos agentes em paralelo e deleguem tarefas de longa duração que muitas vezes levam horas, e não minutos.

Mas executar em uma VM também traz exposição a interrupções, como indisponibilidades do provedor de inferência, pods que precisam ser substituídos e nós de EC2 que saem do ar.

Começamos a desenvolver agentes na nuvem com uma arquitetura de work stealing, em que nós workers podiam assumir agentes e processá-los em loop até a conclusão. Ela levava para um servidor o que funciona localmente, mas era uma configuração frágil — nossa beta inicial de agentes na nuvem frequentemente operava com apenas um nove de confiabilidade.

À medida que os agentes na nuvem amadureceram, percebemos que estávamos prestes a reconstruir muitos dos primitivos de execução durável que o Temporal já resolve (por exemplo, mecanismos de retry, escalonamento de trabalho entre máquinas e durabilidade diante de falhas de nós), então migramos para lá.

Nosso loop de agente atual no Temporal consegue sobreviver a oscilações na confiabilidade da inferência, hibernação e retomada de pods, e execuções que se estendem por dias ou até semanas. Só essa migração já nos levou para mais de dois noves de confiabilidade e, hoje, o Temporal lida com mais de 50 milhões de ações por dia em mais de 7 milhões de fluxos de trabalho únicos. Internamente, mais de 40% das nossas PRs vêm de agentes na nuvem, e esse número só cresce.

Com o tempo, aprendemos a arquitetar melhor nossos fluxos de trabalho no Temporal. Saímos de fluxos de trabalho de agente "eternos" para vários fluxos mais curtos, que se encerram após concluir uma única tarefa, o que facilita upgrades de versão. Também passamos a separar as atividades para capturar melhor timeouts e retries, à medida que chamadas de ferramenta assíncronas, subagentes e indisponibilidades do provedor de inferência mudaram nossas premissas subjacentes.

#Desacoplando agentes e máquinas do estado da conversa

Um agente na nuvem não é mais apenas um loop em execução em uma única máquina. Em vez disso, um agente pode executar em uma máquina, iniciar subagentes assíncronos em várias outras ou começar localmente e depois delegar trabalho para a nuvem. Um subagente pode até sobreviver ao seu pai ou executar em um tipo de pod completamente diferente.

Para viabilizar isso, consideramos importante manter o loop do agente, o estado da máquina e o estado da conversa como componentes desacoplados. Como o loop do agente fica no Temporal em vez de na própria VM, podemos gerenciar os ciclos de vida dos pods de forma independente e executar agentes em diferentes tipos de pods — incluindo otimizações como VMs somente leitura ou VMs pré-aquecidas.

No lado da conversa, separamos a camada de armazenamento e streaming do fluxo de trabalho principal do agente. Desenvolvemos um mecanismo eficiente de armazenamento append-only que transmite atualizações da conversa para clientes web e desktop. Essa camada leva em conta retries, de modo que, se uma etapa do loop do agente falhar depois de transmitir uma saída parcial e então for tentada novamente, o cliente poderá detectar isso, retroceder o stream e mostrar os novos dados em vez dos antigos.

#Saber quando sair do caminho

Desenvolver um harness de agente na nuvem significa reavaliar constantemente quanto do comportamento é determinístico e quanto fica a cargo do agente.

No início, não confiávamos muito no agente, então o harness conferia o trabalho dele após cada tarefa, forçava um commit e fazia push. À medida que os modelos ficaram mais inteligentes, começamos a tirar a lógica do harness e passá-la para ferramentas controladas pelo agente. Há um ano, configurações multi-repo exigiam comportamento codificado no próprio harness. Agora, podemos fornecer ao agente o layout do repositório, expor ferramentas para branches e PRs e deixá-lo decidir como executar o trabalho.

A mesma coisa aconteceu com o CI Autofix, em que versões anteriores do nosso harness de agente na nuvem continham lógica para capturar logs de falha de jobs e gravá-los na VM. Agora, apenas damos ao agente acesso ao GitHub CLI e gravamos automaticamente saídas extensas em arquivos nos quais ele pode fazer busca. A mensagem para o agente ficou muito mais simples, e esperamos que essa tendência continue.

O harness não está deixando de existir; o que está mudando é o seu conteúdo. O uso do computador é um bom exemplo disso neste momento. Nosso harness de agente na nuvem tem um tipo dedicado de subagente para uso do computador, com seu próprio roteamento de modelo, prompts personalizados e gravação de tela. O VNC e o Chrome pertencem ao ambiente, que é compartilhado entre o agente principal e o subagente. Isso permite que o agente principal os use diretamente, por exemplo, executando um script Playwright. Usamos essa estrutura porque os modelos ainda não estão prontos para lidar com o uso do computador por conta própria, mas o agente ainda controla quando acioná-lo.

Agentes na nuvem também precisam de tipos de prompts diferentes no harness em relação aos agentes locais. Nós os incentivamos a ser mais autônomos, porque o custo de bloquear é muito maior. Localmente, você sabe quando um agente parou e está esperando permissão, mas, na nuvem, ele pode ficar ali por horas antes de você voltar para verificar como ele está.

#Ambientes de agentes com autorrecuperação

Olhando para o futuro, nosso foco é ir além da escolha binária entre guiar o agente o tempo todo e simplesmente deixá-lo agir sozinho. Um caminho melhor é dar ao agente ferramentas para entender o sistema ao seu redor.

Queremos que agentes na nuvem consigam informar quando faltarem segredos, quando o acesso à rede estiver bloqueado ou quando o ambiente estiver, de alguma outra forma, impedindo seu progresso — e então possam agir de forma autorrecuperável. Em um post recente no blog de pesquisa, falamos sobre um caminho para alcançar isso, que chamamos de “autoinstall”.

Os agentes na nuvem melhoraram imensamente só nos últimos meses, e esperamos que o ritmo dessas mudanças continue acelerando daqui para frente. Os agentes na nuvem do Cursor permitem que equipes aproveitem esse amplo conjunto de possibilidades sem precisar construir ou manter a infraestrutura por trás disso.