CERC e Google ADK: a lógica por trás da escolha

Por Henrique Souza · Mar 20, 2026

TL;DR — A CERC escolheu o Google ADK como framework central de sua plataforma de agentes de IA porque precisava de três coisas ao mesmo tempo: orquestração explícita, governança compatível com um ambiente regulado e integração nativa com a estratégia da companhia no Google Cloud. Mais do que adotar um framework, a decisão buscou reduzir a distância entre desenvolvimento, deploy, operação e observabilidade. O resultado é uma fundação mais previsível para construir agentes em produção, com padronização arquitetural sem abrir mão de interoperabilidade futura.

Introdução

A decisão não era sobre um framework. Era sobre arquitetura.

Quando se fala em agentes de IA, é comum ver comparações diretas entre Google ADK, LangChain, LangGraph, LangFlow e LangSmith como se todas essas tecnologias disputassem o mesmo espaço.

Na prática, essa visão é simplificada demais.

Essas ferramentas operam em camadas diferentes do stack. Algumas ajudam a compor integrações. Outras estruturam fluxos de execução. Outras apoiam prototipação. Outras oferecem observabilidade, avaliação e tracing. Compará-las como se fossem equivalentes leva a decisões técnicas frágeis e, em ambientes enterprise, isso cobra um preço alto.

Na CERC, esse tipo de simplificação não é suficiente.

Operamos uma infraestrutura financeira crítica, em um ambiente regulado, onde rastreabilidade, previsibilidade e governança não são diferenciais. São requisitos de base. Nesse contexto, a escolha de uma tecnologia para agentes de IA não pode ser guiada apenas por velocidade de experimentação ou preferência de desenvolvedor. Ela precisa responder a exigências reais de compliance, auditabilidade, escala e operação.

Foi nesse contexto que definimos o Google ADK como framework central da nossa plataforma de agentes de IA.

Este artigo apresenta a lógica por trás dessa escolha, o papel da parceria estratégica com o Google Cloud Platform (GCP) e a visão arquitetural que sustenta essa decisão: em produção, a pergunta mais importante não é qual framework parece mais interessante isoladamente, mas qual combinação entre framework e plataforma reduz mais atrito ao longo de todo o ciclo de vida do sistema.

“Em ambientes enterprise, o problema raramente é só construir o agente. O problema é operar o agente com controle.”

O cenário: ferramentas diferentes, responsabilidades diferentes

Antes de explicar a decisão da CERC, vale organizar o cenário de forma objetiva.

Uma plataforma de agentes de IA em produção não depende de uma única tecnologia. Ela depende de um conjunto de capacidades: composição de componentes, controle de fluxo, execução de ferramentas, gestão de estado, observabilidade, avaliação e runtime de produção.

É por isso que essas ferramentas devem ser entendidas por papel arquitetural, não apenas por popularidade.

Google ADK: orquestração explícita para produção

O Agent Development Kit (ADK) do Google é um framework code-first desenhado para construção de sistemas multi-agente com foco em produção.

Seu principal diferencial está na forma como trata a orquestração: ela não fica implícita. Ela é modelada explicitamente em código. Isso significa que a coordenação entre agentes, a ordem de execução, os pontos de paralelismo e a passagem de contexto podem ser lidos, versionados e testados como arquitetura executável.

Em vez de esconder o fluxo em prompts extensos ou em comportamentos difíceis de rastrear, o ADK privilegia estruturas mais previsíveis.

Entre suas capacidades, destacam-se:

Topologias multi-agente
Execução sequencial, paralela e iterativa
Saídas estruturadas
Controle de estado por sessão
Integração com ferramentas externas
Persistência de memória e artefatos
Avaliação contínua
Integração direta com o Vertex AI Agent Engine

Um exemplo simplificado de orquestração em ADK:

from google.adk.agents import SequentialAgent, ParallelAgent, LlmAgent

router_agent = LlmAgent(
    name="RouterAgent",
    instruction="Classifique a solicitação e prepare o contexto inicial.",
    output_key="route_result"
)

analysis_agent = LlmAgent(
    name="AnalysisAgent",
    instruction="Faça a análise da solicitação.",
    output_key="analysis_result"
)

retrieval_agent = LlmAgent(
    name="RetrievalAgent",
    instruction="Recupere informações relevantes.",
    output_key="retrieval_result"
)

computation_agent = LlmAgent(
    name="ComputationAgent",
    instruction="Realize os cálculos necessários.",
    output_key="computation_result"
)

execution_agent = LlmAgent(
    name="ExecutionAgent",
    instruction="Execute a ação planejada.",
    output_key="execution_result"
)

synthesis_agent = LlmAgent(
    name="SynthesisAgent",
    instruction="""
Combine os resultados de:
- Roteamento: {route_result}
- Análise: {analysis_result}
- Recuperação: {retrieval_result}
- Computação: {computation_result}
- Execução: {execution_result}
"""
)

root_agent = SequentialAgent(
    name="MultiAgentWorkflow",
    sub_agents=[
        router_agent,
        ParallelAgent(
            name="ParallelProcessing",
            sub_agents=[
                analysis_agent,
                retrieval_agent,
                computation_agent,
                execution_agent
            ]
        ),
        synthesis_agent
    ]
)

Esse tipo de estrutura torna o fluxo visível. A orquestração deixa de ser uma inferência e passa a ser um artefato arquitetural.

Vale uma observação importante: o determinismo está no fluxo de coordenação, não no raciocínio interno do LLM. Em outras palavras, a ordem de execução pode ser previsível, mesmo que o conteúdo gerado por um agente continue probabilístico. Para produção, essa separação é extremamente útil.

LangChain: o ecossistema de componentes

O LangChain é um dos ecossistemas mais difundidos em aplicações baseadas em LLMs, especialmente por sua vasta coleção de integrações e abstrações reutilizáveis.

Seu papel é muito forte na camada de composição:

Abstrações de modelos
Tool calling
Retrieval
Memória
Templates de prompt
Conectores com bancos, APIs e sistemas corporativos

Exemplo simples:

from langchain_openai import ChatOpenAI
from langchain_core.tools import tool

@tool
def get_weather(city: str) -> str:
    """Fetch current weather for a city."""
    return f"72°F and sunny in {city}"

llm = ChatOpenAI(model="gpt-4o").bind_tools([get_weather])
result = llm.invoke("What's the weather in Tokyo?")

O valor do LangChain está em acelerar exploração, integração e montagem de capacidades.

LangGraph: controle de fluxo com grafos e estado

O LangGraph atua na camada de orquestração dentro do ecossistema LangChain.

Enquanto o LangChain entrega componentes, o LangGraph organiza a execução como grafo com estado, permitindo loops, branching, persistência e retries.

from langgraph.graph import StateGraph, END

workflow = StateGraph(AgentState)

workflow.add_node("research", research_agent)
workflow.add_node("analyze", analysis_agent)
workflow.add_node("decide", decision_node)

workflow.add_edge("research", "analyze")
workflow.add_conditional_edges("analyze", route_decision, {
    "needs_more_research": "research",
    "ready": "decide"
})
workflow.add_edge("decide", END)

app = workflow.compile()

Seu diferencial aparece especialmente quando o fluxo precisa reavaliar etapas, repetir ciclos e decidir caminhos com base em estado.

LangFlow: velocidade para prototipação visual

O LangFlow é uma camada visual voltada à construção de pipelines em formato drag-and-drop.

Ele é útil para aprendizado, ideação, demonstrações e validação rápida de fluxo antes da tradução para código. Seu foco está em acelerar experimentação.

LangSmith: observabilidade e avaliação

O LangSmith resolve outro problema: observabilidade, tracing, testes e avaliação de aplicações com LLM.

Quando um agente retorna uma resposta errada, chama uma ferramenta inadequada ou consulta o trecho incorreto em um fluxo RAG, rastrear o motivo exige instrumentação. O LangSmith ajuda exatamente nisso, com tracing estruturado, datasets de avaliação e monitoramento de regressão.

Por que a CERC escolheu o Google ADK

A escolha do ADK não foi uma comparação isolada de funcionalidades. Foi uma resposta a requisitos concretos da companhia.

1. Orquestração explícita para um ambiente regulado

Em uma infraestrutura financeira regulada, não é suficiente que um agente “funcione”. É necessário entender como ele chegou a determinado comportamento.

Quando um auditor, uma área de risco ou uma área de compliance pergunta por que uma decisão foi tomada, a resposta não pode depender de reconstrução manual de contexto ou interpretação de um fluxo implícito.

O ADK oferece uma vantagem importante nesse cenário: a orquestração é explícita.

Isso permite que o fluxo seja:

Visível no código
Versionado em Git
Testado em CI/CD
Revisado como arquitetura
Auditado com mais clareza

Na prática, um SequentialAgent pode definir a ordem de processamento, um ParallelAgent pode abrir múltiplas frentes de análise simultâneas, e um agente final pode consolidar resultados. Esse desenho não fica escondido. Ele fica formalizado.

Para a CERC, essa clareza importa porque reduz opacidade operacional.

2. Paralelismo para reduzir latência em fluxos reais

Em vários cenários de backoffice, os agentes precisam consultar múltiplas fontes: bases internas, motores de regras, APIs, fontes documentais ou repositórios de apoio à decisão.

Quando isso acontece de forma sequencial, a latência cresce rapidamente.

Nos casos de uso que estamos evoluindo, esse comportamento já apareceu de maneira clara. Em fluxos sequenciais, o tempo total pode ultrapassar facilmente 10 segundos. Com o uso do ParallelAgent do ADK, essas execuções passam a ocorrer de forma concorrente, aproximando a resposta de algo em torno de 3 segundos.

Ainda não estamos usando esse padrão no core transacional da companhia. Mas os resultados em backoffice já mostram por que isso é relevante. Em escala, paralelismo não é apenas otimização. Ele define se a experiência será utilizável ou sujeita a timeout.

3. Isolamento de estado para evitar contaminação entre requisições

Em sistemas agênticos, vazamento de estado entre requisições é um risco sério.

Quando contexto, memória ou artefatos de uma execução contaminam outra, o sistema pode produzir respostas incorretas ou até acionar ferramentas com base em premissas erradas. Em ambientes críticos, isso é inaceitável.

O ADK favorece isolamento por execução por meio de seu modelo de instanciação e gestão de sessão. Isso ajuda a reduzir o risco de contaminação entre requisições e melhora a previsibilidade operacional do sistema.

4. Alinhamento com a estratégia da CERC no Google Cloud

A escolha do ADK também foi estratégica.

A CERC já opera parte relevante de sua infraestrutura no Google Cloud Platform. Adotar o ADK como núcleo da camada de agentes aproxima essa nova capacidade do ecossistema onde a companhia já opera dados, segurança, identidade, observabilidade e runtime.

Essa convergência tem impacto direto na operação.

Com o Vertex AI Agent Engine, o deploy e a execução dos agentes passam a acontecer dentro de uma plataforma gerenciada, integrada com os mecanismos do Google Cloud. Isso reduz a necessidade de construir do zero uma camada própria de runtime, escalabilidade, sessões e observabilidade para agentes.

Em outras palavras: a decisão reduz complexidade de plataforma.

5. Padronização sem fechar portas

Um ponto importante da decisão é que escolher ADK não significa assumir que um único framework resolve tudo ou que a arquitetura da CERC está fechada ao restante do ecossistema.

Pelo contrário.

Nossa decisão foi padronizar em ADK para produção, sem perder a visão de que diferentes ferramentas podem coexistir em outras camadas do stack ou em cenários futuros de interoperabilidade.

Isso dá à companhia um equilíbrio importante entre governança e flexibilidade.

O papel do Vertex AI Agent Engine

Uma distinção arquitetural importante precisa ser feita aqui.

O Vertex AI Agent Engine é a camada de runtime gerenciado da plataforma. Já o ADK é o framework de orquestração que escolhemos como padrão produtivo.

Essas duas decisões são complementares, mas não idênticas.

Na CERC, a separação é clara:

Plataforma: Vertex AI
Framework padrão de produção: Google ADK

Essa distinção é importante porque evita uma confusão comum em projetos de IA: assumir que a escolha do runtime deve automaticamente definir toda a arquitetura de desenvolvimento. Não precisa ser assim.

O que decidimos foi usar o ADK como núcleo de orquestração e o Vertex AI como a camada que complementa a operação, incluindo runtime, avaliação, observabilidade e integração com o ecossistema do Google Cloud.

Camada	Tecnologia	Papel na CERC
Orquestração & Execução	Google ADK	Topologia multi-agente, paralelismo, controle de fluxo e execução de tools
Retrieval (RAG)	ADK + Tools	Integração com Vertex AI Search e APIs externas
Memória & Estado	ADK Session State	Persistência entre agentes e sessões
Observabilidade	Vertex AI + Logging padrão	Tracing, métricas e debugging
Avaliação	Vertex AI Evaluation	Testes automatizados e qualidade
Deploy & Runtime	Vertex AI Agent Engine	Infraestrutura gerenciada e escala

Essa composição reflete uma visão objetiva: nenhuma ferramenta isolada resolve com excelência todas as necessidades de um sistema agêntico enterprise. O que resolve é uma arquitetura em que cada camada assume um papel claro.

A parceria estratégica com o Google Cloud

A escolha do ADK está diretamente conectada ao alinhamento da CERC com o Google Cloud. Mas vale deixar isso claro da forma certa: não se trata de dependência automática. Trata-se de coerência arquitetural.

Infraestrutura unificada

Quando bancos como BigQuery e Cloud SQL, serviços como Cloud Run, armazenamento em Cloud Storage e a camada de agentes operam dentro do mesmo ecossistema, a operação tende a ficar mais consistente.

Essa convergência traz ganhos práticos:

Modelo único de identidade com IAM
Controles de segurança alinhados
Telemetria mais consistente
Operação com SLAs enterprise
Menor fricção de governança e compliance

Em um ambiente regulado, reduzir fragmentação operacional tem valor arquitetural real.

Vertex AI como plataforma de ciclo de vida

O valor do Google Cloud não está apenas em executar agentes.

O Vertex AI também amplia a capacidade de evoluir a plataforma ao longo do tempo, com recursos como:

Model Garden para escolha de modelos
Vertex AI Search para grounding e RAG
Evaluation Pipelines para validação contínua
Example Store para evolução orientada por uso real
Agentspace para descoberta e organização de agentes

Isso faz diferença porque a discussão deixa de ser “como rodo um agente?” e passa a ser “como opero e evoluo uma plataforma de agentes com menos atrito?”.

Interoperabilidade com A2A

Outro ponto estratégico é a interoperabilidade.

O protocolo A2A (Agent-to-Agent) reforça uma visão mais aberta de ecossistema, permitindo que agentes de diferentes origens possam se comunicar de forma padronizada.

Isso não muda o fato de que, hoje, a decisão da CERC é padronizar em ADK para produção. Mas mostra que essa padronização não precisa significar isolamento arquitetural no futuro.

O que essa escolha entrega para a CERC

No fim, a decisão pelo ADK entrega algo mais importante do que uma preferência tecnológica.

Ela reduz a distância entre:

Arquitetura
Desenvolvimento
Deploy
Operação
Governança

Essa redução de fricção é um dos principais objetivos de qualquer plataforma enterprise.

Na prática, isso significa:

Fluxos mais explícitos
Comportamento mais previsível
Maior clareza para auditoria e compliance
Menor complexidade operacional
Uma base mais coerente para escalar agentes em produção

Esse é o ponto central da decisão.

Conclusão

A CERC não escolheu o Google ADK porque acredita que o futuro dos agentes de IA será dominado por um único framework.

Escolheu porque, no contexto atual da companhia, ele oferece uma combinação particularmente forte entre:

Controle de orquestração
Clareza arquitetural
Suporte a paralelismo
Isolamento de estado
Integração com a estratégia no Google Cloud
Menor fricção entre engenharia e operação

Em ambientes enterprise, vantagem competitiva raramente vem da ferramenta mais chamativa em laboratório. Ela vem da capacidade de transformar tecnologia em operação previsível, governável e sustentável.

Foi isso que orientou a nossa decisão.

Insight estratégico Em ambientes enterprise, a melhor escolha não é a que promete mais features isoladas. É a que reduz mais atrito entre desenvolvimento, deploy, operação e governança.

“O futuro dos agentes de IA não está apenas em modelos mais inteligentes. Está em engenharia mais madura.”

Referências

Em um ambiente financeiro regulado, construir agentes de IA exige mais do que prototipar rápido. Exige arquitetura, controle e capacidade real de operação em escala.