Google ADK: Guia Definitivo para Agentes Multi-Linguagem

TL;DR — O Google ADK é um framework open-source (Apache 2.0) para construir, debugar e deployar agentes de IA. Funciona em cinco linguagens (Python, TypeScript, Go, Java, Kotlin), integra nativamente com Vertex AI, suporta MCP e o protocolo A2A para comunicação entre agentes, e vem com uma UI de debugging embutida. Se você já opera dentro do ecossistema Google Cloud, o ADK elimina semanas de boilerplate. Se não opera — continue lendo mesmo assim, porque a arquitetura vale o estudo.

Overview: O que é o Google ADK e por que ele existe

O Google entrou na corrida dos agent frameworks em 2025 com o Agent Development Kit. Enquanto CrewAI (2023) e LangGraph (2024) já disputavam atenção, o ADK chegou com uma proposta diferente: não ser apenas mais uma lib Python, mas um framework multi-linguagem com runtime de produção integrado ao Google Cloud.

Em maio de 2026, o ADK Python 2.0 alcançou General Availability. Hoje o framework acumula mais de sete milhões de downloads e conta com repositórios oficiais em Python, TypeScript, Go, Java e Kotlin. A Google usa internamente o mesmo framework para construir os agentes dentro do Agentspace e do Customer Engagement Suite — não é um side project jogado no GitHub para ganhar stars.

O pitch oficial, direto do site: “Build production agents, not prototypes.” E honestamente? A arquitetura entrega o que promete.

A LangChain resume bem: “Choose Google ADK if you’re GCP-native and want an opinionated, batteries-included agent runtime with built-in debugging UIs.” Essa frase captura a essência — opinionated, batteries-included, debugging nativo. Se você já navega o ecossistema Google, o ADK não é uma escolha; é quase uma consequência natural.

Tutorial: Seu primeiro agente ADK em 10 minutos

Chega de contexto. Vamos colocar um agente pra rodar.

Pré-requisitos

• Python 3.9+ (para o exemplo; funciona igual em Java 17+, Go 1.21+, Node 18+)
• Uma API key do Gemini (pegue em ai.google.dev)
• Terminal com acesso à internet

Passo 1: Instalação

# Recomendo usar um virtual environment
python -m venv .venv && source .venv/bin/activate

# Instalar o ADK
pip install google-adk

Para as outras linguagens:

# TypeScript/Node
npm install @google/adk

# Go
go get google.golang.org/adk

# Java — adicione ao pom.xml
# <dependency>
#   <groupId>com.google.adk</groupId>
#   <artifactId>google-adk</artifactId>
# </dependency>

Passo 2: Criar o projeto

O ADK vem com CLI própria. Crie a estrutura do projeto:

adk create my_agent
cd my_agent

Isso gera a seguinte árvore:

my_agent/
├── __init__.py
├── agent.py
└── .env

Passo 3: Definir o agente

Abra agent.py e substitua pelo seguinte:

from google.adk import Agent
from google.adk.tools import google_search

root_agent = Agent(
    name="pesquisador",
    model="gemini-2.0-flash",
    instruction="""Você é um assistente de pesquisa técnica.
    Quando o usuário perguntar sobre um tópico, use o Google Search
    para encontrar informações atualizadas e sintetize em português.""",
    tools=[google_search],
)

Repare: nome, modelo, instrução, ferramentas. Quatro campos. Sem YAML de 200 linhas, sem chains encadeados, sem abstrações sobre abstrações. O ADK abraça a filosofia code-first — seu agente é código Python normal.

Passo 4: Configurar a API key

echo "GOOGLE_API_KEY=sua-chave-aqui" > .env

Passo 5: Rodar

Duas opções:

# CLI interativa (terminal)
adk run my_agent

# Web UI com debugging visual
adk web my_agent

A segunda opção abre um browser em localhost:8000 com a interface de desenvolvimento — traces, eventos, estado da sessão, tudo visível em tempo real.

Pronto. Seu agente está rodando, fazendo buscas e sintetizando respostas. Dez minutos, talvez menos.

Deep Dive: Anatomia do ADK

Agora que você tem um agente funcionando, vamos destrinchar o que acontece por baixo do capô.

Agents: Três sabores de inteligência

O ADK não trata “agente” como sinônimo de “wrapper em volta de um LLM”. São três tipos distintos:

LLM Agents — Os mais comuns. Recebem um modelo, instrução e ferramentas. Raciocinam, planejam, decidem qual tool chamar. Seu pesquisador do tutorial é um desses.

Workflow Agents — Determinísticos. Não usam LLM para decidir o fluxo, mas sim lógica de código. O ADK 2.0 trouxe graph-based workflows: você compõe nós de execução (agentes ou funções puras) em um grafo dirigido com branching explícito. Pense em um DAG, mas com a possibilidade de inserir raciocínio AI em nós específicos.

Custom Agents — Herdam de BaseAgent e implementam lógica de orquestração arbitrária. Quando nem o grafo nem o agente simples resolvem seu caso, você desce um nível.

Essa separação é inteligente. Nem todo problema precisa de um LLM decidindo próximos passos — às vezes você quer fluxo previsível com bolsos de inteligência. O ADK torna isso natural.

Tools: A mão do agente no mundo real

Um agente sem ferramentas é um chatbot caro. O ADK oferece três categorias:

Function Tools — Funções Python decoradas que o agente pode chamar. Você escreve a função, documenta o que ela faz, e o LLM decide quando usá-la:

from google.adk.tools import tool

@tool
def consultar_estoque(produto_id: str) -> dict:
    """Consulta o estoque atual de um produto pelo ID."""
    # Sua lógica aqui
    return {"produto_id": produto_id, "quantidade": 42}

MCP Tools — O ADK é um MCP client nativo. Conecte qualquer MCP server e seus tools ficam disponíveis automaticamente para o agente. Sem adapter code, sem wrappers manuais. E o inverso também funciona: você pode expor tools ADK como um MCP server. A interoperabilidade é bidirecional.

OpenAPI Tools — Aponte para um spec OpenAPI e o ADK auto-gera tools a partir dos endpoints. Integração com APIs legadas sem escrever uma linha de código de integração.

Quer saber mais sobre MCP e ferramentas para agentes? Confira nosso guia sobre ferramentas, tools e MCP servers.

Sessions e Memory: Contexto como código

O ADK trata contexto como algo estruturado, não como concatenação bruta de strings até o context window estourar. A arquitetura separa:

• Sessions — Conversas individuais com ID único, isoladas por usuário e aplicação. Cada sessão mantém estado (key-value) acessível por qualquer agente no pipeline. O ADK 2.0 trouxe rewind: você pode rebobinar uma sessão para antes de uma invocação anterior.

• State — Dicionário compartilhado dentro da sessão. Agentes leem e escrevem livremente. É o “barramento de dados” entre sub-agents num pipeline sequencial.

• Events — Cada ação (mensagem do usuário, resposta do agente, chamada de tool) vira um evento imutável na sessão. O log completo de execução fica disponível para debugging e auditoria.

• Memory — Memória de longo prazo, cross-session. O agente lembra informações de interações passadas sem você precisar reimplementar RAG do zero.

A mágica está na forma como o framework filtra automaticamente eventos irrelevantes, sumariza conversas antigas, e faz lazy-load de artefatos pesados. Você não pensa em token budget — o ADK pensa por você.

A2A Protocol: Agentes que falam entre si

Aqui as coisas ficam interessantes de verdade. O Agent-to-Agent (A2A) é um protocolo aberto que o Google desenvolveu para comunicação entre agentes — independente de linguagem, framework ou infraestrutura.

Pense no A2A como o HTTP do mundo agêntico. Três conceitos centrais:

1. Agent Cards — JSON servido em /.well-known/agent.json que descreve as capacidades do agente (nome, skills, formatos de I/O). Qualquer agente pode fazer discovery de outro.

2. JSON-RPC 2.0 — Protocolo de comunicação. Um agente manda message/send com dados estruturados, o outro responde. Simples como uma API REST, porém com semântica agêntica.

3. Task Lifecycle — Cada interação é um Task com estados bem definidos: submitted → working → completed/failed. Funciona para chamadas síncronas e assíncronas.

Na prática, isso significa que seu agente Python pode chamar um agente Go como se fosse um sub-agent local:

from google.adk.agents import SequentialAgent
from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

# Agente Go remoto, exposto via A2A
compliance_agent = RemoteA2aAgent(
    name="compliance_validator",
    agent_card="http://go-agent:8888/.well-known/agent.json",
    description="Valida contratos contra políticas corporativas."
)

# Pipeline: extrai → valida → reporta
pipeline = SequentialAgent(
    name="contract_pipeline",
    sub_agents=[extractor_agent, compliance_agent, report_agent],
)

O RemoteA2aAgent abstrai completamente a comunicação de rede. Você não escreve HTTP client, não serializa JSON-RPC, não lida com retry manual. O ADK cuida disso.

Para entender como esse padrão de orquestração se encaixa em arquiteturas maiores, leia sobre harness e loop — arquitetura de agentes.

MCP Integration: Ferramentas sem fronteiras

O Model Context Protocol já se tornou o padrão de facto para exposição de ferramentas a agentes. O ADK trata MCP como cidadão de primeira classe:

Como client: Configure um MCP server e todos os tools dele ficam disponíveis para seu agente automaticamente. O ADK faz discovery dos tools, registra schemas, e o LLM sabe chamá-los.

Como server: Exponha os tools do seu agente ADK como um MCP server. Outros frameworks (LangChain, CrewAI, qualquer MCP client) podem consumir seus tools sem saber que são ADK por baixo.

Essa bidirecionalidade é um diferencial real. Você não fica preso num ecossistema fechado. Construiu um tool no ADK? Qualquer framework MCP-compatible pode usá-lo. Encontrou um MCP server útil? Plug direto no seu agente.

Debugging UI: Visibilidade total, de graça

Vou ser direto: a UI de debugging do ADK é provavelmente o maior diferencial prático em relação a outros frameworks. Enquanto a maioria te dá print() e reza, o ADK vem com:

• Trace viewer — Visualização de cada passo da execução: qual tool foi chamado, com quais parâmetros, o que retornou, quanto tempo levou.
• Event inspector — Stream de todos os eventos da sessão em tempo real.
• State viewer — Estado atual da sessão, atualizado a cada interação.
• Visual Builder — Interface drag-and-drop para prototipagem rápida de agentes (novo no ADK Web).
• Evaluation dashboard — Rode testes automatizados contra seu agente e veja métricas de qualidade.

Execute adk web e tudo isso aparece no browser. Zero configuração. Compare com a experiência de debugar um agente LangChain onde você precisa configurar LangSmith, criar conta, gerenciar API keys separadas, e torcer para o trace capturar o que você precisa. No ADK, é built-in.

A Infoworld capturou bem: “The ADK includes a command-line interface and a developer UI for running agents, inspecting execution steps (events, state changes), debugging interactions, and visualizing agent definitions.”

Multi-Agent Workflows: Orquestração real

O ADK 2.0 trouxe quatro padrões de orquestração multi-agente:

1. Sequential — Agentes executam em ordem fixa. Output de um alimenta o próximo via state compartilhado.

2. Parallel — Agentes rodam simultaneamente. Útil para buscar informações de múltiplas fontes ao mesmo tempo.

3. Loop — Execução iterativa até uma condição ser satisfeita. Refinamento progressivo.

4. Collaborative — Um coordenador delega dinamicamente para sub-agentes baseado no contexto. O mais flexível e o mais complexo.

5. Graph-based (ADK 2.0) — Composição explícita de nós e edges com decision branching. Combina nós determinísticos com nós de raciocínio AI.

A opção de graph-based workflows é particularmente poderosa. Você ganha a previsibilidade de um DAG com a flexibilidade de inserir LLMs onde faz sentido. Nem tudo precisa ser “autônomo” — às vezes você quer que o agente seja inteligente no nó 3, mas previsível nos nós 1, 2, 4 e 5.

Gemini Enterprise Agent Platform: O ADK em Produção

Em 17 de julho de 2026, o Google Cloud apresentou 13 demos ao vivo que reposicionaram o ADK. O framework deixou de ser “só” uma ferramenta de desenvolvimento — virou o pilar Build de uma plataforma maior: a Gemini Enterprise Agent Platform.

O Google rebrandeou toda a superfície do Vertex AI voltada para agentes em uma plataforma unificada com quatro pilares: Build (ADK), Scale (Agent Runtime + Gateway), Govern (Registry + Model Armor), e Optimize (AutoRaters + observabilidade). Cada pilar é um produto em si, mas juntos cobrem o pipeline completo: do código no seu editor até o agente rodando em produção com governança enterprise.

Vou destrinchar cada peça. O conjunto é ambicioso — resta ver quanto disso já funciona bem fora de demos controladas.

Agent Runtime: Deploy sem pensar em infra

O antigo Agent Engine do Vertex AI evoluiu. Agora se chama Agent Runtime e a proposta é direta: você faz deploy do seu agente ADK e o Runtime cuida de infraestrutura, auto-scaling, session management, health checks e failover.

# Deploy direto do editor para o Agent Runtime
agents deploy --runtime managed --region us-central1

# O Runtime gerencia:
# - Scaling automático baseado em load
# - Session persistence cross-pod
# - Health monitoring + auto-restart
# - Memory Bank para contexto de longo prazo

A integração com Memory Bank é o que mais muda a experiência prática. Antes, persistir memória cross-session exigia configurar seu próprio backend (Firestore, Redis, PostgreSQL). Agora o Agent Runtime oferece Memory Bank como serviço nativo — seu agente lembra de interações passadas e mantém contexto entre sessões sem código extra de sua parte.

Para quem vem de arquiteturas serverless: pense no Agent Runtime como o Cloud Run dos agentes. Você entrega o container (ou nem isso — o Runtime builda a partir do código ADK), e ele lida com o resto. A diferença é que o Runtime entende semântica de agentes. Ele sabe o que é uma session, entende checkpoints, gerencia state de forma inteligente. Não é um container runner genérico — é um agent-native runtime.

Na prática, isso resolve a complexidade operacional de manter agentes stateful em produção. Session affinity, graceful shutdown sem perder contexto, scaling sem corromper estado — são problemas reais que quem já tentou deploy manual conhece bem. O Agent Runtime absorve essa camada.

Um ponto de atenção: quanto mais você delega para o managed runtime, mais dependente fica do GCP. Se portabilidade entre clouds é requisito, vale pesar isso antes de abraçar o Memory Bank nativo.

Agent Gateway: Segurança enterprise

Se o Runtime é o “como rodar”, o Agent Gateway é o “quem pode rodar o quê”.

Cada agente deployado recebe uma identidade única — não uma API key genérica, mas identidade criptográfica com mTLS end-to-end. Agente A falando com Agente B tem comunicação autenticada e encriptada nos dois lados, sem certificados manuais.

O Gateway empilha três camadas de proteção:

1. IAP Authentication — Identity-Aware Proxy na frente de cada agente. Usuários e serviços provam identidade antes de tocar no agente.

2. IAM Authorization — Políticas granulares: “Este agente pode chamar aquele tool.” “Este usuário pode invocar este agente, mas não aquele.” O mesmo RBAC do GCP, aplicado a agentes.

3. Model Armor — Inspeciona todo conteúdo que entra e sai do agente em tempo real. Detecta prompt injection, data leakage, tentativas de jailbreak, e informação sensível vazando nas respostas. Funciona como um WAF, mas para agentes.

# Configuração de segurança no deploy
# O Agent Gateway aplica automaticamente:
# - mTLS entre todos os agentes no mesh
# - IAP auth para chamadas externas
# - Model Armor scanning em requests/responses
# - Audit logging completo via Cloud Audit Logs

Para setores regulamentados (saúde, finanças, governo), o Agent Gateway endereça o argumento mais comum do time de segurança: “como garantimos governança?”. Não é mais “confia no prompt engineering” — é audit trail completo com políticas declarativas.

Agent Registry: Discovery de agentes

Cenário real: 50 agentes deployados por 10 times na mesma organização. Como um agente novo descobre quais existentes pode chamar? Como evitar duplicação?

O Agent Registry resolve com auto-registro. Quando você faz deploy via Agents CLI, o agente aparece no Registry com seu Agent Card (do protocolo A2A). Outros agentes fazem discovery, verificam capabilities e estabelecem comunicação — programaticamente.

A analogia mais precisa: é o DNS dos agentes. Você não hardcoda URLs. Pergunta ao Registry “quem sabe fazer compliance check?” e ele retorna agentes registrados com essa capability, ranqueados por relevância e autorização.

Para organizações grandes, isso destranca composição entre times. Cada time constrói agentes especializados, registra no Registry, e o resto da organização pode montar pipelines usando esses agentes como blocos — sem reunião de alinhamento, sem wiki de integrações.

A ressalva honesta: discovery automático funciona bem quando Agent Cards são bem escritos. Se a descrição do agente for vaga (“faz coisas de compliance”), o Registry devolve resultados igualmente vagos. A qualidade do catálogo depende de disciplina dos times que publicam.

AutoRaters: Avaliação de qualidade com o DeepMind

AutoRaters é um sistema de avaliação desenvolvido em parceria com o DeepMind. A diferença fundamental de abordagens como “pedir pro LLM avaliar a própria resposta”: são modelos especializados, treinados especificamente para avaliar outputs de agentes.

O ciclo opera em flywheel de 5 estágios:

┌─────────────────────────────────────────────────────────────┐
│                    AutoRaters Flywheel                        │
│                                                              │
│  1. Prepare Data                                             │
│     └── OTel traces + casos manuais + cenários sintetizados  │
│                          ↓                                   │
│  2. Run Inference                                            │
│     └── Executar o agente contra o dataset                   │
│                          ↓                                   │
│  3. Grade com AutoRaters                                     │
│     └── Modelos especializados avaliam qualidade             │
│                          ↓                                   │
│  4. Analyze Failure Clusters                                 │
│     └── Agrupar falhas por padrão, identificar root causes   │
│                          ↓                                   │
│  5. Targeted Optimizations                                   │
│     └── Prompt tuning, tool refinement, guardrails           │
│                                                              │
│  ↺ Repetir continuamente                                     │
└─────────────────────────────────────────────────────────────┘

O que diferencia dos frameworks de eval tradicionais (RAGAS, DeepEval): os AutoRaters não são um Gemini genérico com prompt de “avalie esta resposta de 1 a 10”. São modelos calibrados para detectar alucinações, avaliar fidelidade factual, medir relevância contextual e verificar aderência a instruções.

O input também é mais robusto — o sistema puxa traces reais de produção (via OpenTelemetry), combina com casos de teste manuais curados por humanos, e gera cenários adversariais sintetizados. Avaliação tridimensional: produção real + golden set + stress test.

Quem já tentou medir objetivamente se um agente “está bom” sabe a dor. AutoRaters atacam esse problema de forma estruturada. Não é perfeito — nenhum sistema de eval automático é — mas a abordagem de modelos especializados por dimensão de qualidade é mais confiável do que general-purpose LLM-as-judge.

A2UI: Agentes que renderizam interfaces

A2UI (Agent-to-UI) permite que o agente renderize componentes de interface reais durante a conversa. Não markdown com tabela — componentes interativos: layouts responsivos, charts dinâmicos, menus clicáveis, formulários com validação.

O agente decide, no contexto da conversa, que a melhor forma de apresentar a informação é visual. Renderiza o componente. O usuário interage, e essa interação volta como input para o agente.

Exemplo concreto: um agente de analytics que, em vez de despejar números em texto, renderiza um dashboard com filtros interativos. Ou um agente de reservas que mostra um calendário visual com disponibilidades clicáveis. A2UI dissolve a fronteira entre “chatbot de texto” e “aplicação visual”.

A ideia é ousada: a interface não é desenhada a priori, mas gerada pelo agente baseada no contexto da interação. O frontend vira um canvas dinâmico.

Dito isso — isso foi demonstrado em condições de demo. Quão bem esses componentes renderizados se comportam em cenários reais (acessibilidade, responsividade em devices variados, consistência visual com o design system da empresa) ainda precisa de validação em produção. O conceito é poderoso; a maturidade do output é a incógnita.

Agents CLI: Seu editor como command center

O Agents CLI é a ponte entre o ambiente local e a Gemini Enterprise Agent Platform. Instala como extensão em qualquer coding agent — Claude Code, Codex, Antigravity — e entrega 7 operações diretamente no editor:

1. Scaffold — Criar novos agentes com templates e boilerplate configurado
2. Deploy — Push direto para Agent Runtime com configuração declarativa
3. Evaluate — Rodar AutoRaters localmente antes de deployar
4. Monitor — Ver logs, traces e métricas do agente em produção
5. Discover — Buscar agentes no Registry por capability
6. Connect — Configurar comunicação A2A entre agentes
7. Secure — Aplicar políticas de Model Armor e Gateway

# Instalação do Agents CLI
pip install agents-cli

# Scaffold um novo agente
agents new meu-agente --template multi-tool --runtime managed

# Deploy para produção
agents deploy --env production --region us-central1

# Avaliar qualidade antes do deploy
agents evaluate --dataset tests/golden_set.yaml --autorater quality-v2

# Monitorar em tempo real
agents monitor meu-agente --tail --metrics latency,quality

O valor prático: antes, você alternava entre terminal, console GCP, dashboards de monitoramento. Com o Agents CLI, o ciclo inteiro acontece de dentro do editor. Mesma filosofia do kubectl para Kubernetes — uma CLI que é sua interface primária com a plataforma.

Temos um guia dedicado cobrindo tudo: Guia Definitivo: Agents CLI.

Padrão Long-running: Agentes que não perdem o fio

Contribuição menos vistosa, mas talvez a mais relevante para produção real: suporte nativo a agentes long-running. Agentes que pausam, esperam (horas, dias, semanas), retomam, e mantêm contexto intacto.

Três padrões foram demonstrados:

1. Durable State Machines — O agente opera como uma state machine com estados persistidos. Cada transição é atômica e durável. Se o runtime reiniciar, o agente retoma do estado exato onde parou.

from google.adk import Agent
from google.adk.patterns import DurableStateMachine

onboarding_agent = Agent(
    name="customer_onboarding",
    model="gemini-2.0-flash",
    pattern=DurableStateMachine(
        states=["collecting_info", "awaiting_approval", "provisioning", "done"],
        initial="collecting_info",
        # Cada transição é persistida automaticamente
        # O agente pode ficar dias em "awaiting_approval"
    ),
)

2. Event-driven Idle Time — O agente hiberna até receber um evento externo. Não consome recursos enquanto aguarda. Um webhook, um email, uma aprovação manual — qualquer evento acorda o agente e ele continua de onde parou.

3. Checkpoint-and-Resume com Persistent Sessions — Para workflows complexos com progresso incremental, checkpointing automático garante que nenhum trabalho é perdido. Mesmo que o processo caia, o último checkpoint é restaurado.

Esses padrões existem porque processos de negócio reais não são síncronos. Onboarding de cliente que leva 3 dias. Aprovação de contrato esperando assinatura do jurídico. Compliance review com input humano em etapas. Agentes que orquestram esses fluxos não podem ser stateless ou efêmeros — precisam ser duráveis.

O que isso significa na prática

A Gemini Enterprise Agent Platform leva o ADK de “framework para escrever código de agente” para “plataforma end-to-end para operar agentes em produção”. A analogia mais próxima: ter o React (lib de UI) versus ter o Vercel (plataforma que roda, escala, monitora e otimiza seu app React).

Se antes a equação era ADK (código) + você (infra, segurança, monitoring, eval), agora é ADK (código) + Agent Platform (tudo o resto). A mensagem do Google é clara: “Foque no que seu agente FAZ. Nós cuidamos de como ele RODA.”

Para quem acompanha o ecossistema de agent frameworks, esse é o movimento mais agressivo de um cloud provider até agora. A AWS com o Bedrock AgentCore e a Azure com o AI Foundry seguem a mesma direção, mas o Google chegou primeiro com o pacote mais integrado — e com a vantagem do ADK open-source como fundação.

O contraponto justo: plataforma integrada também significa acoplamento. Quanto mais você adota (Runtime, Gateway, Registry, AutoRaters), mais difícil fica migrar. O ADK em si é open-source e roda em qualquer lugar. Mas a plataforma ao redor dele é GCP puro. Essa distinção importa na hora de decidir quanto do stack você abraça.

Spider Chart: ADK em 8 eixos

Como o ADK se posiciona em relação aos critérios que importam? Aqui vai minha avaliação (1-10):

           Facilidade de Início
                  8
                  │
    Debugging ────┼──── Multi-linguagem
        9         │         9
                  │
  Ecossistema ────┼──── Produção/Deploy
      8           │         9
                  │
   Flexibilidade──┼──── Documentação
        7         │         8
                  │
            Comunidade
                6

Score geral: 8.0/10 — Framework enterprise-ready com a melhor experiência de debugging do mercado.

Prós e Contras

Prós

• Multi-linguagem de verdade — Cinco linguagens com paridade de features. Times enterprise com stacks heterogêneos não precisam forçar Python em todo mundo.

• Debugging UI embutida — Não é um add-on pago, não é um SaaS separado. Vem com o framework, funciona com adk web, e mostra tudo que importa.

• A2A + MCP nativos — Os dois protocolos que estão definindo interoperabilidade entre agentes. O ADK suporta ambos como cidadãos de primeira classe.

• Deploy one-click — adk deploy joga direto no Agent Runtime (ex-Vertex AI Agent Engine). Container em Cloud Run ou GKE com Dockerfile gerado.

• Gemini Enterprise Agent Platform — Não é só um framework. É um ecossistema completo: Agent Runtime (infra), Agent Gateway (segurança), Agent Registry (discovery), AutoRaters (qualidade), A2UI (interfaces). Nenhum concorrente oferece esse nível de plataforma integrada.

• Agents CLI — Uma CLI que instala em qualquer coding agent e te dá scaffold, deploy, evaluate, monitor, discover — tudo sem sair do editor. A ponte entre código local e produção enterprise.

• Mesma ferramenta que o Google usa internamente — Não é um projeto experimental. O Agentspace e o Customer Engagement Suite rodam ADK.

• Graph Workflows (ADK 2.0) — Combina fluxo determinístico com raciocínio AI. Padrão que faz sentido para produção onde previsibilidade importa.

• Agentes Long-running nativos — Suporte built-in para agentes que pausam, esperam (dias/semanas), retomam e nunca perdem contexto. Essencial para processos de negócio reais.

• Open-source Apache 2.0 — Sem lock-in na licença. Use, modifique, distribua.

Contras

• Viés para Gemini — Model-agnostic no papel, mas a experiência com modelos Gemini é visivelmente melhor. Integração com Claude/OpenAI funciona, mas não é o happy path.

• Comunidade ainda nascente — LangChain tem anos de vantagem em massa crítica, Stack Overflow answers, e blog posts. Encontrar ajuda para edge cases do ADK pode exigir mergulho no código-fonte.

• Exemplos desbalanceados — Python domina o repositório de samples (~30 agentes). TypeScript, Go e Java têm significativamente menos exemplos.

• Curva de aprendizado — O framework é extenso. Agents, workflows, graphs, sessions, memory, tools, callbacks, plugins, evaluation… A superfície é grande. Vai levar tempo até você se sentir fluente.

• Vertex AI pricing — O framework é grátis, mas o runtime gerenciado cobra por uso. Dependendo do volume, pode pesar no budget.

Quando usar o Google ADK

✅ Use quando:

• Seu time já opera no Google Cloud / Vertex AI
• Você precisa de agentes em múltiplas linguagens (time Python + time Go, por exemplo)
• Debugging e observabilidade são críticos (regulamentação, compliance, auditoria)
• Você quer pipelines multi-agente com comunicação cross-language via A2A
• Precisa de deploy managed com escala automática
• Quer interoperabilidade com MCP servers existentes
• Está construindo sistemas de agentes para enterprise, não protótipos de hackathon

❌ NÃO use quando:

• Você quer um protótipo rápido e não se importa com produção — frameworks mais leves como CrewAI ou o Agents SDK da OpenAI vão te dar velocity maior no início
• Seu time é 100% Python e não precisa de multi-linguagem — LangGraph pode ser suficiente com menos overhead
• Você está fortemente investido em AWS ou Azure — os SDKs nativos (Bedrock AgentCore, Azure AI Foundry) terão integração mais profunda com seus serviços
• Precisa rodar modelos locais como prioridade — O ADK funciona com Ollama/vLLM, mas não é o foco
• Comunidade e ecossistema maduro são mais importantes que features — LangChain ainda ganha nesse quesito

Comparação rápida com alternativas

Próximos passos

Se este guia te convenceu a explorar o ADK, aqui vai um roadmap sugerido:

1. Rode o quickstart — 10 minutos, zero custo. pip install google-adk && adk create. Sinta a ergonomia.

2. Explore o ADK Crash Course — O Google publicou um codelab completo que vai do básico ao expert.

3. Instale o Agents CLI — pip install agents-cli e ganhe superpoderes de scaffold, deploy e evaluate direto do editor. Veja nosso Guia Definitivo: Agents CLI para o setup completo.

4. Construa um multi-agent pipeline — Pegue o exemplo de customer service no repositório google/adk-samples e adapte pro seu domínio. Isso vai te forçar a entender sessions, state, e tools de verdade.

5. Integre um MCP server — Pegue qualquer MCP server público e conecte ao seu agente. Vai te mostrar o poder da interoperabilidade sem esforço.

6. Experimente A2A — Se trabalha com times multi-linguagem, tente o padrão do contract compliance pipeline. Python + Go colaborando via protocolo aberto.

7. Deploy no Agent Runtime — Quando estiver confortável localmente, agents deploy é um comando. Ganhe escala, observabilidade, Agent Gateway e Memory Bank de graça (billing à parte, claro).

8. Explore os 13 codelabs da Agent Platform — O Google liberou 13 codelabs hands-on cobrindo cada componente da Gemini Enterprise Agent Platform. Desde Agent Runtime setup até AutoRaters flywheel, passando por Agent Gateway mTLS, Registry discovery, A2UI components, e padrões long-running. São o melhor caminho para dominar a plataforma completa — cada codelab leva 30-60 minutos e vai do zero ao deploy funcional.

9. Configure AutoRaters — Antes de ir pra produção de verdade, monte seu golden dataset e rode o flywheel de avaliação. agents evaluate --autorater quality-v2 vai te mostrar onde seu agente falha antes que seus usuários descubram.

Recursos oficiais

• Documentação ADK — Referência completa
• ADK Samples — ~30 exemplos em Python, mais em TS/Go/Java
• Google Codelabs ADK — Tutoriais hands-on progressivos
• 13 Codelabs Agent Platform — Codelabs dedicados à Gemini Enterprise Agent Platform (Agent Runtime, Gateway, Registry, AutoRaters, A2UI, Agents CLI, Long-running patterns)
• A2A Protocol — Spec do protocolo agent-to-agent
• Agents CLI Docs — Referência oficial do CLI

Opinião final

O ADK não é o framework mais fácil de aprender. Não é o que tem mais hype no Twitter. Não vai te dar aquele dopamine hit de um agente rodando em 3 linhas de código.

Mas é, provavelmente, o framework mais completo e production-ready que existe hoje para quem quer construir sistemas de agentes sérios. A combinação de multi-linguagem + A2A + MCP + debugging UI + managed runtime não existe em nenhum concorrente com a mesma coesão.

Lembra quando o React parecia overkill perto do jQuery? “Por que preciso de toda essa complexidade?” — e então seu app cresceu e você agradeceu por ter escolhido a ferramenta que escalava. O ADK é essa escolha para agentes.

Só não caia na armadilha de achar que precisa do ADK para tudo. Um chatbot simples não precisa de graph workflows. Um protótipo de hackathon não precisa de A2A cross-language. Use a ferramenta certa para o problema certo.

Mas quando o problema for sério, o ADK está pronto.

Quer receber guias como esse direto no seu inbox? Assine a newsletter em ft.ia.br — análises técnicas sem enrolação, toda semana.