Gemini API ganha agentes com tarefas em segundo plano e MCP

Já imaginou pedir uma tarefa longa a um agente de IA e fechar a conexão sem derrubar o trabalho no meio? É essa situação que a Google quer resolver com uma atualização dos Managed Agents na Gemini API, anunciada em 7 de julho de 2026. A novidade reúne execução em segundo plano, conexão com servidores remotos do Model Context Protocol (MCP), funções personalizadas e renovação de credenciais entre interações.

O anúncio foi feito no blog Google AI. Segundo a empresa, as mudanças respondem a pedidos de desenvolvedores que precisam montar agentes capazes de operar em tarefas mais demoradas e conectadas a sistemas próprios. Na prática, a proposta é tirar parte da infraestrutura das mãos do time que desenvolve o agente, sem eliminar a necessidade de controlar permissões, funções e credenciais.

O que muda para quem desenvolve agentes

Os Managed Agents funcionam dentro da Gemini Interactions API. O desenvolvedor faz uma chamada para um único endpoint, enquanto a plataforma administra raciocínio, execução de código, instalação de pacotes, gerenciamento de arquivos e acesso a informações da web em um sandbox isolado na nuvem.

A primeira mudança importante é a execução em segundo plano. Em vez de manter uma conexão HTTP aberta durante uma tarefa longa — um modelo frágil para processos que podem demorar — o cliente envia background: true. A API devolve imediatamente um ID, que pode ser usado para consultar o status, acompanhar o progresso em streaming ou reconectar depois.

Imagine um agente trabalhando em um ambiente de desenvolvimento enquanto sua aplicação precisa continuar respondendo a outras solicitações. Com esse fluxo, o sistema não depende de uma conexão permanentemente aberta para saber se o trabalho terminou. O agente continua no servidor, e o cliente acompanha a interação por meio do identificador retornado.

A atualização também permite conectar o agente diretamente a servidores MCP remotos. O MCP funciona, neste caso, como uma ponte padronizada para ferramentas e endpoints externos. Assim, um agente pode combinar recursos já disponíveis no sandbox, como execução de código e Google Search, com ferramentas hospedadas em servidores remotos.

Essa conexão pode reduzir a necessidade de criar um middleware próprio para cada banco de dados privado ou API interna. Mas “reduzir” não significa eliminar a arquitetura de segurança: o próprio material da Google recomenda seguir boas práticas ao ampliar o agente com ferramentas e APIs externas. A integração torna o acesso possível; não transforma automaticamente qualquer sistema interno em uma fonte segura ou confiável.

Outro recurso é o chamado custom function calling. O agente pode usar ferramentas nativas do sandbox e funções personalizadas na mesma interação. A API aplica uma lógica de “step matching”: ferramentas internas são executadas automaticamente no servidor, enquanto uma função personalizada leva a interação ao estado requires_action. Nesse ponto, o cliente precisa executar a lógica de negócio local e devolver o resultado.

Esse detalhe é relevante. Se uma função precisar consultar uma regra específica da empresa ou acionar um sistema próprio, o agente não executará tudo sozinho. A aplicação continua responsável por essa etapa, o que preserva um ponto de controle, mas também exige que o time implemente corretamente o retorno da ação.

Credenciais, estado e limites práticos

A Google também passou a permitir a atualização de credenciais entre interações. Tokens de acesso e chaves de curta duração expiram; para renová-los ou alterná-los, o desenvolvedor pode enviar o environment_id existente com uma nova configuração de rede na interação seguinte. As novas regras substituem imediatamente as anteriores, enquanto o sandbox mantém o estado do sistema de arquivos, os pacotes instalados e os repositórios clonados.

Esse comportamento combina persistência de ambiente com rotação de acesso. Um projeto não precisa necessariamente começar do zero quando a credencial muda, mas a troca imediata das regras aumenta a importância de configurar corretamente a rede e as permissões. Uma chave atualizada não deve ser tratada como autorização ampla para tudo que o agente consegue alcançar.

Em privacidade e segurança, o dado confirmado no anúncio é que as operações ocorrem em um sandbox isolado na nuvem. O material também direciona os desenvolvedores para recomendações específicas de segurança ao usar agentes e ferramentas externas. A publicação, porém, não detalha políticas de retenção, tratamento dos dados enviados, localização da infraestrutura ou garantias independentes sobre isolamento. Portanto, não dá para concluir, apenas com essas informações, como cada aplicação será protegida em cenários reais.

Também há limites claros no que foi apresentado. A Google descreve as atualizações como uma forma de construir agentes “confiáveis” e “prontos para produção”, mas o anúncio não traz benchmarks, resultados de testes independentes, métricas de disponibilidade ou exemplos de desempenho comparativo. A capacidade técnica foi anunciada e documentada; sua maturidade para cada caso de uso ainda depende da implementação e da validação do desenvolvedor.

O texto não informa preço, limites de uso, cotas ou condições comerciais para esses recursos. Também não especifica uma data separada de disponibilidade por região ou um cronograma de liberação gradual. O que está acessível são as páginas de documentação da Managed Agents in Gemini API, da execução em segundo plano e do início rápido para agentes gerenciados.

Para quem já trabalha com a Gemini API, o impacto mais direto está na arquitetura. Tarefas longas podem deixar de bloquear a aplicação; ferramentas privadas podem ser conectadas por MCP; funções de negócio continuam sob execução do cliente; e ambientes persistentes podem receber novas credenciais sem perder arquivos, pacotes ou repositórios.

O próximo passo, portanto, não é simplesmente ligar um botão e liberar um agente para operar sozinho. É testar cada fluxo: verificar como o status é consultado, definir o que acontece quando uma função entra em requires_action, limitar o acesso das ferramentas remotas e confirmar como a rotação de credenciais afeta a rede. A promessa é uma API mais preparada para trabalhos contínuos. A prova de que ela funciona bem continua sendo o teste no ambiente real de cada equipe.