AIREITERCinquenta milhões de linhas de Lean 4 para uma única prova, 800 mil linhas de Rust seguro em duas semanas e kernels de TPU 4,09 vezes mais rápidos: a atualização de pesquisa do Google publicada em 13 de novembro dá uma boa ideia do que o Antigravity Teamwork consegue fazer. Mas há um detalhe importante: na prática, ele só costuma compensar em projetos organizados por marcos que levam horas ou dias, já que uma única execução pode consumir uma fatia considerável da cota semanal.
O que é, de fato, o Antigravity Teamwork
O Antigravity Teamwork é o fluxo de orquestração multiagente do Google para trabalhos grandes e que exigem muita verificação dentro do Antigravity. O comando /teamwork inicia uma equipe coordenada — Sentinel, Project Orchestrator, Explorers, Workers, Critic, Challenger, Auditor e Success Auditor — que divide o trabalho em marcos, atua em um diretório de projeto dedicado e só libera cada etapa depois de uma verificação independente.
O processo acontece em duas fases. A primeira é uma entrevista de escopo, na qual o agente principal registra objetivos, requisitos, métodos de verificação, critérios de aceitação e o diretório do projeto (por padrão, ~/teamwork_projects/{PROJECT_NAME}). Na segunda, a execução é autônoma e baseada em artefatos estruturados — solicitação, plano do projeto e registros de progresso —, com propriedade exclusiva dos arquivos para cada Worker e validações do Critic, Challenger, Auditor e Success Auditor antes da entrega (documentação do Teamwork).
Os modos de integridade, definidos durante a entrevista, determinam o nível de rigor:
development(padrão): iteração rápida; reutilização de código e frameworks são permitidas, mas resultados inventados e implementações de fachada são rejeitados.demo: apresentação reproduzível; é proibido copiar a lógica principal de projetos open source, terceirizar o trabalho central ou consultar o código dos testes para obter as respostas.benchmark: rigor máximo; a implementação deve ser feita do zero, usando a biblioteca padrão da linguagem, com avaliação independente baseada em resultados reais.
Os caminhos de execução ajustam automaticamente a composição da equipe:
- Programação distribuída geral (padrão): engenharia e refatoração em vários arquivos.
- Programação iterativa: uma correção pontual quando o pedido diz para “manter pequeno”.
- Document Review: análise crítica de artigos e documentos de design sob vários ângulos.
- Math / Proof e Math / Proof Large Team: raciocínio formal e campanhas extensas para provar conjecturas.
Em planos pagos, no aplicativo e na CLI do Antigravity, o horizonte típico vai de horas a dias (documentação do Teamwork).
Teamwork, Swarm, Boost ou subagentes: qual escolher?
O Antigravity Teamwork só é a melhor opção quando a tarefa precisa de marcos, etapas formais de auditoria e um diretório dedicado. Para a maior parte do trabalho diário, as alternativas mais leves bastam — e escolher a ferramenta errada significa gastar cota sem necessidade.
| Ferramenta | Melhor uso | Como começa | Workspace | Verificação | Duração típica | Plano |
|---|---|---|---|---|---|---|
| Subagentes | Tarefas auxiliares focadas: pesquisa no repositório, verificações no navegador e execução de testes | Automático ou @subagent | Workspace atual | O agente principal confere a resposta | Segundos a minutos | Todos os planos |
Boost (/boost) | Problemas difíceis, mas estreitos: condições de corrida, bugs complicados e algoritmos | /boost <task>, começa imediatamente | Workspace atual, com contextos isolados | Workers desafiam e verificam novamente; o orquestrador faz verificações pontuais | Segundos a horas | Planos pagos |
Swarm (/swarm) | Trabalho amplo que pode ser dividido com clareza: arquivos, pacotes e suítes de testes | /swarm <task>, começa imediatamente | Workspace atual ou cópias por worker | Um @verifier dedicado revisa os diffs e executa os testes | Minutos a horas | Google AI Pro e Ultra |
Teamwork (/teamwork) | Projetos com vários marcos: migrações, simulações e provas formais | /teamwork <goal> + entrevista de escopo | ~/teamwork_projects/{PROJECT_NAME} dedicado | Etapas de validação do Critic, Challenger, Auditor e Success Auditor | Horas a dias | Planos pagos |
Use o Teamwork para migrar uma API REST para Fastify em dezenas de arquivos, com cobertura completa de testes; criar um simulador com precisão de ciclo validado por temporizadores de hardware; ou desenvolver uma prova formal verificada pelo Lean 4. O Swarm é mais adequado para adicionar validação a três handlers de API independentes, com um worker por arquivo e um verificador executando npm test. Já o Boost faz mais sentido para uma única condição de corrida ou uma refatoração interdependente em que o ciclo sequencial de desafio, correção e verificação supera workers paralelos. Para pesquisas de apoio enquanto a conversa principal continua, use subagentes.
A confusão é compreensível. Como resumiu um usuário do Antigravity:
“agy has way too many modes now and honestly it's getting confusing. right now we have ... /teamwork (long milestone projects with audit gates) ... and now dynamic workflows... to be fair, we really don't need all of them. fewer modes = less confusion...”
— @Heamanth_alturi (X)
A regra prática é simples: se a tarefa tem uma única definição de pronto e termina em uma sessão, o Teamwork é exagero. Se ela precisa de um artefato de planejamento, um registro de progresso e da aprovação de alguém que não seja o autor em cada marco, aí o Teamwork se encaixa.
O que a atualização de pesquisa de novembro realmente demonstrou
A atualização do Google Research de 13 de novembro é um relatório de resultados, não um anúncio de lançamento. O Teamwork já existia antes como /teamwork-preview para planos pagos; o texto documenta o que equipes organizadas por marcos conseguiram realizar com Gemini 4 Argon, Carbon e Hydrogen. Os humanos continuaram definindo os problemas, as restrições e os métodos de avaliação, enquanto críticos novos revisavam o trabalho em contextos limpos.
| Área | Projeto de exemplo | Escala dos agentes | Resultado divulgado |
|---|---|---|---|
| Matemática | Prova da conjectura de Courtade–Kumar (Google, CUHK, USC, CMU) | Padrão de prova longa, formalização em Lean 4 | Prova completa com cerca de 50 milhões de linhas de código Lean |
| Química | Estrutura molecular a partir de dados de RMN | 30 agentes especializados + simulador de física | 95% de correspondência exata em primeiro lugar e 100% entre as três primeiras |
| Sistemas | Reescrita de Zircon de C++ para Rust | Campanha de duas semanas com Argon | Cerca de 800 mil linhas de Rust seguro, inicializadas em arm64 |
| Hardware de ML | Otimização de kernels de TPU (DuoDiscover) | Avaliadores proxy (23 s contra 7–32 min) | Aceleração média de 4,09 vezes em 17 kernels do JAXBench |
O Google também abriu inscrições para que 10 mil pesquisadores acadêmicos recebam acesso de alto nível por seis meses. Alguns fluxos descritos no artigo ainda estão sendo liberados para usuários externos. Portanto, encare a tabela como evidência de capacidade, não como promessa de que todo projeto repetirá esses ganhos.
A conta de cota que as páginas oficiais não mostram
A página de preços do Antigravity lista o plano Individual por US$ 0/mês, com conclusões de aba ilimitadas e limites semanais básicos, além dos planos Pro e Ultra, que oferecem limites maiores e uma reserva flexível de créditos de IA; o número exato de solicitações não é divulgado. As cotas do Pro e do Ultra são renovadas a cada cinco horas até atingir o teto semanal, e o excedente pode usar créditos comprados, conforme a configuração Never ou Always (documentação dos planos). Teamwork e Boost exigem planos pagos; o Swarm requer Pro ou Ultra (documentação do Swarm). O próprio texto do Google sobre o sistema operacional alertou que algumas tarefas complexas de prévia poderiam consumir uma cota semanal inteira (artigo sobre o Antigravity OS).
Relatos de usuários — anedóticos e sem representar uma amostra estatística — vão de um consumo administrável a um estrago completo:
“holy crap that sucked all my quota in about only 5 minutes (3.5 Flash (high))”
— u/Several_Bag_3665 (Reddit)
“very usable on ultra sub actually, had a teamwork preview with gemini flash medium going for 50 minutes straight and it took about 20% of my 5-hour quota and did huge refactorings properly”
— u/ningkaiyang (Reddit)
Duas características ajudam a explicar essa diferença. Na documentação do /swarm, o Antigravity informa que cada worker é um agente separado, que workers em espera não consomem tokens e que workers que esgotam a cota entram em pausa, em vez de tentar novamente automaticamente, até receberem uma nova mensagem no quadro, uma troca de modelo ou uma mensagem direta (documentação do Swarm). A documentação do Teamwork não publica a mesma informação sobre retomada; por isso, trate esse comportamento como algo compartilhado entre os fluxos multiagente, mas confirme no seu plano. O Teamwork também produz muitos artefatos intermediários — registros de solicitação, plano e progresso, além de anotações de trabalho e logs de verificação por agente (documentação do Teamwork) —, e isso representa estado esperado, não necessariamente avanço real.
Como fazer o primeiro Teamwork sem queimar a cota da semana
Iniciar o Teamwork exige um comando, mas é a entrevista de escopo que define o custo. No aplicativo, abra uma conversa de projeto e digite /teamwork Migrate our REST API service from Express to Fastify, including full test coverage, TypeScript typing, and benchmark validation. Na CLI, execute /teamwork Design and implement a cycle-accurate memory controller with lockstep simulation tests a partir do diretório do projeto. Acompanhe o processo pelo painel de subagentes ou pela barra de status da CLI, use Alt+J para ir às aprovações e inspecione os artefatos de plano e progresso em tempo real (documentação do Teamwork).
Trate a primeira fase como seu principal controle de custos. Descreva o que precisa ser feito, não como fazer: objetivo, público (demo, produção ou benchmark), restrições rígidas e uma verificação objetiva para cada requisito, como uma suíte de testes ou um script de métricas. Escolha development para iterar e deixe demo ou benchmark para situações em que uma prova apresentável ou uma implementação feita do zero seja realmente necessária, pois uma verificação mais rigorosa implica mais trabalho dos agentes. Antes de aprovar, confirme qual é o diretório dedicado do projeto.
Durante a execução, mantenha a coordenação centralizada. Encaminhe mudanças de escopo pelo coordenador, integre as alterações dos workers antes de removê-los e avalie o progresso pelos marcos e pelas evidências dos testes, não pela quantidade de arquivos. Em Settings, configure o excedente de créditos de IA como Never na primeira execução, para que o esgotamento da cota básica interrompa o trabalho em vez de gastar créditos silenciosamente (documentação dos planos). Quando a documentação do plano permitir, combine um planejador mais potente com uma implementação mais barata: o Ultra oferece Orchestrator (Carbon) e Orchestrator (Argon), que planejam com Gemini 4 Carbon ou Argon enquanto o Gemini 4 Hydrogen implementa (página de preços) — uma troca que também aparece nas comparações entre Carbon e Argon.
Perguntas frequentes
Qual é a diferença entre /teamwork e /teamwork-preview?
/teamwork-preview era o nome usado na fase anterior de prévia de pesquisa. A documentação atual do Teamwork usa /teamwork nos planos pagos; o Google não publicou uma declaração separada sobre disponibilidade geral.
É possível pausar ou recuperar o Teamwork depois que a cota acaba?
O comportamento documentado do /swarm é colocar em pausa os workers que esgotaram a cota até que recebam uma nova mensagem no quadro, uma troca de modelo ou uma mensagem direta (documentação do Swarm); a documentação do Teamwork não confirma o mesmo caminho de retomada. Antes de reiniciar, confira o plano e os artefatos de progresso em ~/teamwork_projects/{PROJECT_NAME}, pois os marcos parciais permanecem salvos como arquivos.
Quais artefatos o Teamwork gera?
Artefatos de solicitação, plano do projeto e progresso, além de anotações de trabalho por agente, scripts auxiliares e logs de verificação (documentação do Teamwork). É normal haver uma grande quantidade de Markdown; avalie o avanço pelos marcos e pelas evidências dos testes, não pelo número de arquivos.
O Teamwork é seguro para repositórios de produção?
O Teamwork isola o trabalho em um diretório dedicado, com propriedade exclusiva dos arquivos e etapas de auditoria, o que reduz o risco de conflitos (documentação do Teamwork). Mesmo assim, o uso em produção exige revisão humana dos critérios de aceitação, das evidências de teste e da aprovação final do Success Auditor antes do merge.
Checklist de 30 segundos antes de digitar /teamwork
Digite /teamwork somente quando as cinco condições forem verdadeiras: o trabalho envolve vários marcos, cada marco tem uma verificação objetiva, um diretório dedicado ajuda, etapas de auditoria independentes são importantes e uma execução que consome muita cota sai mais barata do que semanas de trabalho manual. Caso contrário, use Swarm para tarefas amplas e paralelizáveis, Boost para bugs difíceis e específicos ou subagentes para tarefas auxiliares — e deixe o Teamwork para o projeto que realmente precisa de uma equipe.