O anúncio de Managed Agents na Gemini API parece, à primeira vista, apenas mais uma expansão do catálogo de recursos do Google para desenvolvedores. Mas essa leitura perde o ponto principal. O que está em jogo aqui não é só um novo endpoint ou uma conveniência para quem já usa Gemini. A jogada estratégica é maior: o Google quer empacotar a parte mais difícil de construir agentes de IA — ambiente de execução, loop de ferramentas, persistência de contexto operacional e definição de comportamento — como um serviço nativo de plataforma.

Em vez de pedir que cada equipe monte sua própria “engenharia de agência” com frameworks, containers, sandboxes, orquestradores e muito código de cola, o Google está dizendo: deixe essa camada conosco.

O exemplo central desse movimento é o Antigravity, apresentado como um agente gerenciado de uso geral na Gemini API. Pela documentação oficial, uma única chamada pode acionar um agente capaz de raciocinar, executar código, manipular arquivos e navegar na web dentro de um sandbox Linux remoto e seguro, hospedado pelo próprio Google. Esse detalhe é crucial. Não se trata apenas de um modelo chamando ferramentas abstratas; existe uma infraestrutura de execução concreta por trás, provisionada como parte do produto.

O que muda na prática

Durante muito tempo, construir um agente “de verdade” significou montar uma pilha paralela ao modelo. O LLM era só uma parte do sistema. Era preciso decidir como o agente usaria ferramentas, onde executaria código, como arquivos seriam criados e preservados, como sessões multi-etapas seriam retomadas e como limitar tudo isso com segurança. Na prática, boa parte do trabalho ainda recai sobre times de produto e infraestrutura.

É exatamente essa fricção que o Google tenta remover.

No Antigravity, cada chamada pode provisionar um ambiente Linux e iniciar um loop de uso de ferramentas em que o agente planeja, age, observa os resultados e itera até concluir a tarefa. A documentação também destaca um ponto importante para usos menos triviais: esse ambiente pode ser reutilizado em interações subsequentes, preservando arquivos e estado. Isso empurra a experiência para além do padrão “prompt entra, texto sai” e aproxima o produto de uma máquina de trabalho temporária operada por IA.

Essa persistência controlada é uma peça central do argumento do Google. Muitos casos de uso para agentes quebram quando tudo precisa ser refeito a cada chamada. O Google está tentando transformar essa continuidade em capacidade nativa da API, e não em responsabilidade do cliente.

De modelos para infraestrutura agentic

O aspecto mais relevante do lançamento talvez esteja menos no que o agente faz e mais em quem passa a ser dono da camada de execução.

Nos últimos dois anos, o mercado de IA generativa se acostumou a separar duas camadas. De um lado, os modelos. Do outro, a infraestrutura agentic: frameworks de orquestração, memória, sandboxes, ferramentas, rastreamento de sessões e guardrails. Essa segunda camada, em geral, ficou pulverizada em bibliotecas open source, produtos especializados e implementações internas. O anúncio do Google aponta para uma integração vertical: o provedor do modelo também quer controlar o ambiente onde o agente opera.

Há vantagens claras nisso: menos distância entre capacidade do modelo e produto final, menos engenharia para colocar agentes em produção e mais concentração de segurança e observabilidade numa plataforma única.

Mas há uma implicação comercial ainda mais importante: quando a infraestrutura agentic vira serviço nativo, o valor deixa de estar apenas no acesso ao modelo e passa a incluir o ambiente operacional que o torna útil. Em outras palavras, o Google não está vendendo só inteligência; está vendendo a esteira de execução da inteligência.

O significado de AGENTS.md e SKILL.md

Talvez o sinal mais eloquente dessa ambição esteja na forma de customização proposta. Segundo o anúncio, desenvolvedores poderão definir agentes gerenciados com arquivos como AGENTS.md e SKILL.md. O ponto aqui não é a sintaxe em si. O importante é a tentativa de deslocar a definição de agentes do terreno do código de orquestração para um modelo mais declarativo, versionável e legível por humanos.

Isso sugere uma visão de produto bastante clara. O Google quer que criar um agente não signifique necessariamente escrever toda a lógica estrutural de execução. Em vez disso, a empresa tenta transformar instruções, habilidades e dados em artefatos de configuração de alto nível, deixando a plataforma cuidar do resto.

Se essa abordagem funcionar bem, ela pode reduzir um problema real do ecossistema atual: muita solução de agentes depende de código artesanal demais para tarefas que, no fundo, são repetitivas — encadear ferramentas, manter estado, operar arquivos, buscar páginas, executar scripts e retornar resultados. Arquivos como AGENTS.md e SKILL.md apontam para uma espécie de “infraestrutura como comportamento”, em que o desenvolvedor descreve o agente e a plataforma realiza a execução.

Ainda é cedo para saber quão flexível isso será fora de demos e casos guiados. Mas, conceitualmente, a proposta é forte: simplificar a camada de montagem sem reduzir o agente a um prompt com verniz.

Antigravity não é só um brinquedo de playground

A documentação do Antigravity também mostra que o agente nasce conectado a ferramentas específicas. Por padrão, ele pode usar execução de código, Google Search e URL Context, além de capacidades de sistema de arquivos habilitadas quando o parâmetro de ambiente remoto é usado. Isso importa porque indica um produto pensado para tarefas abertas, não apenas para workflows rigidamente fechados.

Na prática, estamos falando de um agente que pode pesquisar, ler páginas, escrever arquivos, rodar comandos e iterar sobre os próprios resultados. Isso aproxima a API do tipo de experiência que muitos usuários já associam a assistentes “operacionais”, e não apenas conversacionais.

Há, porém, uma diferença relevante entre demonstração técnica e adoção de produção. O valor dessa arquitetura dependerá menos do efeito “uau” de uma tarefa complexa resolvida em uma chamada e mais da previsibilidade com que ela se comporta em escala: tempo de execução, custo, confiabilidade, controles de segurança, observabilidade e governança. O anúncio toca no problema que pretende resolver; o mercado vai julgar a solução pelo que acontecer nessas camadas menos vistosas.

A concorrência existe, mas a disputa real é pela pilha

É inevitável comparar esse movimento com uma tendência mais ampla do setor: provedores de modelos e plataformas tentando subir na cadeia e capturar a camada de agentes. Mas vale evitar simplificações. A questão não é apenas “quem lançou primeiro” ou “quem tem agente mais autônomo”. A disputa mais séria é por quem se torna o lugar padrão onde agentes são definidos, executados e mantidos.

Nesse sentido, o Google parece mirar um espaço que hoje ainda é fragmentado entre SDKs, frameworks e soluções internas. Ao abrir a infraestrutura que já sustentava experiências próprias — o texto menciona o Deep Research como um managed agent anterior — a empresa tenta transformar uma competência interna em plataforma externa.

É um movimento típico de consolidação: algo que começou como capacidade proprietária de produto passa a ser oferecido como bloco reutilizável para terceiros. Se der certo, a vantagem competitiva não virá apenas da qualidade do Gemini 3.5 Flash, mas da facilidade com que empresas consigam construir fluxos agentic sem levantar um pequeno sistema operacional paralelo.

O que o lançamento ainda não responde

Como toda estreia em preview, o anúncio também deixa perguntas em aberto. O quanto esse modelo de agentes gerenciados será personalizável para fluxos realmente específicos? Até onde vai a abstração antes que times mais avançados sintam necessidade de “quebrar a caixa” e retomar controle da orquestração? Como ficam portabilidade e risco de acoplamento a uma plataforma única?

Essas perguntas não invalidam o lançamento; apenas lembram que a promessa de simplificação sempre traz um trade-off. Quanto mais infraestrutura o provedor absorve, mais conveniente a experiência tende a ser — e maior também pode ser a dependência da sua forma particular de operar agentes.

Ainda assim, o raciocínio estratégico do Google é claro e faz sentido. Se o desenvolvimento de agentes continuar evoluindo para algo menos experimental e mais operacional, a camada de execução deixará de ser detalhe técnico e passará a ser parte central da oferta. Quem dominar essa camada poderá definir o padrão de como agentes são construídos.

Conclusão

O lançamento de Managed Agents na Gemini API deve ser lido menos como um recurso isolado e mais como uma tentativa de reorganizar a pilha de IA em torno do próprio provedor. Com o Antigravity, o Google oferece um pacote que junta modelo, ferramentas, sandbox Linux remoto, persistência de ambiente e uma forma declarativa de definir agentes com AGENTS.md e SKILL.md.

A novidade, portanto, não está apenas em permitir que um agente execute código ou navegue na web. Está em transformar toda essa engrenagem em serviço nativo.

Se essa proposta amadurecer, o impacto pode ser relevante: menos tempo gasto montando bastidores e mais foco no comportamento do agente e na experiência do produto. Ao abrir sua infraestrutura agentic na Gemini API, o Google sinaliza que enxerga o próximo campo de disputa não só nos modelos, mas na operacionalização deles. E, hoje, essa pode ser a camada mais valiosa de todas.