Antigravity /teamwork: Google libera seu sistema multiagente

O Google Research publicou em 13 de novembro de 2026 um balanço do /teamwork, o sistema multiagente do Antigravity, e anunciou sua liberação para usuários externos. O texto, assinado por Vahab Mirrokni, Google Fellow e vice-presidente da área, reúne resultados em matemática, química, sistemas distribuídos e reescrita de código, e credita colaboradores acadêmicos de instituições como CUHK, Columbia, UCSD, MIT e CMU.

A proposta do Antigravity /teamwork é menos sobre um modelo mais capaz e mais sobre arquitetura: em vez de um agente longo tentando resolver um problema inteiro, dezenas de agentes especializados trabalham em paralelo, com verificadores automáticos descartando as tentativas erradas e agentes auditores revisando o resultado sem ver o raciocínio de quem produziu. É esse arranjo — e não um salto de capacidade bruta — que o Google aponta como responsável pelos números apresentados.

Antes dos resultados, um aviso necessário: tudo o que segue vem do relato do próprio Google, com métricas internas. Parte dos trabalhos tem verificação independente do mecanismo — provas conferidas em Lean 4, suítes de teste não modificadas — e parte não tem auditoria externa.

O que o Antigravity /teamwork acrescenta

O Antigravity é a plataforma de desenvolvimento com agentes do Google, lançada em 18 de novembro de 2025 junto com o Gemini 3, inicialmente como um ambiente derivado do Visual Studio Code. Em maio de 2026 ganhou uma versão 2.0 com aplicativo próprio para gerenciar agentes, interface de linha de comando e SDK. Entre seus recursos estão um gerenciador de agentes assíncronos e níveis ajustáveis de autonomia, do modo em que comandos de terminal rodam sem aprovação até o modo restrito com sandbox.

O /teamwork roda dentro desse ambiente e é construído sobre a família Gemini 4 — o post menciona os modelos Argon, Carbon e Hydrogen. O Gemini 4 Argon, lançado em 13 de outubro de 2026, é o modelo de ponta da linha; segundo o Google, o uso dele no Antigravity elevou em mais de 35% o volume de submissões de código feitas por agentes e reduziu em quase um terço as reversões.

Duas funções derivadas também estão disponíveis: o /boost, um laço sequencial de resolver e verificar, e o Deep Review, voltado à revisão de manuscritos técnicos.

Como o sistema é construído

Os mecanismos descritos no post são a parte mais aproveitável para quem constrói sistemas com agentes, independentemente de usar ou não a plataforma do Google.

• Exploração paralela com falsificadores. Várias soluções candidatas são geradas ao mesmo tempo e verificadores automáticos decidem quais sobrevivem. Os exemplos citados são o verificador de provas Lean 4, suítes de teste não modificadas, simuladores de execução, busca na web e contadores de hardware.
• Particionamento de contexto. Cada agente recebe só os arquivos e ferramentas do seu passo, o que limita a diluição de atenção em tarefas que duram dias.
• Coordenadores e repasses. Em vez de estender indefinidamente o contexto, coordenadores repassam a tarefa a agentes sucessores novos. Agentes críticos e auditores conferem o resultado a partir de contexto limpo, sem acesso ao raciocínio do produtor original.
• Padrões declarativos. Os fluxos são escritos em linguagem natural e cada pedido é roteado para o padrão mais adequado — prova longa, revisão de documento, codificação distribuída.
• Auto-aperfeiçoamento. Especificações são construídas a partir de transcrições de execuções anteriores. Um exemplo contraintuitivo citado no post: uma campanha de otimização descobriu que código fortemente acoplado rende mais com estágios sequenciais do que com divisão em paralelo, e isso foi incorporado ao /boost.

O post também nomeia componentes internos: Stellar Colosseum (o arcabouço multiagente), LEAP (arcabouço de formalização desenvolvido com o Google Cloud AI) e DuoDiscover (padrão voltado a otimização de desempenho).

Os resultados apresentados

Em matemática e teoria da computação, o caso central é a conjectura de Courtade–Kumar, proposta em 2013, que o Google afirma ter sido provada em generalidade plena. Segundo o relato, o modelo encontrou contraexemplos para uma versão generalizada, o problema foi reduzido a uma otimização de 14 variáveis, o Gemini 4 Argon desenvolveu a maior parte dos limites analíticos e estendeu a prova para funções não balanceadas. A prova completa foi formalizada em Lean 4 com cerca de 50 milhões de linhas. O post lista ainda resultados em complexidade de consulta quântica, multiplicação de matrizes booleanas, esparsificação de cortes em grafos e um novo limite para a conjectura do deque de Tarjan, também verificado em Lean 4.

Pelo LEAP, o sistema produziu formalizações conferidas por máquina das conjecturas de Weil — cerca de 1,8 milhão de linhas de Lean ao longo de 28.800 invocações de subagentes — e de resultados ligados ao décimo problema de Hilbert (mais de 919 mil linhas), além da conjectura de Bochner–Riesz em três dimensões, caso em que, segundo o Google, foi encontrada e corrigida uma lacuna em uma prova informal.

Há também um experimento de melhoria autônoma: partindo de uma implementação básica de AlphaZero, campanhas automáticas treinaram um motor de Go 9×9, com 2.300x de aceleração no autojogo e ganho de cerca de 2.600 pontos de Elo em menos de oito dias. Humanos definiram alocação de chips e configuração de avaliação, e campeões só eram promovidos após testes estatísticos sobre registros travados.

O que observar com reserva

O post não tem seção de limitações, mas registra ressalvas que importam. O resultado do Go vem de uma única partida jogada para a publicação. A pesquisa sobre o Deep Review está em andamento, tem 70 respondentes e é autodeclarada. Os resultados dependem de especialistas humanos para formular os problemas, definir restrições e verificar as saídas — os autores afirmam ter verificado, simplificado e editado as provas geradas antes de publicar. E, mesmo com formalização em Lean, continua sendo papel humano confirmar que o enunciado formal corresponde ao problema original, o que é o ponto mais delicado de toda a cadeia: um teorema provado em Lean é inquestionável para o enunciado que foi escrito, não para o que se pretendia enunciar.

Também não há auditoria externa da maioria dos números de desempenho, e várias comparações são contra linhas de base internas do Google. Nada disso invalida os resultados, mas distingue o que é verificável de fora — provas em Lean, conformidade bit a bit do decodificador AV1, suítes de teste não modificadas — do que é relato corporativo.

Por que isso importa para segurança

Dois pontos merecem atenção de quem avalia essas ferramentas em ambiente corporativo.

O primeiro é o histórico de incidentes da própria plataforma. Pesquisadores de segurança já relataram no Antigravity um repositório malicioso capaz de instalar porta dos fundos persistente e ataques de injeção indireta de prompt com exfiltração de dados e execução de comandos. Houve ainda relato público de apagamento de disco em modo de alta autonomia. O Google respondeu com um modo restrito e com sandbox para comandos de terminal em macOS e Linux. Um sistema que dispara dezenas de agentes com acesso a terminal, navegador e repositórios amplia a superfície desses problemas, não a reduz.

O segundo é que o Google reporta avanço justamente nesse eixo: o Gemini 4 Argon lidera, segundo a empresa, o teste de injeção indireta de prompt da Gray Swan, com taxa de sucesso de ataque de 0,7% em 15 tentativas adaptativas. É um número bom, mas é um número de benchmark, não uma garantia de ambiente real — e 0,7% diferente de zero, multiplicado por dezenas de agentes e milhares de execuções, continua sendo uma quantidade de incidentes esperados.

Recomendações para quem for avaliar

• Tratar agentes com acesso a terminal e repositórios como identidades privilegiadas: credenciais de escopo mínimo, segredos fora do contexto do agente e registro dos comandos executados.
• Manter modo restrito e sandbox ativos em código de terceiros e nunca apontar agentes autônomos para repositórios não auditados.
• Exigir verificadores independentes do gerador — suíte de testes não modificada, conferência formal, revisão humana — porque é a camada de verificação, e não o modelo, que sustenta os resultados do /teamwork.
• Em pesquisa, tratar saída formalizada como verificada apenas para o enunciado formal, conferindo à mão a correspondência com o problema real.

Conclusão

O balanço do /teamwork é o relato mais detalhado até agora de uma aposta de engenharia específica: trocar o agente único e longo por muitos agentes curtos, paralelos e descartáveis, com verificação automática separando o que presta. Os resultados mais sólidos são os que não dependem de confiança no relato — provas conferidas em Lean, código Rust com conformidade bit a bit, testes não modificados. O acesso externo está aberto, com inscrições para 10 mil pesquisadores acadêmicos receberem seis meses de uso gratuito no nível mais alto, e o Google anuncia padrões adicionais de prova formal e de reescrita de código. O que acompanhar: validação independente dos resultados matemáticos, publicação em veículos revisados por pares e como a plataforma lida com segurança quando o número de agentes autônomos em execução simultânea cresce.

Fontes e referências

• Google Research — “Advancing science & engineering with Antigravity’s /teamwork”, 13 de novembro de 2026: research.google
• Google — “Gemini 4 Argon: Built to solve your hardest problems”, 13 de outubro de 2026: blog.google
• Wikipedia — “Google Antigravity” (histórico da plataforma, recursos e incidentes de segurança relatados): en.wikipedia.org
• Plugged Ninja — “Equipes paralelas de agentes rendem mais que o best-of-N”: plugged.ninja