Hoje cedo eu vi duas coisas ao mesmo tempo: o repositório adk-go apareceu com 8.374 estrelas no GitHub, e a documentação do Agent Development Kit martelou um recado simples: "build production agents, not prototypes". Quando a conversa sai de demo e entra em produção, eu presto atenção. Se você lidera produto, tecnologia ou operação, eu acho que a pergunta não é "qual framework ganhou a semana".
Hoje cedo eu vi duas coisas ao mesmo tempo: o repositório adk-go apareceu com 8.374 estrelas no GitHub, e a documentação do Agent Development Kit martelou um recado simples: "build production agents, not prototypes". Quando a conversa sai de demo e entra em produção, eu presto atenção.
Se você lidera produto, tecnologia ou operação, eu acho que a pergunta não é "qual framework ganhou a semana". A pergunta útil é outra: esse tal de Google ADK ajuda meu time a tirar um agente do PowerPoint e colocar de pé com menos improviso?
TL;DR
Eu não escolho Google ADK porque o X ficou eufórico. Eu escolho quando preciso organizar agente, ferramenta, aprovação humana e rastro em um fluxo só.
Eu uso o método C.A.B.O. para decidir: Caso claro, Aprovação humana, Blocos determinísticos e Observabilidade.
Eu não piloto se 2 desses 4 pontos falham. Agente sem cabo vira drone bêbado.
O problema
Eu vejo muita empresa comprar IA na ordem errada.
Primeiro vem o encanto. O time vê um agente escrevendo código, navegando em tela ou chamando ferramenta, e pronto: todo mundo acha que o gargalo sumiu.
Depois vem a vida adulta. A tarefa está mal definida, ninguém sabe quando o agente deve parar, o gestor não decide quem aprova os passos de risco, e o piloto nasce sem métrica. Aí a empresa culpa a IA por um problema de gestão. Conveniente. E preguiçoso.
Eu gostei do recado do ADK porque a documentação não vende só prompt bonito. Ela fala de workflow, graph-based agents, evaluation, artifacts, memory e developer UI. Em português claro: ela tenta transformar agente em sistema, não em truque de palco.
Também foi por isso que o assunto esquentou no X nos últimos dias. A conversa girou em torno de controle maior, human-in-the-loop em qualquer nó, fluxos com grafo e menos fé em prompt gigante. Quando eu junto esse barulho com repo grande e docs maduras, eu pelo menos paro para olhar.
Mas eu também não compro hype por atacado.
Eu não acho que Google ADK seja um passe mágico para qualquer empresa. Se o seu time ainda não sabe qual processo quer automatizar, trocar de framework agora é balela. Você só vai profissionalizar a bagunça.
O framework / método
Quando eu preciso decidir se um framework de agentes merece um piloto, eu uso o método C.A.B.O..
Nome simples. Porque framework com nome pomposo costuma esconder confusão cara.
1. Caso claro
Eu começo pelo caso, não pela ferramenta.
Eu só piloto quando a tarefa tem começo, meio, fim. Precisa existir uma entrada clara, um resultado esperado, além de um dono humano. Se eu não consigo descrever a tarefa em cinco linhas, eu ainda não tenho um piloto. Eu tenho ansiedade com API.
No ADK, isso faz sentido porque a proposta toda gira em torno de compor agentes, funções, ferramentas e estado de forma estruturada. Isso combina com tarefas reais como triagem de leads, consolidação de documentos, revisão de cadastro ou preparação de briefing.
Se o seu uso é "quero um agente que melhore a empresa", eu paro aí. Isso não é caso. Isso é mantra de offsite.
2. Aprovação humana
Eu não libero agente para mexer em dinheiro, cliente ou dado sensível sem aprovação humana no meio.
A parte interessante do ADK é que a documentação de grafos mostra nós de função, ferramentas, capacidades de LLM e até entrada humana na mesma esteira. Para mim, esse detalhe muda o jogo. Eu não preciso deixar o agente fingir autonomia total. Eu posso desenhar o ponto exato em que uma pessoa revisa, corrige ou barra.
Na prática, eu gosto de uma regra bem simples: se o agente vai enviar algo para cliente, alterar CRM, disparar e-mail ou tomar decisão com impacto financeiro, eu coloco revisão humana obrigatória.
Autonomia total no primeiro piloto é coisa de gente entediada com o próprio emprego.
3. Blocos determinísticos
Eu gosto de agente que raciocina. Mas eu confio mais quando ele raciocina dentro de um trilho.
A documentação do ADK 2.0 bate forte em graph-based workflows e separa três estilos: grafo para processo estruturado, workflow dinâmico para lógica mais complexa e agentes prontos para padrões como sequência, paralelo e loop. Essa separação é boa porque me obriga a decidir onde eu quero criatividade e onde eu quero previsibilidade.
Eu traduzo isso assim para founder: não jogue tudo em um prompt e reze.
Se parte do processo é fixa, eu transformo em bloco fixo. Se existe condição clara, eu crio desvio claro. Se existe passo arriscado, eu encaixo aprovação. O agente continua útil, mas para de inventar moda em trecho que precisa disciplina.
4. Observabilidade
Eu não aceito piloto sem rastro.
O ADK não fala só de build. Ele fala de evaluation, traces, Developer UI e inspeção do fluxo. Isso importa porque piloto sem observabilidade vira conversa de corredor: "acho que ajudou", "pareceu bom", "talvez economizou tempo". Eu odeio esse talvez.
Eu prefiro três métricas feias e honestas: tempo por tarefa, taxa de intervenção humana e taxa de execução correta.
Se eu não consigo responder essas três perguntas depois de duas semanas, eu não tenho piloto. Eu tenho teatro com token.
Como aplicar hoje
Se eu fosse testar Google ADK hoje em uma empresa média, eu faria assim:
Passo 1: eu escolheria uma tarefa chata e repetitiva
Eu pegaria um processo que já existe, consome tempo toda semana e depende de duas ou três ferramentas no máximo.
Exemplos bons: consolidar briefing comercial, validar cadastro, pesquisar fornecedor, preparar resumo de reunião com próximos passos, ou montar uma pré-análise de lead antes da equipe falar com o cliente.
Passo 2: eu desenharia o fluxo em uma página
Eu escreveria em português simples:
entrada do processo
passos fixos
decisão que pode variar
ponto de aprovação humana
saída esperada
Se o time não consegue desenhar isso, eu não abro framework nenhum ainda.
Passo 3: eu pediria para o time modelar o fluxo em grafo
Eu usaria a visão de grafos do ADK para quebrar o processo em nós: coletar dado, validar regra, gerar rascunho, pedir aprovação e executar ação.
Se o time trabalha mais com Python ou TypeScript, eu não travaria por causa do Go. A própria documentação mostra ADK disponível em Python, TypeScript, Go, Java e Kotlin. O ponto não é a linguagem. O ponto é a disciplina do fluxo.
Passo 4: eu colocaria revisão humana onde dói
Eu deixaria o agente correr solto no trabalho braçal e pararia antes do passo sensível.
Foi exatamente isso que me chamou atenção no ADK: a ideia de misturar lógica determinística com entrada humana. Esse meio-termo costuma funcionar melhor do que prometer um funcionário digital que nunca dorme. Funcionário que nunca dorme também nunca processa trauma. Ainda bem.
Passo 5: eu rodaria um piloto de 14 dias com três métricas
Eu mediria só isto:
quanto tempo a tarefa levava antes versus depois
em quantos casos o humano precisou corrigir o agente
quantos resultados saíram corretos na primeira tentativa
Se você quiser aprofundar antes de mexer nisso, eu leria estes três textos meus na sequência: Servidor MCP: 4 testes antes de liberar para o time, Modelo aberto na IA: 4 filtros antes da troca e O que são skills de IA?.
Resultados esperados
Eu espero três ganhos de um piloto bem escolhido.
O primeiro ganho é clareza. Em duas semanas, eu descubro se o problema era processo ruim, falta de integração ou tarefa boa demais para continuar manual.
O segundo ganho é velocidade com critério. Eu não prometo milagre. Eu espero menos clique bobo, menos retrabalho e mais consistência na parte repetitiva.
O terceiro ganho é decisão melhor. Mesmo quando o piloto falha, eu saio sabendo por que falhou. Isso já vale bastante. Matar um piloto em 14 dias dói menos do que sustentar lorota por seis meses.
Se o piloto der certo, eu amplio escopo aos poucos. Se der errado, eu corrijo o processo primeiro. O que eu não faço é trocar de framework como quem troca de filtro do Instagram.
Perguntas rápidas
Google ADK é só para quem programa em Go?
Não. A documentação pública do ADK mostra suporte para Python, TypeScript, Go, Java e Kotlin. O repositório que ganhou tração agora foi o adk-go, mas a decisão de piloto não depende de casar com Go.
Eu preciso de multi-agent no primeiro piloto?
Eu acho que não. Eu começaria com um fluxo pequeno, com poucos nós, mais uma aprovação humana bem colocada. Vários agentes cedo demais costumam virar mais arquitetura do que resultado.
Onde entra human-in-the-loop nesse tipo de projeto?
Eu colocaria human-in-the-loop nos pontos em que o agente pode enviar algo para fora, mudar registro relevante ou tomar uma decisão com impacto comercial, jurídico ou financeiro.
Google ADK substitui MCP?
Não. Eu vejo ADK como orquestração do agente. Eu vejo MCP como uma ponte para ferramentas e dados quando faz sentido. Se você quiser base antes de misturar os dois assuntos, eu começaria por Servidor MCP: 4 testes antes de liberar para o time.
Qual tarefa eu testaria primeiro?
Eu testaria uma tarefa com regra conhecida, volume recorrente e erro tolerável. Se o primeiro piloto traz risco grande já no primeiro clique, eu escolhi a batalha errada.
Conclusão
Eu gostei do que vi no Google ADK porque a conversa ficou mais adulta.
Menos encantamento com agente onisciente. Mais foco em fluxo, controle, avaliação e aprovação humana.
No fim do dia, é isso que separa quem entrega de quem só mostra demo bonita para board impaciente.
Se você quer desenhar um piloto de agentes com começo, critério e métrica, eu posso ajudar. Fale comigo aqui.