Em agosto de 2026, o Google apresentou atualizações no framework Teamwork, dentro da plataforma Antigravity, integrando o Gemini 3.7 Flash a tarefas complexas de pesquisa e engenharia. O anúncio chama atenção porque desloca o foco do agente individual para uma equipe de agentes capazes de colaborar, criticar e revisar soluções. O bug, para quem acompanha a inteligência artificial, está em entender o que essa divisão realmente faz e onde termina a demonstração controlada: este artigo descomplica a arquitetura, os mecanismos de verificação e os resultados divulgados, sem transformar o experimento em uma promessa de autonomia geral. A apresentação oficial do Google ajuda a acompanhar a proposta por trás dessa nova forma de trabalho digital.

De agente isolado a equipe coordenada

A partir dessa demonstração, o ponto central do Teamwork é a orquestração, isto é, a coordenação de vários agentes autônomos em torno de uma mesma tarefa. Cada agente funciona como uma unidade de software capaz de participar do processo, enquanto o conjunto distribui etapas, confronta respostas e retorna a uma solução quando encontra problemas. O framework foi descrito como uma estrutura em que agentes colaboram, criticam e iteram, termo que significa repetir o ciclo de trabalho para aperfeiçoar o resultado. A metáfora mais próxima não é a de uma máquina que recebe uma pergunta e entrega uma resposta isolada, mas a de uma sala de pesquisa em que diferentes participantes examinam o mesmo problema por ângulos distintos. Essa mudança de unidade prepara o terreno para entender por que a crítica foi incorporada ao próprio fluxo.

Essa divisão de tarefas também delimita o alcance do anúncio. O material divulgado não apresenta um agente com liberdade irrestrita para decidir qualquer coisa, e sim uma arquitetura com padrões de trabalho escolhidos automaticamente pelo Gemini. A diferença parece pequena, mas altera a leitura prática da tecnologia: a plataforma organiza a colaboração de acordo com o tipo de problema, em vez de tratar matemática, programação e documentação como variações da mesma conversa. Quando um sistema escolhe uma forma de execução, propõe uma solução e abre espaço para contestação, sua capacidade passa a depender tanto do processo quanto do modelo que gera o texto ou o código. É esse processo, com regras e papéis definidos, que conduz à próxima camada do Teamwork.

Cinco padrões para problemas diferentes

Para dar forma a essa coordenação, o Teamwork utiliza cinco padrões nomeados pelo Google: Iterative Coding, Distributed Coding, Long Proof, Self-Verification e Document Review. Os nomes descrevem molduras diferentes para organizar o trabalho, indo da repetição de etapas de código à distribuição de uma tarefa, passando por uma prova longa, pela autoverificação e pela revisão de documentos. Em todos eles, a lógica anunciada permanece parecida: agentes apresentam propostas, examinam o que foi produzido e refinam a resposta. A escolha automática feita pelo Gemini é uma tentativa de combinar o modo de colaboração com a natureza do problema, como um editor que decide se um texto precisa de novas versões, de leitores críticos ou de uma conferência documental antes de ser publicado. Essa variedade importa porque uma solução de engenharia não é avaliada da mesma maneira que uma demonstração matemática.

A escolha automática, portanto, funciona como uma camada de decisão sobre o próprio processo de resolução. No padrão de codificação iterativa, a palavra iterativa aponta para ciclos sucessivos de melhoria; em Distributed Coding, o termo distribuído indica que a tarefa é organizada entre participantes; em Long Proof, o foco está na construção de uma prova extensa. Já Self-Verification e Document Review nomeiam, respectivamente, a checagem do próprio trabalho e a análise de documentos. Essas descrições não transformam cada padrão em uma receita universal, mas ajudam a traduzir o tecniquês: o Teamwork tenta escolher a forma de colaboração antes de pedir que os agentes produzam o resultado. A pergunta seguinte é inevitável: quem verifica se a equipe está apenas concordando consigo mesma?

A crítica entra antes da resposta final

A colaboração ganha uma camada de oposição por meio dos chamados falsificadores, agentes concentrados em encontrar falhas nas soluções apresentadas. Em vez de participar apenas como mais uma voz que confirma a resposta dominante, esse grupo procura testar se há um erro capaz de derrubar a proposta. O framework também mantém um registro de armadilhas, chamado pitfall registry, para guardar problemas já identificados e evitar que os mesmos erros reapareçam em novas tentativas. A imagem lembra menos uma linha de montagem e mais um laboratório em que cada hipótese precisa sobreviver a experiências adversas. Em termos práticos, o valor do sistema não está apenas na quantidade de respostas geradas, mas na capacidade de tornar visíveis os pontos em que elas podem falhar.

Esse mecanismo se aproxima de uma estrutura de torneio, segundo a análise independente dos resultados divulgados pelo Google: estratégias geradas em paralelo são submetidas a agentes focados em encontrar falhas, e as alternativas mais consistentes avançam. O padrão Long Proof alcançou 71% de sucesso no TCSBench, um benchmark, ou seja, um conjunto de testes usado para medir o desempenho em uma tarefa específica. A mesma análise confirmou a publicação de artigos e patches produzidos pelo sistema, além de provas validadas, como uma demonstração de otimização convexa esparsa publicada no JMLR em 2021. Esses dados não provam que qualquer resultado criado por agentes esteja correto, mas mostram que a verificação foi colocada no centro da experiência, e não deixada como uma etapa decorativa depois da resposta.

Da matemática ao processador

A prova mais ambiciosa apresentada pelo Google aparece na matemática teórica. Com o Gemini 3.7 Flash integrado ao Teamwork, a empresa relata avanços em sete problemas em aberto, incluindo a Conjectura de Ciclos de Knuth. Um problema em aberto é uma questão que permanece sem solução reconhecida, portanto a afirmação descreve uma classe de desafios muito distante de uma tarefa rotineira de programação. A estrutura de agentes permite que propostas sejam confrontadas e retrabalhadas, aproximando o processo de uma comunidade de pesquisadores que registra tentativas, objeções e correções. O resultado é apresentado como uma demonstração do método de colaboração em problemas complexos, não como uma declaração de que a inteligência artificial passou a resolver automaticamente toda questão matemática. A mesma lógica de tentativa e validação aparece quando a equipe deixa o papel e entra na engenharia de sistemas.

Na engenharia de sistemas, o exemplo divulgado envolve um simulador de CPU, isto é, um programa que representa o funcionamento de uma unidade central de processamento, baseado em RISC-V, referência arquitetural usada no experimento. O resultado registrou 0,71% de erro de alinhamento, métrica apresentada pelo Google para avaliar a correspondência do simulador com o comportamento esperado. O número dá uma medida concreta para a demonstração, mas não elimina a necessidade de compreender o que foi testado, quais condições foram usadas e como o resultado será verificado fora daquele fluxo. A equipe de agentes aparece, nesse caso, como uma forma de dividir o trabalho de engenharia e revisar a implementação, enquanto a métrica oferece um ponto objetivo de comparação. O percurso continua nas otimizações de código, onde a produção pode ser observada em projetos de código aberto.

O mesmo processo também foi aplicado a otimizações em código aberto nas bibliotecas Eigen e ParlayHash. Código aberto é aquele cuja implementação pode ser examinada e modificada de acordo com as regras da licença, o que torna a revisão externa uma parte visível do trabalho. A análise independente sobre o Teamwork confirmou a existência de patches gerados pelo sistema nessas bibliotecas, conectando a demonstração a artefatos que podem ser avaliados fora da conversa original. Essa passagem é relevante porque troca a promessa abstrata por uma entrega técnica concreta: uma alteração de código precisa sobreviver à inspeção, aos testes e ao uso no projeto em que foi proposta. O agente, nesse desenho, produz uma contribuição que ainda precisa ser lida como contribuição técnica, não como autoridade definitiva.

O modelo por trás da engrenagem

Os resultados estão ligados ao lançamento do Gemini 3.7 Flash, modelo apresentado para desempenho de codificação e eficiência de custo em agentes destinados à produção. O preço introdutório informado foi de US$ 0,75 por 1 milhão de tokens de entrada e US$ 3,75 por 1 milhão de tokens de saída até 31 de dezembro de 2026. Tokens são unidades usadas para dividir e processar o texto recebido e produzido por um modelo, portanto a cobrança relaciona o valor ao volume de informação movimentado. Essa estrutura de preço ajuda a entender a aposta do Google: uma equipe com vários agentes pode consumir mais processamento do que uma interação simples, e o custo passa a fazer parte do desenho da ferramenta. A eficiência financeira aparece, assim, ao lado da capacidade de colaboração, e não como um detalhe separado.

Esse desempenho também foi medido em codificação. O Gemini 3.7 Flash atingiu 65,3% no DeepSWE v1.1, resultado apresentado como melhoria na precisão de código em comparação com o Gemini 3.6 Flash. O nome DeepSWE v1.1 identifica o teste utilizado para essa medição, e o número deve ser lido dentro desse instrumento específico, não como uma nota geral para toda atividade de programação. A relação entre modelo e framework fica mais clara nesse ponto: o Gemini fornece a capacidade de raciocínio e geração, enquanto o Teamwork organiza agentes, críticas e ciclos de revisão. Uma peça pode aumentar a qualidade da outra, mas o resultado final ainda depende da tarefa, dos critérios de teste e da inspeção do trabalho produzido.

O que a plataforma muda na prática

A proposta se torna mais concreta quando observada junto das ferramentas da plataforma Antigravity. A página geral descreve o Antigravity CLI, uma interface de linha de comando voltada ao uso pelo terminal, e um SDK em Python para prototipar agentes. O CLI aproxima a execução do ambiente em que muitos projetos de engenharia já são administrados, enquanto o SDK oferece uma forma de experimentar agentes por meio de código. A plataforma também inclui um ambiente IDE integrado, isto é, um espaço de desenvolvimento que reúne ferramentas para gerenciar vários agentes em projetos de software. O conjunto sugere um centro de comando para organizar experimentos e tarefas, mas a demonstração do Teamwork continua sendo uma arquitetura de colaboração, com padrões e verificações que precisam ser definidos de acordo com o problema.

Para quem desenvolve, pesquisa ou acompanha o futuro do trabalho, a aplicação mais imediata está em observar o fluxo completo, não apenas a resposta final. Uma tarefa pode ser dividida, submetida a agentes críticos, confrontada com um registro de armadilhas e avaliada por um teste específico, como ocorreu nos exemplos apresentados. A pergunta que permanece é de natureza quase literária: quando várias vozes artificiais revisam uma ideia, onde está a autoria do resultado e quem assume a responsabilidade por seu erro? O material disponível não responde a esse dilema, mas oferece uma pista operacional: a autonomia anunciada é organizada por padrões e limitada por verificações, enquanto as entregas ainda precisam ser examinadas por pessoas e por critérios técnicos.

A caixa de ferramentas para ler o anúncio

O próximo passo para interpretar o Teamwork é separar três camadas que aparecem juntas na demonstração: o Gemini 3.7 Flash como modelo, o Teamwork como método de coordenação e os testes ou revisões como mecanismos de controle. Essa separação evita confundir desempenho em um benchmark com competência universal e impede que uma prova validada seja tratada como garantia para qualquer outro problema. Na prática, quem avaliar a plataforma deve observar qual padrão foi selecionado, quais agentes tiveram a função de procurar falhas e qual evidência sustenta a resposta. Os exemplos em matemática, simulação de CPU e código aberto mostram aplicações diferentes da mesma ideia de colaboração, mas cada resultado permanece ligado às condições em que foi produzido.

Até 31 de dezembro de 2026, o preço introdutório divulgado para o Gemini 3.7 Flash oferece uma referência concreta para quem quiser medir o custo de agentes em produção, enquanto o Teamwork fornece a estrutura para distribuir e revisar tarefas complexas. O anúncio, portanto, deixa uma ferramenta específica nas mãos do leitor: começar pelo problema, escolher o tipo de trabalho, exigir uma etapa de falsificação e conferir o resultado com métricas ou revisão documental. O Google apresentou uma equipe artificial organizada, não uma consciência digital independente; compreender essa diferença é o que permite usar a tecnologia com curiosidade, rigor e responsabilidade.