O Google ampliou os Managed Agents da Gemini API com mecanismos para bloquear ou auditar ações, limitar o consumo de tokens e executar tarefas em horários programados. O anúncio foi publicado em 28 de julho de 2026 e tornou o Gemini 3.6 Flash o modelo padrão do agente Antigravity. A documentação consultada em 16 de agosto continua indicando esse modelo como padrão e mantém o serviço em prévia.
A atualização é importante menos pelo nome do modelo e mais pelos controles ao redor dele. Um agente que executa código, grava arquivos, instala pacotes e navega na web precisa de limites verificáveis. Hooks, orçamento máximo e gatilhos de agendamento aproximam o serviço de uma rotina operacional, mas não eliminam revisão humana, configuração de rede nem testes de falha.
O que o Google anunciou
No comunicado oficial de 28 de julho, o Google reuniu cinco mudanças para os Managed Agents: Gemini 3.6 Flash como padrão naquele momento, seleção explícita de modelo, hooks de ambiente, acesso em projetos da camada gratuita, limite total de tokens e execução recorrente com triggers.
Os Managed Agents fazem parte da Interactions API, assunto que o Bastidores já explicou na notícia sobre a migração da Interactions API. Em uma chamada, o serviço pode provisionar um sandbox Linux no qual o agente raciocina, executa código, gerencia arquivos, instala pacotes e consulta a web. A infraestrutura reduz o trabalho de montar o ciclo do agente, porém concentra mais ações em uma única execução.
Esse detalhe muda a pergunta que uma equipe deve fazer. Não basta saber se o modelo produz uma boa resposta. É necessário definir quais ferramentas ele pode usar, quais destinos de rede pode alcançar, quanto pode consumir, o que acontece quando uma validação falha e quem revisa o resultado antes de qualquer implantação.
Hooks criam pontos de controle antes e depois das ferramentas
Os hooks permitem executar um script ou fazer uma chamada HTTP antes ou depois de uma ferramenta. A configuração fica em .agents/hooks.json dentro do ambiente. O evento pre_tool_execution ocorre antes da ação e pode negá-la. Já o post_tool_execution roda depois e serve para tarefas como formatação, validação ou telemetria.
Um uso prático seria impedir que o agente grave em uma pasta restrita, verificar um arquivo recém-criado ou registrar cada chamada de ferramenta em um sistema de auditoria. A documentação permite associar um hook a ferramentas específicas ou usar um padrão mais amplo. Isso transforma uma orientação escrita no prompt em uma barreira executável, desde que o hook tenha sido configurado e testado corretamente.
Há um contraponto decisivo. A documentação de hooks informa que falha de script, resposta HTTP fora da faixa de sucesso, tempo excedido ou JSON inválido são tratados como aprovação. Em outras palavras, o mecanismo segue uma lógica de permitir a ação quando o validador quebra, para não travar o fluxo.
Esse comportamento pode ser aceitável para um formatador ou uma coleta de telemetria, mas merece cautela em controles de segurança. Se uma organização precisa bloquear por padrão quando o validador está indisponível, não deve presumir que o hook sozinho implementa essa política. O desenho pode exigir restrições adicionais no próprio ambiente, nas credenciais, na rede e no sistema que recebe a saída.
Rede e credenciais continuam sendo parte do risco
A visão geral atual dos agentes diz que o sandbox é isolado no nível do sistema operacional, mas permite acesso de saída irrestrito à rede por padrão. A equipe pode limitar os destinos com uma lista de permissões ou desativar a rede. Isso é especialmente relevante quando o agente recebe arquivos internos ou acesso a ferramentas externas.
Para credenciais, o Google recomenda contas e chaves com o menor privilégio possível, tokens de curta duração e rotação regular. A documentação também descreve transformação de cabeçalhos no proxy de saída, de forma que o segredo real não precise ficar dentro do sandbox. Mesmo assim, qualquer credencial concedida pode ser usada dentro do escopo autorizado. O princípio seguro é fornecer somente o acesso que a tarefa realmente exige.
Limite de tokens reduz uma forma de execução descontrolada
Agentes costumam repetir ciclos de raciocínio e ferramenta. Uma tarefa aparentemente curta pode abrir arquivos, pesquisar, testar uma hipótese e voltar ao início. Para controlar esse consumo, a atualização adicionou o campo max_total_tokens na configuração do agente.
O limite cobre tokens de entrada, saída e raciocínio. Quando ele é atingido, a interação retorna como incompleta e o estado do ambiente é preservado. A execução pode ser retomada com o identificador da interação anterior e um novo orçamento. Isso ajuda a diferenciar uma pausa controlada de um processo que continua consumindo sem um teto definido.
A documentação atual estima que uma única interação gerenciada pode usar de 100 mil a 3 milhões de tokens em seus vários ciclos. Essa faixa não é promessa de custo nem previsão para todo caso. Ela é um alerta de escala. Antes de automatizar, vale medir uma tarefa representativa, registrar o consumo e definir um limite compatível com o risco e a utilidade esperada.
Triggers permitem recorrência, mas criam estado entre execuções
Os gatilhos agendados associam um agente, um ambiente, um pedido e uma expressão cron a um recurso persistente. A referência da Triggers API também prevê fuso horário, tempo máximo de execução e quantidade máxima de falhas consecutivas antes de o gatilho entrar em estado de erro.
Segundo o anúncio, cada execução reutiliza o mesmo sandbox. Arquivos produzidos em uma rodada podem permanecer disponíveis na próxima. Isso é útil para relatórios recorrentes ou acompanhamento de um projeto, mas também cria estado acumulado. Um arquivo antigo, uma dependência alterada ou uma saída parcial pode influenciar a execução seguinte.
Uma rotina agendada deveria, portanto, registrar pelo menos o identificador da execução, o horário, a versão do pedido, os arquivos lidos e gravados, o status final e o motivo de qualquer falha. Também precisa definir se o comportamento correto é retomar o ambiente existente ou começar de um estado limpo.
Camada gratuita não significa execução sem custo
O anúncio informa que projetos sem faturamento ativo podem experimentar Managed Agents dentro da camada gratuita, sujeitos às cotas aplicáveis. A página oficial de preços separa os componentes: inferência do modelo e ferramentas seguem as regras de cobrança e de cota da Gemini API, enquanto CPU, memória e execução do sandbox não são cobradas durante a prévia.
Isso não deve ser resumido como “agentes gratuitos”. Uma experiência pequena pode caber na cota gratuita. Uma automação frequente, uma tarefa longa ou um fluxo com muitas chamadas pode superar essa cota ou gerar cobrança quando o projeto tiver faturamento. Como disponibilidade, cotas e preços mudam, a conferência deve ser feita no projeto e na tabela oficial antes de colocar um trigger em produção.
O modelo padrão exige acompanhamento durante a prévia
Em 28 de julho, o Google informou que antigravity-preview-05-2026 passava a usar Gemini 3.6 Flash por padrão. Na consulta de 16 de agosto, a visão geral e a documentação de criação de agentes ainda descreviam Gemini 3.6 Flash como padrão e mantinham Gemini 3.5 Flash e Gemini 3.5 Flash-Lite como opções configuráveis.
Como o recurso segue em prévia, o texto do anúncio deve ser lido como registro daquele momento. Para fluxos que precisam de repetibilidade, confiar apenas no padrão pode ser arriscado. A equipe deve fixar uma opção compatível quando a API permitir, registrar a configuração usada e repetir os testes após mudanças de modelo, esquema ou limites.
Quando isso aconteceu
O anúncio dos hooks, controles de orçamento, triggers e acesso na camada gratuita foi publicado em 28 de julho de 2026. A documentação técnica consultada pelo Bastidores da IA em 16 de agosto de 2026 continuava classificando Managed Agents como prévia e mantinha Gemini 3.6 Flash como padrão.
Esse intervalo curto importa porque exemplos de código, modelos disponíveis e limites podem mudar sem que uma publicação histórica seja reescrita. Para implementar hoje, use a notícia para entender a direção do produto e a documentação atual para confirmar os parâmetros.
Por que isso ainda importa
A novidade mostra uma etapa de amadurecimento das plataformas de agentes. O produto deixa de oferecer apenas um modelo com ferramentas e passa a incluir orçamento, agendamento, estado persistente e pontos programáveis de validação. Esses recursos facilitam automação real, mas também ampliam o impacto de uma configuração inadequada.
O teste mais responsável não começa com acesso amplo nem com uma tarefa crítica. Começa com um ambiente descartável, rede limitada, credencial de baixo privilégio, conjunto pequeno de arquivos e um orçamento baixo. Depois, a equipe força falhas no hook, interrompe a rede, estoura o limite de tokens e observa se a rotina termina de forma compreensível.
O principal ganho dos novos controles é tornar parte do comportamento observável e configurável. O principal limite é que esses controles não substituem governança. Um agente agendado pode executar sem alguém diante da tela, mas ainda precisa de dono, escopo, registro, revisão e uma forma segura de parar.
Fontes oficiais
- Google Blog: atualização dos Managed Agents com hooks, orçamento e triggers, publicada em 28 de julho de 2026.
- Google AI for Developers: visão geral atual dos Managed Agents.
- Google AI for Developers: hooks, decisões e tratamento de falhas.
- Google AI for Developers: referência da Triggers API.
- Google AI for Developers: preços e componentes de custo dos agentes.