Cursor Projects: o que é e como o coordenador delega tarefas
MarkdownCursor Projects, tal como anunciado pela Cursor: como o coordenador delega tarefas, onde é armazenado o contexto partilhado, como funcionam as Subscriptions e para que serve esta versão beta.
Ler o artigo completo
A 10 de setembro de 2026, a Cursor anunciou a versão beta de Projects — uma funcionalidade para tarefas de grande dimensão com contexto partilhado que persiste durante meses.
Um coordenador lidera o trabalho em Projects. Não escreve código por si próprio: planeia o trabalho e delega partes dele noutros agentes. Um projeto tem um conjunto partilhado de ficheiros que contém o material acumulado ao longo do percurso. Também pode pedir ao coordenador que esteja atento a eventos e responda sem um novo prompt. Segue-se uma análise das capacidades e limitações descritas no anúncio da Cursor.
Documentação de referência da Ailoot: ailoot.ai/docs/.
O que é o Cursor Projects, em linguagem simples?
Ideia principal
Cursor Projects é uma funcionalidade para trabalhar numa tarefa de grande dimensão: uma nova funcionalidade, uma migração ou uma aplicação inteira. Um coordenador planeia o trabalho e distribui-o por agentes de implementação. O coordenador não escreve código por si próprio. De acordo com o anúncio de 10 de setembro de 2026, Projects está disponível em versão beta no painel de navegação esquerdo da Cursor; o acesso está a ser disponibilizado gradualmente a todos os utilizadores.
O anúncio oficial da Cursor descreve o objetivo da funcionalidade da seguinte forma:
Projects permite-lhe assumir tarefas de maior dimensão, como uma funcionalidade, uma migração ou uma aplicação completa. Mantém o contexto ao longo de meses de trabalho, delega tarefas em milhares de subagentes e executa trabalho recorrente sem que lhe seja pedido.
Por outras palavras: Projects permite-lhe assumir tarefas de grande dimensão, como uma nova funcionalidade, uma migração ou uma aplicação inteira. Mantém o contexto ao longo de meses de trabalho, delega tarefas em milhares de subagentes e executa trabalho recorrente sem um pedido do utilizador.
Em que difere o coordenador de um agente normal da Cursor?
Ideia principal
O coordenador de um projeto planeia o trabalho, distribui-o pelos agentes de implementação e traz-lhe o trabalho concluído para revisão. Não escreve código por si próprio. Os coordenadores criam e gerem agentes em seu nome, executando tantos em paralelo quantos o trabalho exigir.
Eis como a Cursor descreve a divisão de funções:
O agente coordenador de um projeto não escreve código por si próprio; planeia o trabalho, delega-o em agentes que o implementam e traz-lhe o trabalho concluído para verificar. Os coordenadores criam e gerem agentes em seu nome, executando tantos em paralelo quantos o trabalho exigir.
Por outras palavras: o coordenador de um projeto não escreve código por si próprio. Planeia o trabalho, delega-o em agentes de implementação e traz-lhe o trabalho concluído para revisão. Os coordenadores criam e gerem agentes em seu nome, executando tantos em paralelo quantos o trabalho exigir.
Pode comparar a divisão de funções à de um encarregado e uma equipa: o encarregado planeia o trabalho e atribui tarefas a quem as vai executar. Em Projects, quem as executa são agentes de IA geridos pelo coordenador. O coordenador continua a trazer-lhe o trabalho concluído para revisão. Este modelo é semelhante à estrutura de «orquestrador e trabalhadores» em sistemas multiagente — consulte o guia sobre a distribuição de tarefas entre agentes.
O projeto é executado na nuvem, mas o coordenador pode iniciar um agente local para testar algo na sua máquina:
Um Project é executado no seu próprio computador na nuvem, por isso fechar o portátil não o interrompe. Quando algo precisa de ser testado na sua máquina, o coordenador inicia um agente local para o executar aí.
Por outras palavras: o projeto é executado no seu próprio computador na nuvem, por isso fechar o portátil não o interrompe. Quando algo precisa de ser testado no seu computador, o coordenador inicia aí um agente local para efetuar esse teste.
Como funciona a memória partilhada de um projeto?
Ideia principal
Cada projeto tem um conjunto de ficheiros que é sincronizado entre todas as máquinas na nuvem e locais utilizadas pelos seus agentes. Os agentes colocam nesses ficheiros as suas descobertas, artefactos e aquilo que aprendem sobre o código e a sua forma preferida de trabalhar. Se um agente descobrir como testar um serviço, os agentes futuros podem usar essas instruções.
A Cursor chama a este mecanismo Shared context:
Cada Project mantém um conjunto de ficheiros que é sincronizado entre todas as máquinas na nuvem e locais utilizadas pelos seus agentes. Os agentes acrescentam investigação e artefactos, bem como aquilo que aprendem sobre a base de código e a forma como prefere que o trabalho seja feito. Por exemplo, se um agente descobrir como testar um serviço, todos os agentes futuros podem usar essas instruções. O contexto partilhado cresce com o Project, tornando o coordenador mais eficaz ao longo do tempo.
Por outras palavras: cada projeto mantém um conjunto de ficheiros sincronizados entre todas as máquinas na nuvem e locais dos seus agentes. Os agentes acrescentam resultados de investigação, artefactos e informações sobre o código e as suas preferências de trabalho. Se um agente descobrir como testar um serviço, todos os agentes futuros podem usar as respetivas instruções. O contexto partilhado cresce com o projeto, o que, segundo a Cursor, torna o coordenador mais eficaz ao longo do tempo.
O coordenador pode recorrer ao material acumulado. Isto aproxima-se da ideia de Second Brain, mas aqui refere-se à memória partilhada de um projeto na Cursor, e não à sua memória pessoal. Os agentes acrescentam-lhe conteúdo à medida que trabalham.
Se estiver interessado em criar uma memória pessoal semelhante no Claude Code, existe um guia separado sobre o Second Brain no Claude Code. Aborda a ideia relacionada de acumular material para trabalhos futuros.
A acumulação de contexto entre tarefas faz parte da engenharia de contexto: gerir o que entra na memória da IA e onde fica guardado.
O que são as Subscriptions no Cursor Projects?
Ideia principal
As Subscriptions permitem-lhe pedir ao coordenador que acompanhe um canal do Slack, seja executado segundo um horário ou siga todos os seus pedidos de integração de alterações. O coordenador responde então a sinais por iniciativa própria, sem um novo prompt. Um exemplo do anúncio: ligue o Slack e indique um canal de relatórios de erros; o coordenador começa a delegar uma tarefa sempre que chega um novo relatório de erro.
A memória partilhada guarda o material do projeto, enquanto as Subscriptions especificam quando o coordenador deve agir. Depois de configurado desta forma, não precisa de esperar que escreva uma nova tarefa na conversa:
Diga ao agente coordenador para acompanhar um canal do Slack, ser executado segundo um horário ou seguir todos os seus PRs. Assim, pode agir com base nos sinais que deteta, sem esperar pelo seu prompt.
Por outras palavras: peça ao coordenador que acompanhe um canal do Slack, seja executado segundo um horário ou siga todos os seus pedidos de integração de alterações, e ele poderá agir com base nos sinais que deteta sem esperar pelo seu prompt.
Um exemplo do mesmo anúncio:
Ligue o Slack e indique um canal de relatórios de erros; o coordenador começa a delegar sempre que chega um erro.
Por outras palavras: ligue o Slack e indique um canal para relatórios de erros; o coordenador começa a delegar uma tarefa sempre que chega um novo relatório.
O anúncio oficial não explica que outros eventos, para além do Slack, dos horários e dos PRs, podem desencadear trabalho, nem indica um preço para a funcionalidade. Para a configurar, abra Projects no painel de navegação esquerdo da Cursor. Não são fornecidos passos de configuração detalhados: siga a interface da versão que tem disponível.
Quando considerar o Cursor Projects
Ideia principal
A Cursor disponibiliza Projects para tarefas de grande dimensão: uma nova funcionalidade, uma migração ou uma aplicação inteira. A minha recomendação editorial: para uma alteração pontual ou uma tarefa pequena, um agente de conversa normal é provavelmente suficiente. Considere Projects para tarefas de grande dimensão que se prolongam no tempo.
O anúncio descreve o objetivo da funcionalidade como «tarefas de maior dimensão, como uma funcionalidade, uma migração ou uma aplicação completa» — tarefas de grande dimensão, como uma nova funcionalidade, uma migração ou uma aplicação inteira. Este caso de utilização serve de base à minha recomendação. Se uma tarefa couber numa única conversa com um agente, um agente de conversa normal é provavelmente suficiente. Se regressa regularmente à mesma tarefa de grande dimensão e ao mesmo código, o contexto partilhado de Projects poderá ajudar: os agentes futuros podem utilizar as instruções e descobertas já acumuladas.
Se está a escolher entre a Cursor e outras ferramentas, existe uma comparação separada — Cursor vs Claude Code. Analisa as diferenças no trabalho quotidiano, sem Projects.
O que fazer a seguir
Cursor Projects estava em versão beta na altura do seu anúncio, a 10 de setembro de 2026. O anúncio oficial não indica um preço, por isso consulte os preços e limites no produto quando o ativar, em vez de se basear neste artigo.
Continue a explorar o Ailoot em ailoot.ai.
Mais detalhes
Perguntas frequentes
Quando basta um chat de agente normal em vez de Projects?
Para uma alteração pontual que caiba numa conversa, um chat normal é um ponto de partida razoável. Projects destina-se a trabalho maior que continua ao longo do tempo e beneficia de descobertas e instruções partilhadas.
O que verifico antes de ativar uma Subscription?
Decida que sinal o coordenador deve acompanhar: um canal Slack de erros, um agendamento ou pedidos pull, por exemplo. Verifique a interface, os preços e limites da sua conta; o anúncio não fornece preço nem guia completo de configuração.