Google Gemini e o novo jeito de montar agentes: ADK e Managed Agents
TL;DR
O anúncio em torno de “Gemini agent framework” não aponta para uma única peça, e sim para duas camadas da estratégia do Google: o Agent Development Kit (ADK), voltado a construção em código, e os Managed Agents, voltados a execução gerenciada. Na prática, isso muda o trabalho do dev: sai a integração improvisada em scripts soltos e entra uma arquitetura em que agente, ambiente, conectores e avaliação ficam mais explícitos.
O que mudou no ecossistema Gemini
A leitura mais útil desse lançamento é separar ferramenta de desenvolvimento e runtime de execução. O ADK aparece como framework open-source code-first para construir, avaliar e deploymentar agentes, enquanto os Managed Agents do Gemini privilegiem uma configuração declarativa com ambiente, instruções e skills. Essa divisão conversa bem com o momento atual da IA aplicada: o desafio já não é apenas chamar o modelo, mas organizar o ciclo de vida do agente.
O próprio changelog do Gemini API mostra que a plataforma vem ampliando a superfície de automação e integração, incluindo recursos para agentes e ferramentas como MCPServer. Isso importa porque o “framework” deixa de ser só uma biblioteca local e passa a se conectar com um ecossistema de runtime, ferramentas e protocolos que precisam conversar entre si.
ADK: o lado code-first
No ADK, a promessa é aproximar desenvolvimento de agentes do que já conhecemos em engenharia de software. O repositório google/adk-python descreve o toolkit como modular, open-source e orientado a agentes e workflows em grafo, o que facilita compor etapas, subagentes e orquestração de tarefas.
Isso é importante porque muitos projetos de IA começam como prova de conceito e acabam presos em um arquivo único, sem separação clara entre instrução, lógica e execução. Um framework code-first tende a ajudar na testabilidade, no versionamento e na reutilização de componentes, especialmente quando o time precisa medir comportamentos e repetir experimentos.
Managed Agents: o lado configurável e gerenciado
Já os Managed Agents do Gemini empurram a experiência para um modelo mais declarativo. Em vez de montar toda a infraestrutura no aplicativo, você define um base_agent, uma system_instruction, um base_environment e recursos relacionados a fontes e skills, e deixa parte da execução no runtime do Google. O guia oficial de managed agents mostra justamente esse fluxo de criação e uso via API.
O benefício aqui é operacional: menos cola de integração, menos partes móveis e mais padronização. O custo é outro: quanto mais a execução fica gerenciada, mais importante fica entender onde os dados vivem, qual o escopo do ambiente e como controlar acesso a recursos externos.
O papel de segurança e conectividade
Um ponto central no material encontrado é o controle de ambiente. O developer guide de Managed Agents detalha configuração em sandbox com egress control e allowlists, o que é relevante para evitar que um agente saia falando com qualquer serviço da rede sem critério.
Isso é um detalhe técnico, mas na prática é um dos pontos que definem se um agente pode chegar a produção. Em cenários reais, agente sem limitação de rede vira risco de custo, risco de vazamento e risco de comportamento inesperado. No Brasil, isso conversa diretamente com exigências de LGPD e com a necessidade de rastrear melhor onde dados sensíveis trafegam.
Como isso se encaixa em arquitetura de produto
O release fica mais claro quando você pensa em três camadas: orquestração, ambiente e ferramentas. O ADK cobre bem a orquestração em código; os Managed Agents cobrem parte do ambiente e da execução; e o ecossistema Gemini amplia a ligação com ferramentas e protocolos. Essa separação é útil porque torna mais fácil decidir o que deve ser controlado pelo time e o que pode ficar sob responsabilidade do fornecedor.
Para produto, isso significa menos improviso na criação de assistentes internos, chatbots corporativos e automações com ação real. Para engenharia, significa que prompts, skills, instruções e conectores passam a ser tratados como artefatos que merecem revisão, observabilidade e ciclo de vida próprio.
Onde o time costuma errar
O erro mais comum é tentar usar agente como se fosse apenas um prompt bonito com acesso a uma API. Quando a complexidade cresce, surgem problemas de estado, recuperação de falhas, limites de contexto e governança do ambiente. O formato apresentado pelo Google sugere justamente o contrário: definir o agente como unidade de software, com fronteiras mais claras.
Outro erro é tratar instruções e skills como texto descartável. Quando o runtime aceita arquivos, base environment e configurações declarativas, essas peças passam a fazer parte do processo de entrega. Isso pede versionamento, revisão e documentação interna, do mesmo jeito que já fazemos com infraestrutura como código.
Por que isso importa pro dev brasileiro
O contexto brasileiro torna essa discussão mais concreta porque muita operação ainda vive sob restrição de custo, latência e compliance. Rodar fluxos de IA em regiões distantes, com dependência de vários serviços externos, pode pesar em BRL e em experiência do usuário; além disso, a LGPD exige cuidado com base legal, finalidade e tratamento de dados pessoais. Em empresas brasileiras, esse tipo de arquitetura só escala de verdade quando segurança e rastreabilidade entram desde o desenho.
Há também um fator de formação profissional. No Brasil, é comum encontrar devs que vieram de bootcamp, transição de carreira ou autodidata, então um framework que explicita camadas, responsabilidades e workflows ajuda a reduzir a dependência de “mágica” no prompt. Isso facilita revisão por pares, onboarding e manutenção em times que nem sempre têm um especialista de IA dedicado.
O que testar na prática
Se você quiser avaliar o movimento do Google sem fazer uma migração grande, comece por um agente simples com uma tarefa repetível: classificar tickets, resumir documentos internos ou acionar uma API controlada. O objetivo não é montar um laboratório de demo, e sim verificar se a separação entre instrução, ambiente e ferramentas melhora a operação real do time.
Depois, compare dois cenários: um fluxo local, controlado pelo seu código, e um fluxo gerenciado. Observe onde ficam os logs, como você versiona os prompts, como define permissões de rede e o que muda quando o agente precisa chamar outra ferramenta. Essa comparação costuma revelar rapidamente se o modelo serve para produção ou se fica melhor como prova de conceito.
Esta seção descreve a versão atual do ecossistema Gemini/ADK citada nas fontes. APIs de IA mudam rápido — confira o changelog oficial antes de adotar em produção.
Um bom ponto de referência é acompanhar o changelog oficial do Gemini API e o repositório google/adk-python antes de decidir arquitetura, porque esse tipo de plataforma evolui rápido e mudanças de integração costumam afetar código, permissões e deployment.
Conclusão
O recado do Google é simples: agente deixou de ser um experimento isolado e virou uma unidade de software com ciclo de vida, ambiente e governança. O ADK favorece a construção em código; os Managed Agents favorecem execução gerenciada; e, juntos, eles mostram que a próxima etapa da IA aplicada é menos sobre “fazer a demo funcionar” e mais sobre operar com previsibilidade.
Se você já trabalha com cloud ou automação, vale reservar uma hora para ler o README do ADK e o guia de Managed Agents, e anotar quais partes do seu fluxo atual já deveriam ter versionamento, controle de rede e observabilidade mais explícitos.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
