Agentes de IA do Cursor em maio de 2026: 2 lacunas ainda em aberto

Em 13 de maio, o Cursor lançou ambientes multi-repositório para agentes de IA na nuvem. Segundo a própria página do produto, mais de 30% dos pull requests que o Cursor mescla já são criados por agentes autônomos operando em sandboxes na nuvem.

O que mudou nos agentes de IA do Cursor em 13 de maio

O principal recurso são os ambientes multi-repositório para agentes na nuvem. Agora, eles conseguem trabalhar em vários repositórios dentro de um único ambiente configurado, ampliando os workspaces multi-root lançados pelo Cursor em 24 de abril. Como o ambiente pode ser reutilizado entre sessões, vem o ganho prático: não é mais preciso reconfigurar a mesma máquina de desenvolvimento toda vez que um agente começa a trabalhar.

A configuração é feita por um Dockerfile. Segredos usados no build ficam restritos a essa etapa e não são repassados ao agente em execução. Isso elimina o deslize mais comum na infraestrutura de agentes: uma chave de API incorporada por engano ao build terminar na memória de trabalho do agente. O Cursor também consegue configurar o Dockerfile depois de analisar as ferramentas e dependências dos repositórios. Esse fluxo continua em beta privado para equipes Enterprise.

O maior salto de desempenho veio do cache de camadas. Builds com cache hit agora rodam 70% mais rápido, porque apenas as camadas alteradas do Dockerfile são refeitas. Em equipes que iniciam agentes repetidamente, é a diferença entre esperar e produzir.

A operação é justamente o ponto que os concorrentes continuam tratando como detalhe. Cada ambiente mantém um histórico de versões com rollback, restrito a administradores. Um log de auditoria registra todas as ações realizadas pelos membros da equipe nos ambientes. As listas de permissão de tráfego de saída e os escopos de segredos são definidos por ambiente; assim, um segredo disponível no ambiente A não pode ser acessado pelo ambiente B. É a infraestrutura pouco glamourosa, mas indispensável antes de permitir que um agente abra PRs contra código de produção.

O exemplo apresentado pelo Cursor no anúncio é o da Amplitude. As Cursor Automations da empresa monitoram canais públicos do Slack, investigam os problemas relatados, identificam quais repositórios foram afetados e abrem PRs nos repositórios corretos. É um agente multi-repositório fazendo a triagem inicial em uma empresa real e em escala real. Não é uma demonstração.

O número de PRs mescladas comprova a adoção dos agentes de IA do Cursor

Segundo o Cursor, mais de 30% dos pull requests que ele mescla já são criados por agentes autônomos operando em sandboxes na nuvem. O denominador faz diferença: são pull requests mesclados, não tentativas dos agentes. Esse é o dado que mostra que o ciclo consegue passar por revisão, correções e entrega sem depender de uma pessoa para enviar cada commit.

Desde 2 de setembro de 2026, o Self-Hosted Machines do Cursor permite que as equipes transfiram edições de arquivos, comandos de terminal, ferramentas de computer use e a execução local de MCP para workers gerenciados pelo cliente, enquanto o Cursor mantém o ciclo do agente, a inferência e o planejamento em sua nuvem. Isso fecha a lacuna do local de execução privada, mas não transforma o Cursor em um runtime durável e programável.

A escolha já não se resume a estado restrito à sessão versus estado durável. O Cursor persiste o estado da conversa em seu backend, permitindo revisitar e retomar execuções, enquanto os Self-Hosted Team Pools conseguem restaurar um workspace hibernado. A distinção mais precisa é estado do agente gerenciado pelo fornecedor versus estado programável da aplicação. A Cloudflare expõe estado SQLite por Agent e etapas duráveis de workflow controladas em código.

O que minha stack com Cloudflare Workers e Agents SDK já entrega

Mantenho seis agentes em produção na Cloudflare. O runtime é Workers; o estado fica em Durable Objects com SQLite por instância; e a orquestração de longa duração roda no Cloudflare Workflows. É um projeto solo, em uma única conta, explicado em detalhes aqui. A stack completa da Cloudflare custou $19.14 em abril de 2026. É uma conta real de produção daquele período, não uma cotação da plataforma. O Cursor apresenta o preço do Enterprise como Custom; Team Pools exigem Enterprise, e Self-Hosted Machines ainda envolve cobranças pelo modelo escolhido, além da conta dos seus workers.

Há três diferenças entre essa stack e o produto atual do Cursor.

Multi-repo, por código. Um Worker consegue buscar recursos por HTTP durante a execução. O Browser Run, antes chamado Browser Rendering, controla um navegador headless quando o contexto está por trás de um site. O Cursor empacota o acesso multi-repositório como uma configuração de ambiente reutilizável; a Cloudflare deixa por sua conta a busca, a autenticação e a lógica dos repositórios. Não é melhor nem pior — é uma superfície de controle diferente.

Estado durável programável. Um Cloudflare Agent salva automaticamente o estado da aplicação em seu próprio banco SQLite e o recarrega depois de uma reinicialização ou hibernação. O Cursor também preserva o estado da conversa e permite retomar execuções. A diferença está no controle: o Cursor é responsável pelo armazenamento das conversas e pelo runtime do agente, enquanto a Cloudflare expõe ao seu código o estado da aplicação e o respectivo schema.

Etapas duráveis definidas em código, sem garantia automática de execução única. No Workflows, cada etapa pode ser repetida individualmente e emitir estado para que a execução persista e continue após uma falha de rede ou infraestrutura. step.do aceita uma configuração de novas tentativas por etapa, NonRetryableError interrompe as tentativas diante de falhas terminais, e os IDs de instância são únicos por Workflow. Ainda assim, uma etapa pode rodar mais de uma vez, e a Cloudflare orienta explicitamente que chamadas com efeitos colaterais sejam idempotentes. A vantagem está na durabilidade definida pelo desenvolvedor e no controle das tentativas, não em uma proteção automática contra pull requests, e-mails ou cobranças duplicadas.

As duas lacunas que os agentes de IA do Cursor ainda não fecharam

Lacuna 1: estado programável do agente sob controle do cliente. O Cursor já resolveu a retomada básica: por padrão, o estado da conversa é mantido por tempo indeterminado, e os snapshots das VMs gerenciadas seguem uma janela móvel de 90 dias de inatividade. Self-Hosted Machines transfere a execução das ferramentas, mas o Cursor continua operando o ciclo do agente e armazenando a conversa. Um Cloudflare Agent expõe estado baseado em SQLite dentro do runtime da aplicação. Isso faz diferença quando um agente monitora incidentes, coordena uma migração ou carrega estado de negócio ao longo de um onboarding de vários dias.

Essa lacuna é mais específica do que a descrita em maio. O Cursor consegue retomar as execuções de agentes do próprio produto, mas não expõe uma máquina de estados pertencente ao cliente que a aplicação possa consultar, ampliar e coordenar independentemente de um chat do Cursor.

Lacuna 2: uma superfície de etapas duráveis definida pelo desenvolvedor. A documentação atual de Cloud Agent e Self-Hosted Machine do Cursor não expõe uma primitiva de aplicação equivalente a uma etapa de Workflow com estado persistido e configuração de novas tentativas por etapa. A Cloudflare expõe. Essa diferença importa quando um agente de programação passa a interagir com cobrança, e-mail, implantação ou qualquer outro efeito externo.

Transferir as chamadas de ferramentas para uma máquina própria não fecha essa lacuna, porque muda o local de execução, não o contrato de orquestração. A Cloudflare tampouco garante efeitos colaterais exatamente uma vez; ainda é necessário tornar idempotente uma etapa sujeita a novas tentativas.

Nada disso é uma crítica ao Cursor. É uma diferença de categoria. O Cursor é um produto de programação que oferece execução de ferramentas tanto gerenciada quanto operada pelo cliente. A Cloudflare é um runtime de aplicação programável. O lançamento de setembro reduz a lacuna de infraestrutura, mas a fronteira de estado e orquestração ainda separa os dois.

O que fundadores e CTOs devem fazer nesta semana

Três perfis pedem três decisões diferentes.

Para uma equipe pequena de produto focada em entregar funcionalidades, use os Cloud Agents gerenciados pelo Cursor quando os ambientes e controles de rede conseguirem reproduzir seu build. O lançamento dos ambientes em 13 de maio resolve configuração multi-repositório, segredos de build, cache e auditabilidade, enquanto a divulgação de que mais de 30% das PRs mescladas vêm de agentes é a comprovação pública. Não opere uma frota de workers sem que exista uma política interna que exija isso.

Se você já usa Cloudflare ou Vercel para processos de longa duração em segundo plano, mantenha ali o estado durável da aplicação e a orquestração. Agora, Cursor Self-Hosted Machines pode usar a infraestrutura da Cloudflare ou da Vercel para executar ferramentas, mas o Cursor continua responsável pelo ciclo do agente. Há um paralelo do lado do consumidor que vale a leitura sobre como a Anthropic empacota componentes semelhantes para pequenas e médias empresas — esse movimento de plataformas convergindo em torno de agentes aparece por toda parte.

Se você está planejando uma adoção corporativa, comece com Cloud Agents gerenciados quando listas de permissão, Tailscale, AWS PrivateLink ou Cloudflare Tunnel atenderem ao requisito de acesso. Use Team Pools quando o checkout, a execução de ferramentas, o hardware personalizado ou a imagem do worker precisarem permanecer sob seu controle. Team Pools exigem Enterprise, cujo preço é Custom, e Dockerfiles configurados pelo Cursor continuam em beta privado.

O que mudou depois de maio

Dois sinais.

Primeiro, o Cursor agora documenta o estado da conversa separadamente do workspace de runtime. Por padrão, esse estado é mantido por tempo indeterminado para que as execuções possam ser revisitadas e retomadas; os snapshots das VMs gerenciadas expiram após 90 dias de inatividade, a menos que um início ou uma retomada prolongue essa janela. Retomada básica já não é uma lacuna. As diferenças agora estão na propriedade e na programabilidade.

Segundo, o local de execução privada também deixou de ser uma lacuna. Self-Hosted Machines resolve essa questão, embora o ciclo do agente, a inferência e o planejamento continuem na nuvem do Cursor. Estado do agente sob controle do cliente e uma superfície de etapas duráveis definida pelo desenvolvedor seguem como as duas diferenças relevantes.

O lançamento do Cursor em 13 de maio elimina a necessidade de infraestrutura self-hosted para agentes?

Não. Agora o Cursor oferece caminhos self-hosted próprios: My Machines para fluxos pessoais e Team Pools para frotas Enterprise. Isso transfere a execução das ferramentas para a sua rede, mas o Cursor continua executando o ciclo do agente e armazenando o estado da conversa. Equipes que precisam de um runtime de aplicação programável ou de etapas duráveis de workflow ainda necessitam de infraestrutura para essas camadas.

Qual foi o ganho de velocidade dos builds em cache dos agentes na nuvem do Cursor?

Builds com cache hit rodam 70% mais rápido após a atualização de cache de camadas de 13 de maio. Em um cache hit, apenas as camadas alteradas do Dockerfile são refeitas.

O que significa o número interno de PRs mescladas divulgado pelo Cursor?

A página oficial atual do Cursor informa que mais de 30% dos pull requests que ele mescla são criados por agentes autônomos operando em sandboxes na nuvem. É uma evidência útil de adoção em produção porque mede pull requests mesclados, não tarefas tentadas.

Os agentes na nuvem do Cursor são seguros para código que acessa segredos de produção?

O lançamento de 13 de maio define tráfego de saída e segredos por ambiente, isola os segredos de build do agente em execução e oferece histórico de versões, rollback e logs de auditoria. Com Self-Hosted Machines, é possível manter o checkout completo e as credenciais locais da máquina no seu worker, mas conteúdos necessários de arquivos, saídas de ferramentas, diffs, capturas de tela e resultados locais de MCP ainda podem seguir para o Cursor. A segurança depende de avaliar os dois limites.

Posso usar Cloudflare Workers e os agentes na nuvem do Cursor lado a lado?

Sim. O Cursor apresenta a Cloudflare como uma integração de Self-Hosted Machines, e seu template de referência usa um Cloudflare Worker como controlador para iniciar um Cloudflare Container para cada requisição assumida. O Cursor pode cuidar do ciclo do agente de programação, enquanto Workers, Durable Objects e Workflows mantêm o estado durável da aplicação e a orquestração. Agora os produtos se sobrepõem na execução de ferramentas, mas não na fronteira do ciclo do agente.