Cursor permite rodar cloud agents em máquinas da própria empresa

O Cursor anunciou que seus agentes na nuvem podem ser executados em pools de máquinas agendados dinamicamente dentro da rede da própria empresa. A infraestrutura subjacente é gerenciada pelo cliente, enquanto os agentes continuam sendo iniciados e gerenciados pelo Cursor. Segundo o texto, os agentes na nuvem criam hoje mais de 60% das PRs que a empresa faz merge internamente e vêm assumindo uma parcela cada vez maior do trabalho de software em muitas das maiores empresas com que trabalha.

Controle sobre onde os agentes rodam

Os ambientes hospedados pelo Cursor continuam sendo o padrão: cada sessão roda em uma VM dedicada na nuvem da Cursor, com dependências instaladas e controles de rede próprios. O isolamento por agente, a supressão de secrets, os controles de egress e os commits assinados, afirma o texto, atendem aos requisitos de segurança da maioria das equipes.

As Máquinas Auto-hospedadas são indicadas, de modo geral, quando a execução de ferramentas do agente precisa acontecer dentro da rede da empresa, com acesso direto ao controle de versão, a serviços internos e a repositórios; quando os agentes exigem hardware personalizado, como GPUs ou Macs para desenvolvimento iOS, ou infraestrutura como Kubernetes, sandboxes ou VMs gerenciadas; ou quando o sistema operacional ou o pipeline de build é difícil de empacotar como um build de Agente na nuvem.

Nesse arranjo, apenas o ambiente de execução muda de lugar: o agente loop, a inferência e o planejamento permanecem na nuvem da Cursor. As saídas das ferramentas voltam para a Cursor para inferência e podem conter código, e as transcrições de agente podem ser processadas e armazenadas pela Cursor. O acesso aos agentes segue disponível pelo app de desktop, por cursor.com, por dispositivos móveis, Slack, GitHub e Linear.

Workers e pools

Com as Máquinas Auto-hospedadas, a execução de ferramentas deixa de ocorrer em uma VM hospedada pelo Cursor e passa para uma máquina no ambiente do cliente, que mantém a cópia de trabalho do repositório, edita arquivos e executa comandos. Um worker a conecta ao restante do sistema de agentes. Para registrar uma máquina, executa-se um worker instalando a CLI do Cursor e rodando o comando agent worker start, o que abre uma conexão HTTPS de saída de longa duração com a nuvem do Cursor. Quando uma sessão começa, o agente harness do Cursor cuida da inferência e do planejamento e envia as tool calls para um worker dedicado executá-las; o worker devolve os resultados para a próxima rodada de inferência. O texto afirma que o Cursor nunca inicia uma conexão para dentro da rede do cliente.

Os workers podem ser configurados de duas maneiras: Minhas Máquinas, que conecta um único notebook ou VM à conta e é mais indicada para fluxos pessoais; e Pools, uma fila nomeada de workers que pode atender uma equipe ou uma empresa, com capacidade que aumenta conforme as requisições chegam e diminui depois que os workers se desconectam.

A demanda por agentes na nuvem costuma chegar em picos, e os pools se ajustam automaticamente por meio de um controlador que monitora a fila de requisições e usa um script de spawn fornecido pela equipe para iniciar máquinas. Se houver worker disponível, ele assume a requisição; caso contrário, a requisição aguarda até que haja capacidade, de modo que as equipes não precisam decidir quantas máquinas deixar em execução. As equipes podem definir um tempo limite de ociosidade por conexão de worker; quando ele expira, a máquina pode ser reiniciada e voltar ao pool, e o espaço de trabalho pode ser preservado caso o agente receba uma continuação.

Manter uma máquina em execução enquanto o agente está ocioso pode sair caro, mas liberá-la pode fazer o agente levar vários minutos para reconstruir o espaço de trabalho quando chega uma continuação. Com a hibernação, as equipes podem criar um snapshot e parar a máquina ociosa. Se uma continuação chega dentro da janela de reconexão, o snapshot é restaurado e um worker inicia com o mesmo ID; caso contrário, a requisição pode ser transferida para uma nova máquina. Os pools não estão vinculados a repositórios específicos: a requisição só precisa identificar o pool, e qualquer worker disponível pode assumi-la, permitindo que um único pool atenda muitos repositórios.

Sandboxes, browser e Mac

As Máquinas Auto-hospedadas não exigem construir uma camada de sandbox personalizada do zero. O Cursor declara parceria com AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace e Vercel, permitindo iniciar e orquestrar workers onde os sandboxes da equipe já estejam em execução. Com as MicroVMs do Lambda como camada de computação, os desenvolvedores podem executar agentes de programação com IA na própria conta AWS: cada máquina é iniciada quase instantaneamente a partir de um snapshot, é suspensa quando ociosa e retomada com o estado completo.

Os workers Linux agora oferecem suporte a uso do computador, assim como os Macs. Com as dependências necessárias instaladas, incluindo Chrome ou Chromium, um agente pode clicar, tirar screenshots e controlar o browser, e é possível acompanhar o desktop dele ou assumir o controle diretamente do Cursor. Os Devboxes da Namespace sobem um Mac real para cada Agente na nuvem do Cursor, que passa a poder realizar trabalho em Apple silicon, necessário para construir apps para iOS ou macOS.

O texto conclui que as equipes passaram anos moldando sua infraestrutura de acordo com a forma como criam software e que as Máquinas Auto-hospedadas permitem que os agentes na nuvem se encaixem nela com mais naturalidade.