LangGraph vs CrewAI: Qual Framework Sobrevive ao Seu Time em Produção

No começo do mês precisei voltar a um repositório que ninguém do time mexia desde o ano passado: um serviço multiagente escrito às pressas para validar uma hipótese e que, contra todo prognóstico, continuou de pé. A tarefa era pequena, encaixar uma etapa de validação no meio do fluxo. Levei três horas só para descobrir onde ela entrava. O código não estava mal escrito. É que ninguém, nem quem escreveu, sabia dizer com precisão qual informação chegava em cada etapa.

Quando aquele serviço tinha três semanas de vida, isso não era problema: a gente estava descobrindo se a ideia funcionava, e velocidade valia mais que clareza. Quase um ano depois, virou o custo fixo de qualquer alteração. E o que me incomodou não foi a dívida em si, foi perceber quão pouco do material disponível ajuda alguém a evitá-la. Comparação de feature, contagem de estrela no GitHub, frase de efeito sobre qual framework é "melhor". Nenhum desses critérios sobrevive ao primeiro incidente de produção, muito menos ao décimo mês de manutenção. Estrela no GitHub não te conta quem paga a conta quando o worker reinicia no passo sete de doze.

Passei alguns dias lendo changelog dos dois, documentação oficial e comparações mais sérias, e cheguei numa conclusão que me parece mais útil que eleger um vencedor: os dois frameworks divergiram de propósito. Não estão competindo pela mesma vaga. LangGraph virou um runtime de orquestração de baixo nível, onde você é dono do loop, do schema de estado e de cada aresta do grafo. CrewAI virou o caminho mais curto entre "temos uma ideia" e "tem um multiagente rodando", com um custo de token mensurável em cima.

Neste post vou abrir as duas filosofias, comparar os dois nos critérios que importam quando a coisa sai do notebook, mostrar o que mudou nas versões recentes de cada um, propor um critério de decisão por estágio do time em vez de por hype, e terminar com o custo real de migrar de um para o outro. Não vou eleger um vencedor absoluto, porque não acho que exista.

Duas Filosofias Que Divergiram De Propósito

LangGraph se descreve como um framework de orquestração de baixo nível e um runtime para agentes stateful de longa duração. A abstração central é um grafo cujos nós leem e atualizam um estado tipado. Nós são funções, arestas são transições, e o estado é versionado em checkpoint a cada passo. A inspiração declarada vem de Pregel e Apache Beam, o que já diz muito sobre o tipo de desenvolvedor para quem foi desenhado.

Essa escolha tem uma consequência direta: LangGraph não tenta esconder decisão de arquitetura de você. Ele te obriga a decidir como o estado flui, quando ramificar, quando fazer loop, quando parar e esperar aprovação humana. É a diferença entre uma caixa de Lego e um robô montado. Se "máquina de estados explícita" soa animador, esse é o seu framework. Se soa exaustivo, isso também é informação sobre o seu time.

CrewAI parte de outro lugar. A abstração central é a metáfora do time: você define agentes com papel, objetivo e história de fundo, agrupa em uma crew e distribui tarefas entre eles, com processo sequencial ou hierárquico. A tradução conceitual é quase mecânica: agente vira nó, tarefa vira aresta mais trabalho, crew vira grafo compilado, papel e história de fundo viram prompt de sistema. A diferença não está no que dá para expressar, está em quem escreve a orquestração.

E aí mora o ponto que me parece mais honesto de toda a comparação: CrewAI pensa em agentes e papéis, LangGraph pensa em transições de estado. Quando você para de perguntar "qual agente faz isso" e passa a perguntar "que mudança de estado isso produz", já mudou de framework mentalmente antes de mudar de dependência. É a mesma mudança de eixo que discuti em topologias de agente e a lei de Conway: a forma do sistema acompanha a forma de como o time pensa o problema, não o contrário.

Vale registrar a escala de cada um, porque ela também informa a decisão. CrewAI passou de 52 mil estrelas no GitHub e reportou cerca de 2 bilhões de execuções de agente nos doze meses anteriores a maio de 2026. LangGraph está na casa das 38 mil estrelas, mas lidera com folga em downloads mensais no PyPI, com 34,5 milhões contra 5,2 milhões do CrewAI em abril de 2026, segundo levantamento do TokenMix. Leitura possível: CrewAI lidera a atenção de quem está prototipando, LangGraph lidera a adoção de quem está rodando.

O Que Cada Um Cobra De Você Na Primeira Semana

A forma mais rápida de sentir a diferença é olhar o código mínimo de cada um. No CrewAI, um agente é uma declaração quase em linguagem natural:

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role="Senior Research Analyst",
    goal="Uncover comprehensive info on {topic}",
    backstory="20 years in market research, known for thoroughness.",
    tools=[search_tool, scrape_tool],
    llm=openai_llm,
)

crew = Crew(
    agents=[researcher, writer, editor],
    tasks=[research_task, write_task, edit_task],
    process=Process.sequential,
)

Não existe schema de estado, não existe aresta, não existe decisão sobre o que cada etapa lê. Você descreve pessoas fictícias e a ordem em que elas trabalham. Para um pipeline de pesquisa e escrita, isso cabe em menos de cem linhas de Python e roda. Esse é o argumento inteiro do CrewAI, e ele é um bom argumento.

No LangGraph o mesmo fluxo exige que você diga antes o que é o estado e como ele muda:

from langgraph.graph import StateGraph, START, END
from langgraph.types import RetryPolicy, TimeoutPolicy

graph = StateGraph(ResearchState)

graph.add_node(
    "research",
    research_node,
    retry_policy=RetryPolicy(max_attempts=3, backoff_factor=2.0),
    timeout=TimeoutPolicy(run_timeout=120, idle_timeout=30),
    error_handler=handle_research_failure,
)
graph.add_node("write", write_node)
graph.add_node("edit", edit_node)

graph.add_edge(START, "research")
graph.add_edge("research", "write")
graph.add_conditional_edges("edit", route_after_review, {"write": "write", END: END})

compiled = graph.compile(checkpointer=checkpointer)

Repare no que apareceu de graça no segundo exemplo e não existe no primeiro: política de retentativa por nó, teto de tempo por tentativa, função de recuperação quando as retentativas acabam, uma aresta condicional que devolve o texto para o escritor se o editor reprovou, e um checkpointer que permite retomar tudo isso depois de um restart. Nada disso é gratuito no CrewAI, e nada disso é opcional em produção.

O outro lado da moeda é que o exemplo do LangGraph pressupõe um ResearchState que você desenhou antes, campo por campo, decidindo quais são opcionais, quais acumulam e qual redutor cada um usa. Esse é o passo que determina a qualidade de qualquer implementação em LangGraph, e é também o passo que trava times que nunca construíram um motor de workflow. A curva de aprendizado do grafo é real e não some com boa documentação.

A Comparação Que Importa Em Produção

Feature matrix costuma comparar o que é fácil de comparar. Prefiro comparar o que quebra. A tabela abaixo é o resumo do que os dois entregam nas dimensões que aparecem no primeiro incidente sério.

A linha que eu destacaria é a de estado, porque ela contamina todas as outras. Vale separar quatro coisas que costumam ser tratadas como uma só: o estado da thread, o estado de workflow com os identificadores de transação externa, a memória de longo prazo com sua própria política de exclusão, e os eventos de auditoria. Um framework pode te dar um desses e deixar os outros três por sua conta, e a maior parte das comparações finge que são a mesma coisa.

A segunda linha que merece atenção é observabilidade, e não por vaidade de dashboard. Quando um agente de cinco passos erra, o que você precisa reconstruir é qual modelo foi chamado, com qual contexto, qual ferramenta respondeu o quê e qual transição de estado veio depois. LangGraph entrega isso pelo LangSmith com pouco esforço. CrewAI tem tracing próprio e integração OpenTelemetry, mas a abstração de papéis torna mais difícil responder por que o agente A delegou para o agente B. Já defendi antes que observabilidade de stack agêntico é decisão de arquitetura e não de ferramenta, e essa comparação reforça o ponto.

Há uma armadilha comum aqui que vale nomear: nenhum dos dois resolve autorização. Delegação, handoff, subagente ou gerente, o nome muda e o problema continua o mesmo. O componente que recebe a tarefa precisa receber capacidades reduzidas e contexto com escopo, não as credenciais ambientes do pai e a transcrição inteira. Papel e história de fundo não são modelo de permissão, e aresta de grafo também não é.

Portabilidade de modelo também merece nuance. Os dois são agnósticos no papel. Na prática, LangGraph deixa você escolher o modelo por nó, o que torna trivial rodar classificação num modelo barato e síntese num modelo de fronteira dentro do mesmo fluxo. No CrewAI, o LLM é propriedade do agente e não da tarefa, então esse mesmo padrão é possível, porém desconfortável. Para quem está olhando conta de inferência com atenção, essa diferença é maior do que parece na tabela.

O Que Mudou Nas Versões Recentes De Cada Um

Do lado do LangGraph, a linha 1.1 trouxe templates de deep agents e suporte a runtime distribuído no CLI, segundo o levantamento do Softmax Data atualizado em março de 2026. Isso importa porque encurta o caminho entre grafo local e execução distribuída sem que você tenha que escrever o plano de controle do zero. O padrão de planejamento hierárquico que esses templates encapsulam é o mesmo que destrinchei em deep agents e planejamento hierárquico no LangGraph.

Depois disso veio a linha 1.2, cuja primeira alpha saiu em 4 de maio de 2026, e ela é a mais relevante para quem opera. Chegaram timeouts por nó, com limite de relógio (run_timeout) e limite de ociosidade que reseta a cada sinal de progresso (idle_timeout), o que resolve o caso do nó que streama por muito tempo mas continua vivo. Chegaram handlers de erro por nó, que rodam depois que as retentativas se esgotam e recebem um NodeError tipado, permitindo padrão SAGA de compensação sem abortar o grafo. Chegou o DeltaChannel, um tipo de canal que grava só o delta incremental de cada passo em vez de re-serializar o valor acumulado inteiro, o que corta o custo de checkpoint em threads longas. E chegou uma API de streaming v3, centrada em blocos de conteúdo, com projeções tipadas por canal em vez de um iterador de dicionários que o consumidor precisa filtrar na mão. Também entrou shutdown gracioso, que para a execução ao fim do superstep atual e salva um checkpoint retomável.

Do lado do CrewAI, a 1.12.1, de março de 2026, foi a release que mudou o patamar: agent skills, backend de memória Qdrant Edge, isolamento hierárquico de memória via root_scope automático, e provedores OpenAI-compatible nativos, incluindo OpenRouter, DeepSeek, Ollama, vLLM, Cerebras e Dashscope. Esse último item é o que mais muda a conversa de custo, porque tira o CrewAI da dependência de um único caminho de inferência.

A linha 1.14 seguiu por outro eixo, mais operacional. A 1.14.2 trouxe documentação de A2A, tanto no open source quanto no enterprise. A 1.14.6, de 28 de maio, endureceu o checkpointing, corrigiu vazamento de saída estruturada em loops de tool calling, e moveu o repositório de skills para experimental atrás de uma flag CREWAI_EXPERIMENTAL, o que é um sinal saudável de maturidade e não o contrário. E a 1.14.7, de 11 de junho, adicionou backends plugáveis para memória, conhecimento, RAG e flow, uma Chat API para fluxos conversacionais, e passou a expor finish_reason real, parâmetros de sampling e response.id nos eventos de LLM.

Lendo as duas trilhas lado a lado, dá para ver a divergência com clareza. O LangGraph está fechando buracos de runtime: timeout, compensação, custo de checkpoint, streaming tipado. O CrewAI está fechando buracos de plataforma: memória plugável, provedores nativos, protocolo entre agentes, API de conversa. São roadmaps de produtos diferentes, não de concorrentes diretos.

Os 18% De Overhead De Token E O Que Eles Realmente Dizem

O número que mais circula nessa comparação é o de que o CrewAI consome cerca de 18% mais tokens que uma implementação equivalente escrita à mão em LangGraph. A medição vem do TokenMix Research Lab, em abril de 2026, e antes de usar o dado vale dizer que o TokenMix vende um relay de API, então tem interesse na conversa sobre custo. Ainda assim, a explicação mecânica que eles dão é verificável e faz sentido.

São três fontes estruturais. A primeira é a verbosidade do role-play: o CrewAI prefixa cada chamada de agente com papel, objetivo e história de fundo, o que adiciona entre 800 e 1.500 tokens de prompt por invocação numa crew de cinco agentes. A segunda é a propagação de contexto entre agentes, já que o parâmetro context compartilha saídas de tarefas anteriores como texto de conversa cru, enquanto o LangGraph obriga você a escolher exatamente quais campos do estado cada nó lê. A terceira é duplicação de definição de ferramenta, porque o CrewAI redeclara a assinatura de cada tool para cada agente que tem acesso a ela, e numa crew com dez ferramentas isso pode acrescentar mais de 2.000 tokens por turno de agente.

O detalhe que quase sempre some quando o número é citado é que 18% é o ponto médio. A faixa medida vai de 8%, num fluxo sequencial simples de dois agentes, até 35% num arranjo hierárquico com mais de dez agentes compartilhando um pool de ferramentas. Ou seja: o overhead escala com a complexidade da topologia, não é uma taxa fixa do framework. Se a sua crew tem dois agentes e três ferramentas, o número relevante para você é o de baixo da faixa.

Traduzindo em dinheiro, o próprio levantamento faz a conta: 18% sobre 1.000 dólares por mês de gasto com LLM são 180 dólares; sobre 10 mil, são 1.800; sobre 100 mil, são 18 mil. Abaixo de mil dólares mensais, a matemática simplesmente não justifica tempo de engenheiro. Acima de 25 mil, ela se paga em dias. Esse é o tipo de critério que eu gostaria de ver mais vezes numa decisão de stack, no lugar de "o outro framework é mais bonito".

E vale a ressalva metodológica: qualquer percentual desses só é comparável se tarefa, modelo, prompts, ferramentas e orçamento forem mantidos constantes. Benchmark de terceiro serve como hipótese, não como veredito. Um spike de dois dias com as suas ferramentas reais é evidência mais forte que qualquer tabela, inclusive a que está neste post.

Critério De Decisão Por Estágio Do Time, Não Por Hype

Se eu tivesse que reduzir a decisão a uma pergunta, seria esta: o que você está tentando descobrir agora? Se a resposta é "se essa ideia de multiagente resolve o problema", CrewAI é a escolha certa e discutir os 18% é otimização prematura. Se a resposta é "como isso sobrevive a restart, a rate limit e a auditoria", LangGraph é a escolha certa e discutir facilidade de setup é o argumento errado.

Na prática, isso vira quatro cenários razoavelmente nítidos. Time explorando, sem certeza de que o formato multiagente é o caminho, com stakeholder esperando ver algo funcionando nesta semana: CrewAI, sem culpa. Time com fluxo linear estável, poucas ferramentas e gasto mensal baixo com LLM: CrewAI continua sendo a escolha certa, e migrar seria trocar custo de token por custo de engenheiro numa conta que não fecha. Time que já bateu na parede de roteamento condicional, precisa de loop com retentativa, ramificação por saída de ferramenta ou paralelismo com merge: LangGraph, porque no CrewAI isso exige código custom que anula a proposta de valor de prototipagem fácil. Time rodando agente 24 horas por dia com consequência real na ponta, que precisa retomar do nó exato depois de um crash e reconstruir a decisão para um auditor: LangGraph, sem hesitação.

Existe um quinto cenário que quase ninguém cita e que eu acho o mais comum: o time que não deveria estar usando nenhum dos dois ainda. Se os passos e as ramificações são conhecidos, se cada operação tem entrada e saída estáveis e se auditabilidade importa mais que exploração aberta, um workflow determinístico resolve melhor e mais barato. "Mais agentes" não é nível de maturidade, é mais um sistema distribuído para operar.

Vale ainda considerar uma terceira via que muitos times ignoram: não escrever o plano de controle. Infraestrutura gerenciada de agentes resolve sandbox, sessão e ciclo de vida por você, ao custo de acoplamento a um provedor. É um trade-off deliberado, não uma derrota, desde que você documente o caminho dos dados, consiga exportar estado e traces, e saiba calcular o custo de saída antes de entrar.

O Custo Real De Migrar De Um Para O Outro

O padrão de migração mais comum é sempre na mesma direção: construir no CrewAI, validar o conceito, bater numa parede de lógica condicional ou de controle de custo, e ir para o LangGraph. Vale saber disso antes de começar, porque muda o que você escreve no primeiro dia.

Os números de esforço, na tabela do TokenMix, são menos assustadores do que a fama sugere. Um fluxo de dois a três agentes sequenciais leva de 4 a 8 horas de um engenheiro. De cinco a sete agentes com lógica condicional, de um a dois dias. Dez ou mais agentes hierárquicos com ferramentas customizadas, de três a cinco dias. E o corte de produção, com teste de carga e canário, adiciona outros dois a três dias. O que domina o custo, portanto, não é a tradução de código: é a validação.

O passo que determina a qualidade de tudo é o schema de estado. Traduzir agente em nó é mecânico. Traduzir processo sequencial em arestas é mecânico. Decidir exatamente quais dados fluem entre etapas, sem sobra e sem falta, é o trabalho de verdade, e é onde o tempo aparece. Papel, objetivo e história de fundo colapsam num único prompt de sistema por nó, e a redundância dessas três seções some.

A alavanca que mais reduz custo de migração, porém, é anterior à migração: escrever ferramenta como servidor MCP em vez de wrapper específico do framework. Ferramenta em MCP funciona no CrewAI, no LangGraph e em qualquer runtime compatível, o que desacopla implementação de orquestração e torna qualquer troca futura uma mudança de camada, não uma reescrita. Fatorar uma tool existente em MCP custa entre 2 e 4 horas de engenheiro, e paga múltiplos disso na primeira troca de framework. Vale a mesma disciplina para regras de negócio: elas não deveriam viver dentro de string de prompt, de callback de framework ou de objeto de mensagem específico de provedor.

Uma última observação sobre o caminho inverso. Envolver uma crew do CrewAI dentro de um nó do LangGraph é tecnicamente possível e quase sempre uma má ideia: você mantém o overhead de token, carrega as dependências dos dois frameworks e perde justamente o modelo de controle que motivou a mudança. Se vai migrar, migre.

Conclusão

Depois de tudo isso, a resposta que eu daria hoje na frente daquele repositório é menos elegante do que eu gostaria: depende de quanto tempo o serviço vai ficar de pé. Para o protótipo que precisa existir na sexta, CrewAI. Para o fluxo que já está em produção e reinicia sozinho toda madrugada, LangGraph. O mesmo time, o mesmo trimestre, dois frameworks diferentes, e isso não é incoerência.

O que me parece mais importante do que a escolha em si é o que ela revela. Escolher LangGraph é assumir que você quer ver e controlar cada transição, e pagar por isso em código e em semanas de curva de aprendizado. Escolher CrewAI é assumir que velocidade de descoberta vale mais agora do que controle fino, e pagar por isso em tokens e em opacidade de debug. As duas são decisões defensáveis. O que não é defensável é escolher sem saber qual dos dois preços você está pagando.

Não tenho como afirmar qual dos dois vai estar melhor posicionado daqui a um ano, e desconfio de quem afirma. O que dá para observar é que MCP, A2A e OpenTelemetry estão reduzindo o custo de troca em todo mundo ao mesmo tempo, o que torna a decisão de hoje menos definitiva do que ela parece. Se isso continuar, o critério que sobra é bem menos glamouroso do que a discussão de framework sugere: escolha o que deixa o seu time entender o que o sistema fez quando ele fizer errado.

Fontes:

• LangChain — Fault Tolerance in LangGraph: Retries, Timeouts, and Error Handlers
• GitHub — langgraph v1.2 (alpha) release notes
• CrewAI — Changelog oficial
• Softmax Data — Definitive Guide to Agentic Frameworks in 2026
• TokenMix Research Lab — CrewAI to LangGraph Migration Guide: Cut 18% Token Overhead
• QubitTool — AI Agent Frameworks 2026: A Decision Framework
• Morph — AI Agent Frameworks (2026 Update): 8 SDKs Compared