Até agora, a relação entre dev e IA seguia um roteiro previsível: você abre o editor, digita um prompt, espera a resposta, revisa, aceita ou corrige. O agente só existe enquanto você está olhando para ele. Na quarta-feira (5 de março de 2026), o Cursor lançou Automations e mudou essa dinâmica. Agora os agentes podem rodar sem que ninguém esteja assistindo.

A ideia é simples de descrever e complicada de fazer direito: você configura um trigger (um PR mergeado, uma mensagem no Slack, um timer, um incidente no PagerDuty) e o Cursor dispara um agente que executa a tarefa configurada. Sem prompt manual, sem janela aberta, sem dev no loop até que seja necessário.

O que são Automations

Automations é o nome que o Cursor deu ao seu sistema de agentes event-driven. Em vez de responder a um prompt digitado no editor, esses agentes são acionados por eventos externos e executam instruções pré-configuradas.

Na prática, você define três coisas: o trigger que dispara a execução, as instruções que o agente deve seguir e os MCPs (Model Context Protocols) que ele pode acessar. Quando o evento acontece, o agente sobe em um sandbox na nuvem, executa a tarefa, verifica o próprio output e reporta o resultado.

O Cursor estima que já roda centenas de automations por hora. O número impressiona menos pelo volume e mais pelo que implica: tem muita gente confiando em agentes que rodam sem supervisão direta.

Triggers: o que dispara um agente

O sistema suporta seis tipos de trigger nativos:

  • Slack -- uma mensagem em um canal específico aciona o agente
  • Linear -- uma issue criada dispara a automação
  • GitHub -- um PR mergeado inicia a execução
  • PagerDuty -- um incidente reportado chama o agente
  • Cron -- agendamento por horário (tipo crontab)
  • Webhooks customizados -- qualquer sistema que dispare um POST para a URL configurada

Essa lista cobre os cenários mais comuns de um time de engenharia. O webhook genérico é o escape valve: se o trigger que você precisa não existe nativamente, basta apontar o evento para a URL do Cursor.

O que me pega é o Slack como trigger. Um dev do Rippling, Abhishek Singh, montou um assistente pessoal que agrega notas de reunião, TODOs e links de Loom a partir de mensagens no Slack. Um agente cron roda a cada duas horas, deduplica informações entre PRs do GitHub, issues do Jira e menções no Slack, e posta um dashboard limpo. Parece exagero até você perceber quanto tempo se perde caçando contexto espalhado por cinco ferramentas.

Na prática: o que dá para automatizar

O Cursor publicou templates para os casos de uso mais comuns. Alguns exemplos concretos:

Security review por push. A cada push na branch main, um agente audita o diff procurando vulnerabilidades. Ele ignora issues já discutidas em PRs anteriores e posta no Slack apenas os achados de alto risco.

Codeowners inteligente. O agente classifica o risco de cada PR com base no blast radius, complexidade e impacto em infraestrutura. PRs de baixo risco são aprovados automaticamente. Os demais recebem um reviewer humano atribuído. As decisões ficam registradas no Notion via MCP.

Incident response. Quando o PagerDuty detecta um incidente, o agente usa o MCP do Datadog para investigar logs, examina mudanças recentes no código, notifica os engenheiros de plantão no Slack com detalhes de monitoramento e propõe um fix via PR automático.

Cobertura de testes. Todo dia de manhã, um agente revisa o código mergeado no dia anterior, identifica áreas sem teste, escreve os testes seguindo as convenções do projeto e abre um PR depois de rodar a suite.

Triagem de bugs. Quando um bug report chega via Slack, o agente checa duplicatas, cria uma issue no Linear, investiga a causa raiz no codebase, tenta um fix e responde na thread com um resumo.

O padrão que emerge é claro: tarefas repetitivas que exigem contexto do codebase mas não exigem criatividade. É o tipo de trabalho que todo dev sabe que deveria fazer mas empurra para a próxima sprint.

Por dentro da execução: sandbox, MCPs e memória

Quando um trigger dispara, o Cursor sobe um sandbox isolado na nuvem. Esse sandbox tem acesso ao codebase, aos MCPs configurados e às credenciais necessárias. O agente executa as instruções, faz chamadas a APIs externas, roda comandos no terminal e conecta a serviços como Datadog, Linear e Notion.

Dois detalhes técnicos chamam atenção.

Primeiro, o sandbox tem controle granular de acesso à rede. Você define quais domínios o agente pode acessar enquanto roda. Isso limita o blast radius de uma automação mal configurada -- o agente não sai fazendo requests para qualquer endpoint.

Segundo, os agentes têm acesso a uma ferramenta de memória. Eles aprendem com execuções anteriores e melhoram com repetição. Josh Ma, engineering lead do Cursor, resumiu: "Essa ideia de pensar mais, gastar mais tokens para encontrar problemas mais difíceis, tem sido muito valiosa." Na prática, um agente de security review que roda há duas semanas tende a pegar mais coisas que um recém-configurado.

Onde isso se encaixa no mercado

O Cursor não está sozinho nessa corrida. GitHub Copilot tem Agent Mode. Claude Code lançou Agent Teams, onde múltiplos agentes se comunicam entre si via task lists compartilhadas. O Codex da OpenAI roda em sandbox isolado. Todo mundo quer ser o primeiro a resolver o problema de "IA que age sem ser pedida".

Mas o Cursor tem uma vantagem de distribuição que é difícil de ignorar. Segundo dados da Ramp, a empresa detém cerca de 25% do mercado entre clientes de IA generativa. A Bloomberg reportou em 2 de março de 2026 que a receita anualizada do Cursor dobrou em três meses, chegando a US$ 2 bilhões. Clientes enterprise representam 60% dessa receita. São números que compram tempo para iterar.

O conceito de Automations não é inédito. CI/CD faz isso há décadas com pipelines declarativos. A diferença é que o "step" agora não é um script determinístico -- é um agente LLM que interpreta instruções em linguagem natural e decide o que fazer. Isso é ao mesmo tempo o que torna Automations poderoso e o que torna arriscado.

O que muda no dia a dia do dev

Jonas Nelle, chefe de engenharia de agentes assíncronos do Cursor, usou uma metáfora que gruda: "Eles são chamados nos pontos certos dessa esteira rolante." A ideia é que o dev deixa de ser o operador que monitora cada agente e passa a ser o supervisor que intervém em pontos específicos.

Tem algo inquietante em agentes rodando às 3 da manhã sem ninguém assistindo. Um agente de security review que dá auto-approve em um PR de baixo risco está tomando uma decisão que antes era exclusivamente humana. Se o modelo de classificação de risco falhar, o PR vai para produção sem revisão. O controle granular de rede e as instruções explícitas ajudam, mas não eliminam o risco.

Por outro lado, a alternativa realista não é "um humano faz tudo com cuidado". É "ninguém faz porque não tem tempo". Aquele security review que deveria acontecer em todo PR? Na maioria dos times, só acontece nos PRs grandes. A cobertura de testes do código mergeado ontem? Vai ficar para o próximo quarter. Se o agente cobre a maior parte do trabalho com boa acurácia, o saldo provavelmente é positivo.

O ponto de inflexão real é quando o volume de automações cresce a ponto de nenhum humano conseguir revisar todas as decisões. Aí a pergunta muda de "o agente é bom o suficiente?" para "como eu audito o que os agentes fizeram?".

Conclusão

Automations é a versão do Cursor para uma tese que toda empresa de IA está testando: agentes que agem proativamente em vez de esperar um prompt. A execução é sólida: triggers nativos para as ferramentas que times de engenharia já usam, sandbox isolado, controle de acesso, memória entre execuções.

O risco real não está na tecnologia, está na confiança calibrada. Saber quais tarefas delegar para um agente autônomo e quais manter sob revisão humana é uma habilidade nova que a maioria dos times ainda não desenvolveu. Automations está disponível em cursor.com/automations, com templates prontos no marketplace.

Referências pesquisadas nesta publicação