LangChain, LangGraph, ADK, A2A, CrewAI e Agno: como eu escolho entre eles

Antes de qualquer comparação, uma distinção que costuma ser ignorada e que evita boa parte da confusão neste mercado:

• LangChain, LangGraph, ADK, CrewAI e Agno ajudam a construir agentes.
• A2A não constrói agente nenhum. É um protocolo para agentes independentes conversarem entre si.
• LangChain e LangGraph não competem. LangChain entrega componentes e abstrações (modelos, tools, RAG). LangGraph controla execução, estado e workflow. Uso os dois juntos na maioria dos meus projetos corporativos.

Resumo executivo

Se eu precisasse resumir minha régua de decisão em uma frase por ferramenta:

LangGraph com LangChain para sistemas corporativos que não podem errar. ADK quando o cliente já vive dentro do Google Cloud. CrewAI quando o valor está na colaboração autônoma entre papéis. Agno quando o objetivo é sair do zero para uma plataforma própria o mais rápido possível. A2A quando dois agentes precisam conversar sem morar no mesmo processo.

1.LangChain

LangChain é um SDK de alto nível para montar aplicações com LLMs. Ele padroniza modelos de diferentes fornecedores, tool calling, prompts e mensagens, middleware, RAG, retrievers, vector stores e structured output.

Um ponto que costuma passar despercebido: na arquitetura atual, o create_agent do LangChain funciona como um agent harness (modelo, ferramentas, instruções e middleware montados sobre o LangGraph). Isso significa que, mesmo usando só o LangChain, você já está indiretamente se apoiando em persistência e human-in-the-loop do LangGraph por baixo do capô ([Docs by LangChain][1]).

Uso LangChain quando o ciclo do agente é relativamente simples: chatbots corporativos, RAG sobre documentos, agentes SQL, assistentes com ferramentas, integração com vários provedores de modelo, provas de conceito.

Usuário
   ↓
API FastAPI
   ↓
LangChain Agent
   ├── Modelo
   ├── Retriever
   ├── API interna
   └── Ferramenta SQL

Um erro que vejo com frequência em times que estão começando: deixar o agente acessar dezenas de tabelas diretamente ou executar regra de negócio crítica sem passar por uma camada de domínio. Eu trato o LangChain como camada de integração e composição, nunca como substituto da arquitetura da aplicação. As tools do agente deveriam chamar serviços bem definidos, não o banco de dados cru:

Agent
 ├── consultar_cliente()
 ├── buscar_politica()
 ├── consultar_transacao()
 └── abrir_solicitacao()

Infraestrutura

Para aplicação simples, meu stack padrão é FastAPI ou Node.js, Docker, Cloud Run, ECS Fargate, Azure Container Apps ou Railway, PostgreSQL, pgvector ou Qdrant, Redis quando faz sentido e LangSmith ou OpenTelemetry para observabilidade.

Em escala média, o desenho vira:

Load Balancer
      ↓
FastAPI replicas
      ↓
LangChain Agents
 ├── PostgreSQL
 ├── Redis
 ├── Vector DB
 └── APIs internas

Não uso LangChain sozinho quando o workflow tem muitas etapas, dura minutos ou horas, exige aprovação humana, retry por etapa, compensação, retomada após falha, estado complexo ou auditoria completa. Nesse ponto, entra o LangGraph.

2.LangGraph

LangGraph é o meu framework preferido para workflows e agentes stateful construídos como grafo: estado, nós, arestas, condições, loops, subgrafos, checkpoints, interrupções e retomada de execução ficam explícitos no código, não escondidos dentro de um agente autônomo.

Ele mistura etapas determinísticas com etapas controladas por LLM e entrega persistência, execução durável, streaming e human-in-the-loop nativamente ([Docs by LangChain][2]).

START
  ↓
Validar solicitação
  ↓
Buscar dados
  ↓
Agente analista
  ↓
Confiança suficiente?
  ├── Sim → Executar próximo passo
  └── Não → Revisão humana
                 ↓
               Retomar
                 ↓
                END

É a minha recomendação padrão para antifraude, crédito, compliance, recrutamento com etapas e aprovações, atendimento com escalonamento humano, investigações, processamento de documentos e qualquer processo regulado que precise sobreviver a um reinício ou uma falha.

O estado precisa ser tipado e conter só o que importa:

class RiskState(TypedDict):
    transaction_id: str
    rule_score: float
    ai_score: float | None
    evidence: list[str]
    decision: str | None
    human_review: bool

A prática que eu cobro de qualquer equipe que trabalha comigo: deixar explícito onde a IA pode sugerir, onde ela pode escolher caminho e onde a regra determinística prevalece sem exceção.

Infraestrutura

API Gateway
      ↓
Agent Server / LangGraph
      ↓
PostgreSQL Checkpointer
      ↓
Redis / fila
      ↓
Workers

Kubernetes, ECS ou VMs em container, PostgreSQL para checkpoints e threads, Redis para fila e coordenação, Kafka ou SQS ou Pub/Sub para eventos de domínio, object storage para documentos, Qdrant ou pgvector para RAG, OpenTelemetry e LangSmith para trace.

Vale registrar: a documentação do LangSmith Deployment recomenda Kubernetes para produção standalone e alerta explicitamente que servidores LangGraph de execução longa não deveriam depender de ambientes serverless com scale-to-zero, porque isso pode interromper tarefas em andamento e comprometer a retomada ([Docs by LangChain][3]). Já vi essa decisão de infraestrutura ser tomada errado por economia de custo e virar incidente em produção.

O ponto forte do LangGraph é o controle explícito da execução. O ponto fraco é que ele exige mais engenharia: modelagem de estado, tratamento de erro, idempotência, checkpoint, versionamento de grafo, migração de estado, estratégia de retry. Ele não esconde a complexidade do seu sistema. Ele te dá as ferramentas para controlá-la, o que é diferente de fingir que ela não existe.

3.Google ADK

O Agent Development Kit é o framework open source do Google para agentes de produção, com suporte a Python, TypeScript, Go, Java e Kotlin. Ele reúne agentes, ferramentas, workflows em grafo, sistemas multiagente, sessões, memória, artefatos, avaliação e deployment em um pacote só ([Google GitHub][4]).

Um detalhe que costuma surpreender quem assume que ADK é "só para Gemini": o framework oferece suporte ou adaptador para outros modelos, incluindo Claude, Ollama, vLLM e LiteLLM. A integração operacional mais forte continua sendo dentro do ecossistema Google Cloud, mas a dependência de modelo não é absoluta ([Google GitHub][4]).

Recomendo ADK quando a empresa já está no Google Cloud, Gemini ou Vertex AI são os modelos principais, existe equipe poliglota, o projeto vai usar Cloud Run, GKE ou Agent Runtime, e é preciso integrar A2A e MCP nativamente.

Aplicação
   ↓
ADK Agent
   ├── Tools
   ├── Agent Team
   ├── Graph Workflow
   ├── Session Service
   ├── Memory Service
   ├── MCP
   └── A2A

O ADK separa quatro conceitos que eu considero fundamentais para qualquer arquitetura de agente, independente do framework: session é a conversa atual, state é o dado temporário daquela sessão, memory é o conhecimento pesquisável entre sessões, e events é o histórico de mensagens e ações. As implementações in-memory servem para desenvolvimento; em produção precisam virar armazenamento persistente ou serviço gerenciado ([Google GitHub][5]).

Infraestrutura

O Agent Runtime é o serviço gerenciado do Google Cloud voltado especificamente para execução e escalabilidade de agentes, com autoscaling, sessão gerenciada, identidade de agente e observabilidade integrada ([Google GitHub][6]). Faz sentido quando o projeto é totalmente Google Cloud e você quer o menor esforço operacional possível.

Cloud Run é minha escolha para APIs simples, agentes stateless ou com estado externo, carga variável, execuções curtas, MVPs e webhooks.

GKE entra quando o agente é long-running, usa modelo open source, precisa de vLLM ou GPU, service mesh, rede privada complexa ou alta personalização.

Entre LangGraph e ADK, minha régua é direta: escolho LangGraph quando a aplicação precisa ser cloud-agnostic, o grafo e o estado são o centro do sistema, a equipe é Python ou TypeScript e há necessidade forte de controle customizado. Escolho ADK quando Google Cloud já é a plataforma estratégica do cliente, existe time distribuído em Go, Java, Kotlin, Python e TypeScript, e Agent Runtime, Vertex AI e IAM já fazem parte da conversa.

4.A2A

A2A significa Agent2Agent Protocol. Não é framework, é protocolo aberto para comunicação entre agentes independentes, mesmo que construídos com frameworks e linguagens diferentes.

Ele define Agent Card, skills e capabilities, messages, tasks, estados da task, context ID, streaming, autenticação e troca de arquivo e dado estruturado, permitindo que agentes colaborem sem expor memória interna, ferramentas ou lógica proprietária ([A2A Protocol][7]).

A analogia que eu uso em sala de aula:

MCP:
Agente → ferramenta, API, banco ou recurso

A2A:
Agente → outro agente

São complementares, não concorrentes ([A2A Protocol][8]).

Uso A2A quando existe fronteira real: agentes de departamentos diferentes, de empresas diferentes, hospedados em nuvens diferentes, construídos com frameworks diferentes, marketplace de agentes, comunicação B2B, ou um agente corporativo consumindo um agente de fornecedor.

Agente de Atendimento
          ↓ A2A
Agente de Financeiro
          ↓ A2A
Agente Antifraude
          ↓ A2A
Agente de Compliance

Nada impede que o antifraude seja LangGraph, o financeiro seja ADK e o atendimento seja Agno. O A2A é o contrato de comunicação entre eles, não a implementação de nenhum.

O que eu não faço: usar A2A para comunicação entre subagentes que vivem no mesmo processo, no mesmo workflow, no mesmo repositório, sob a mesma transação, com acesso direto ao mesmo estado. Nesse caso as primitivas nativas do LangGraph, ADK, CrewAI ou Agno resolvem com muito menos overhead.

Infraestrutura

API Gateway
      ↓
A2A Client
      ↓
A2A Server
      ├── Agent Card
      ├── Task Store
      ├── Streaming
      ├── Authentication
      └── Agent Runtime

Trato A2A como arquitetura de serviços distribuídos de verdade: um serviço por agente ou domínio, Kubernetes, ECS, Cloud Run ou Agent Runtime, API Gateway, OAuth2/OIDC, mTLS em comunicação sensível, service mesh em Kubernetes, PostgreSQL para estado das tasks, Kafka ou Pub/Sub ou SQS para processamento assíncrono, SSE ou webhook para atualização, OpenTelemetry com correlation ID e task ID, rate limiting, circuit breaker e idempotency key.

O A2A não resolve deployment, banco, fila nem observabilidade. Ele padroniza só a comunicação. Tudo o resto continua sendo trabalho de engenharia normal.

5.CrewAI

CrewAI orquestra multiagentes em torno de dois conceitos: crews, que são grupos de agentes especializados, e flows, que são workflows estruturados controlando estado, evento, branch e execução. Uma crew pode ter pesquisador, analista, revisor e redator; o flow decide quando essa equipe é chamada e o que acontece com o resultado dela ([CrewAI Documentation][9]).

Funciona muito bem para deep research, produção de relatório, análise de mercado, marketing, criação e revisão de conteúdo, prospecção, automação operacional, processamento de documentos e equipes virtuais de especialista.

Flow
  ↓
Crew de Pesquisa
  ├── Pesquisador
  ├── Analista
  └── Revisor
  ↓
Validar resultado
  ↓
Crew de Redação
  ├── Redator
  └── Editor

Minha regra com CrewAI: nunca coloco a aplicação inteira dentro de uma crew autônoma. O flow controla estado, condição, aprovação, tratamento de erro, persistência, entrada e saída, e chamada às crews. A crew fica só com a parte que realmente ganha com colaboração criativa entre agentes.

Flow determinístico
      ↓
Crew autônoma
      ↓
Structured output
      ↓
Validação
      ↓
Próxima etapa

Infraestrutura

Em pequena escala: Docker, FastAPI, PostgreSQL, Redis ou fila, Cloud Run, Railway ou ECS, object storage e vector DB opcional.

Em produção:

API
 ↓
Flow Runtime
 ↓
Job Queue
 ↓
Crew Workers
 ├── Model APIs
 ├── Tools
 ├── Vector DB
 └── PostgreSQL

Para alta concorrência, separo workers da API, uso fila durável, limito concorrência por modelo, garanto retry por tarefa e controlo custo e token de perto, com observabilidade por agente e por task. Vale mencionar que o CrewAI também tem uma camada empresarial com deployment, trigger, ambiente, observabilidade e RBAC prontos ([CrewAI Documentation][9]).

Onde eu tenho cautela: nunca uso CrewAI como núcleo direto de autorização financeira, antifraude transacional em tempo real, decisão jurídica ou atualização irreversível. Ele pode participar da análise, mas cercado por validação e dentro de um flow determinístico. Decisão que não pode ser desfeita não fica na mão de um agente autônomo colaborando livremente com outro.

6.Agno

Agno é um SDK Python para construir plataforma de agentes, com três primitivas: agent, team e workflow. O diferencial é o AgentOS, que transforma agentes, equipes e workflows em uma aplicação FastAPI completa, com API, persistência, autenticação, tracing, execução em background e agendamento prontos ([Agno][10]).

Faz sentido quando o objetivo é criar plataforma interna de agentes, expor vários agentes como API, construir SaaS de agentes, multi-tenancy, agente com memória e conhecimento, equipe de agentes, workflow operacional, integração com Slack ou WhatsApp, e o projeto precisa chegar rápido a uma estrutura de plataforma.

AgentOS / FastAPI
       ├── Agent
       ├── Team
       ├── Workflow
       ├── Auth
       ├── Sessions
       ├── Memory
       ├── Tracing
       ├── Scheduler
       └── REST/MCP
              ↓
           PostgreSQL

Comparado ao LangGraph, o Agno é mais opinativo sobre runtime e plataforma. Comparado ao CrewAI, oferece uma visão de plataforma mais ampla, não só colaboração entre agentes.

Infraestrutura

A própria documentação do Agno descreve o AgentOS como uma aplicação FastAPI que precisa basicamente de container, PostgreSQL, hostname público, HTTPS, variável de ambiente e JWT em produção. O estado fica no banco, o que permite escalar as instâncias da API horizontalmente sem drama ([Agno][11]).

Para MVP: Docker Compose, AgentOS, PostgreSQL com pgvector, Railway, Render ou VPS.

Para produção média: Cloud Run, ECS Fargate ou Azure Container Apps, Cloud SQL, RDS ou Azure Database for PostgreSQL, load balancer, secret manager e OpenTelemetry.

Para grande escala: Kubernetes com Helm, PostgreSQL gerenciado, réplica horizontal, ingress, JWT/OIDC, banco separado para trace e uma estratégia de liderança para o scheduler. Vale atenção aqui: o scheduler do AgentOS pode precisar de uma única instância líder para não duplicar execução, então em alta disponibilidade é preciso leader election ou réplica dedicada ao agendamento ([Agno][11]).

O ponto forte do Agno é a velocidade: é uma das rotas mais rápidas de "agente em Python" para "plataforma de agentes com API". O ponto de atenção é que a arquitetura de plataforma dele é bem opinativa. Se o projeto já tem runtime, autenticação, fila, scheduler e observabilidade próprios, parte do que o Agno entrega vira redundância.

Comparativo prático

Onde eu aplico cada um

Chatbot ou RAG corporativo. LangChain puro, subindo para LangGraph só se surgir aprovação, branch complexo ou processo longo.

FastAPI
  ↓
LangChain
  ↓
PostgreSQL + pgvector

Antifraude, crédito ou compliance. LangGraph com LangChain por baixo, sempre com decisão determinística fora do agente.

Kafka
  ↓
LangGraph
  ├── Regras determinísticas
  ├── Consulta de features
  ├── Modelo ML
  ├── Agente de análise
  ├── RAG de políticas
  └── Revisão humana
         ↓
PostgreSQL Checkpoint

A IA recomenda e produz evidência. O decision engine determinístico é quem decide.

Plataforma inteiramente Google Cloud. ADK, com Cloud Run para agente simples e Agent Runtime para a experiência gerenciada.

Pesquisa e produção automática de relatório. CrewAI, com flow determinístico controlando as crews de pesquisa, análise e redação até a validação humana.

Plataforma SaaS com vários agentes. Agno quando o valor é entregar API, autenticação, sessão, memória, tracing e agendamento rápido. LangGraph quando a diferenciação do produto está no workflow e na máquina de estados customizada.

Agentes de empresas ou domínios diferentes. Qualquer framework internamente, A2A na fronteira entre os serviços.

LangGraph Agent
      ↓ A2A
ADK Agent
      ↓ A2A
Agno Agent

A base que eu adoto nos meus projetos

Para os cenários que mais atravessam a minha mesa (sistema de atendimento com IA, antifraude, gateway de pagamento e plataforma corporativa), a base que eu monto é essa:

FastAPI / APIs de domínio
          ↓
LangGraph
          ├── LangChain para modelos, tools e RAG
          ├── Decision Engine determinístico
          ├── Human-in-the-loop
          ├── Guardrails
          └── Subgrafos especializados
                    ↓
PostgreSQL + Redis + Kafka + Qdrant/pgvector
                    ↓
OpenTelemetry + LangSmith

No gateway de pagamento e no antifraude, LangGraph cuida de investigação, análise e montagem de dossiê, LangChain entra para modelo, retriever, structured output e tool, Kafka carrega os eventos entre gateway, antifraude e IA, A2A só aparece quando cada agente vira serviço independente ou pertence a outro domínio, e o decision engine fica sempre fora do agente, totalmente determinístico.

Em plataformas de atendimento com múltiplos agentes, LangGraph com LangChain segue sendo o equilíbrio que prefiro entre controle, memória, canal e multi-tenancy. Agno entra como alternativa quando o objetivo é acelerar uma plataforma padronizada de agentes. ADK vira a opção natural quando o cliente já está em Google Cloud e Vertex AI. CrewAI encaixa bem em módulos de pesquisa, planejamento ou relatório, não como núcleo do sistema inteiro.

Em pipeline de recrutamento, LangChain resolve triagem, busca semântica e assistente. LangGraph cuida do pipeline de seleção, entrevista, aprovação e retomada. CrewAI entra para hunting e pesquisa de candidato com agentes especializados. Agno faz sentido se a ideia é oferecer vários agentes de RH por cliente dentro de uma plataforma única.

Veredito

Não existe vencedor único, mas se eu tivesse que ordenar por peso na minha arquitetura padrão:

1. LangGraph para controle e orquestração de sistemas críticos.
2. LangChain para ecossistema de componentes e integração.
3. ADK para quando Google Cloud é a plataforma estratégica.
4. Agno para construir rápido uma plataforma própria de agentes.
5. CrewAI para equipes autônomas de pesquisa e produção de conteúdo.
6. A2A como padrão de interoperabilidade entre agentes independentes.

Para o meu perfil técnico e para a maioria dos sistemas corporativos que eu desenho, a combinação mais forte continua sendo LangGraph como motor de orquestração, LangChain como camada de integração, e A2A nas fronteiras entre serviços. ADK entra como alternativa estratégica para cliente Google Cloud, Agno para acelerar produto SaaS de agentes, e CrewAI para workflow de pesquisa e automação que não precisa de rastreabilidade transacional.

• https://docs.langchain.com/oss/python/langchain/overview "LangChain overview - Docs by LangChain"
• https://docs.langchain.com/oss/python/langgraph/overview "LangGraph overview - Docs by LangChain"
• https://docs.langchain.com/langsmith/deployment "LangSmith Deployment - Docs by LangChain"
• https://google.github.io/adk-docs/ "Agent Development Kit (ADK) - Agent Development Kit (ADK)"
• https://google.github.io/adk-docs/sessions/ "Conversational Context: Session, State, and Memory - Agent Development Kit (ADK)"
• https://google.github.io/adk-docs/deploy/ "Deploying Your Agent - Agent Development Kit (ADK)"
• https://a2a-protocol.org/latest/specification/ "Overview - A2A Protocol"
• https://a2a-protocol.org/ "A2A Protocol"
• https://docs.crewai.com/ "CrewAI Documentation - CrewAI"
• https://docs.agno.com/sdk/introduction "Agno SDK - Agno"
• https://docs.agno.com/features/deploy "Deploying - Agno"