LangGraph, Mem0, LangChain, MCP: do que você realmente precisa

Você abriu 6 abas de documentação e ainda não escreveu uma linha de código. LangGraph numa, Mem0 na outra, LangChain, MCP, um comparativo de vector store e um tutorial de 40 minutos no YouTube. O problema não é escolher a ferramenta errada. É achar que precisa de uma.

O ecossistema de orquestração e memória para agentes amadureceu rápido demais e ninguém parou pra escrever o mapa honesto. Cada projeto tem uma landing page que diz "build production-ready agents" e nenhum diz em que ponto exato ele passa a valer o próprio peso. Esse post é esse mapa.

Aqui você vai sair com quatro definições sem marketing, o critério de corte de cada ferramenta (o momento em que ela deixa de ser overhead e vira infraestrutura) e uma árvore de decisão de 5 perguntas pra rodar antes de instalar qualquer coisa. Incluindo o caso — comum — em que a resposta certa é "nenhuma delas".

TL;DR

• O que é: mapa de decisão do ecossistema de orquestração (LangGraph, LangChain) e memória (Mem0) de agentes, mais o estado real do MCP.
• Stack/Modelos: agnóstico. Os exemplos são Python, mas o critério vale igual pra PHP, TypeScript ou Go.
• Custo/Acesso: LangGraph, LangChain e Mem0 OSS são open source e gratuitos. Mem0 Platform começa em US$ 19/mês. MCP é protocolo aberto.
• Regra de bolso: escreva o loop cru primeiro. Adote framework quando bater numa dor específica com nome, não por princípio.

O que cada uma faz, em uma frase, sem marketing

Antes de decidir qualquer coisa, precisa ficar claro que essas quatro coisas não competem entre si. Três são bibliotecas em camadas diferentes e uma é um protocolo. Comparar LangGraph com MCP é comparar Laravel com HTTP.

LangChain é a camada de conveniência. Interface unificada pro modelo, tools, structured output e um loop de agente pronto. Na versão 1.0, lançada em outubro de 2025, a biblioteca jogou fora initialize_agent e AgentExecutor e colapsou tudo em um único ponto de entrada, create_agent, com hooks de middleware (before_model, wrap_model_call, wrap_tool_call, after_model) para você mexer no loop sem reescrevê-lo. É menos framework e mais harness enxuto do que a versão que te traumatizou em 2023.

LangGraph é o runtime. Você declara nós, arestas e estado; ele executa o grafo, salva checkpoint a cada transição de nó e sabe retomar de onde parou. É a peça que transforma "meu script morreu no meio" em "meu agente pausou e continuou".

Mem0 é uma camada de memória de longo prazo. Ele lê a conversa, extrai fatos sobre o usuário, decide o que é novo, o que conflita com o que já sabia e o que descartar — e devolve só os trechos relevantes na próxima chamada, em vez de você reenviar o histórico inteiro.

MCP não é biblioteca nenhuma. É o protocolo que padroniza como um cliente de IA descobre e chama ferramentas expostas por um servidor. Ele não orquestra, não guarda memória, não decide nada. Só substitui integração custom por interface comum.

Repare no padrão: nenhuma das quatro resolve o problema difícil. O problema difícil é decidir o que entra no contexto, quando o modelo chama tool, como você mede se a resposta prestou e quanto isso custa por requisição. Ferramenta nenhuma decide isso por você — e é exatamente esse conjunto de decisões que a gente destrincha ao vivo no AI Engineering Lab 3ª Edição, dois dias de imersão em 19 e 20 de setembro montando arquitetura de agente com tool calling, roteamento, memória, grounding, tracing, evals e custo na mesa. O resto do post é o mapa de quando cada biblioteca ajuda nesse desenho e quando ela só atrapalha.

Orquestração: quando LangGraph paga o próprio peso

A recomendação mais honesta sobre framework de agente veio da própria Anthropic, no Building Effective Agents: "Developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code." O aviso que vem junto é o que importa — framework facilita o começo e ofusca o que está rodando por baixo, o que torna debug mais difícil.

Um agente de tool calling é literalmente isto:

messages = [{"role": "user", "content": pergunta}]

while True:
    resp = client.messages.create(
        model="claude-sonnet-5",
        tools=TOOLS,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason != "tool_use":
        break

    resultados = [executar(bloco) for bloco in resp.content if bloco.type == "tool_use"]
    messages.append({"role": "user", "content": resultados})

Isso é um agente. Não é protótipo, não é versão simplificada pra didática. É o loop que roda em produção em muito mais lugar do que as landing pages sugerem. Se o seu caso é "chama o modelo, ele decide uma tool, executa, responde", instalar LangGraph em cima disso é adicionar um grafo, um schema de estado e um checkpointer pra continuar rodando o mesmo while.

Então quando LangGraph paga o próprio peso? Quando você bate numa destas quatro dores, com nome e sintoma:

1. Execução durável. O processo caiu no meio de uma sequência de 12 passos e você precisa retomar do passo 9, não do zero. LangGraph faz checkpoint a cada transição de nó numa camada de persistência plugável — memória em dev, SQLite em algo leve, Postgres em produção. Reimplementar isso na mão dá certo. Dá trabalho.
2. Human-in-the-loop de verdade. O fluxo precisa parar, esperar aprovação humana que pode chegar 3 dias depois, e continuar com o estado intacto. Sem checkpoint persistido, isso vira gambiarra de fila.
3. Roteamento condicional com ciclos. Não é if/else; é um grafo em que o nó de validação pode devolver pro nó de geração N vezes até passar, com limite de recursão.
4. Fan-out paralelo com merge de estado. Três nós rodando ao mesmo tempo e escrevendo no mesmo objeto de estado sem corromper nada.

Se você não consegue apontar qual dessas quatro dores está sentindo agora, a resposta é while. E não é trabalho jogado fora: o loop cru é onde você isola os ativos que são seus de verdade — as tools, os prompts, a lógica de decisão. Framework depois pluga nesse núcleo.

Vale registrar o outro lado. LangGraph não é hype de Twitter: são mais de 33 mil estrelas no GitHub e dezenas de milhões de downloads mensais no PyPI, com Uber, LinkedIn e Klarna rodando em produção. A questão nunca foi se ele funciona. É se o seu problema tem a forma que ele resolve.

Memória: Mem0 vs. uma tabela no Postgres

Aqui a confusão é maior, porque "memória" virou palavra guarda-chuva pra três coisas diferentes.

Memória de curto prazo é o array de mensagens da conversa atual. Isso é uma coluna JSON. Não precisa de ferramenta.

Memória semântica é "recupere os trechos parecidos com a pergunta". Isso é busca vetorial, e o Postgres que você já tem resolve — já detalhei o setup completo em pgvector no Postgres: onde guardar a memória do seu agente. Não vou repetir o argumento aqui: em resumo, na escala em que 90% dos produtos vivem, uma tabela com uma coluna vector e um índice HNSW é a resposta certa.

Memória de fatos sobre o usuário é onde o Mem0 entra e onde SELECT não resolve sozinho. O problema não é guardar, é manter coerente. O usuário disse em março que é vegetariano e em agosto que voltou a comer carne. Você tem dois fatos contraditórios na base. Qual entra no prompt?

Isso é o trabalho real: extrair fato de conversa, detectar conflito, resolver conflito, decidir relevância na recuperação. É a parte que dá trabalho de escrever e mais trabalho ainda de manter.

Os números que a Mem0 publica na página de research são bons: 92,5 no LoCoMo, 94,4 no LongMemEval, e — o dado que interessa mais no fim do mês — cerca de 1,8 mil tokens por conversa contra 26 mil de mandar o contexto inteiro. É uma redução de ~90% no custo por chamada, com p50 de latência abaixo de 1,1 s. Números do próprio vendor, então trate como teto, não como garantia. Mas a ordem de grandeza faz sentido: enviar 5 fatos relevantes é obviamente mais barato que enviar 40 turnos de conversa.

O detalhe que quase ninguém lê antes de decidir: o Mem0 open source e o Mem0 Platform não são o mesmo produto. Pela documentação oficial de comparação, o OSS (Apache 2.0) não tem graph memory, memory decay, temporal reasoning, operações em lote, webhooks nem app_id pra separação multi-tenant. Passar parâmetro de decay no OSS retorna erro. Self-host é grátis em licença e custa três containers — FastAPI, Postgres com pgvector e Neo4j — mais o seu custo de LLM, porque a extração de fatos é uma chamada de modelo a cada escrita. A Platform começa em US$ 19/mês e graph memory só aparece no plano de US$ 249.

Critério de corte, então:

• Uma tabela no Postgres se a memória do seu agente é "o que esse usuário perguntou antes" e "quais documentos são parecidos com isso".
• Mem0 (ou equivalente) se você precisa que o agente saiba fatos sobre a pessoa que atravessam sessões, se contradizem com o tempo e precisam ser reconciliados sem intervenção.
• Nada se a sua sessão é stateless. Chatbot de FAQ não precisa lembrar de nada, e memória mal calibrada envenena resposta com contexto velho.

MCP: o que mudou e o que ainda é hype

MCP é o item da lista que mais mudou nos últimos meses, e mudou pra um lado que quase ninguém comentou.

A spec 2026-07-28 é a maior revisão desde o lançamento do protocolo, e o resumo é: o MCP virou stateless. Sumiram o handshake initialize/initialized e o header Mcp-Session-Id. Cada requisição carrega a própria versão de protocolo, identidade e capabilities em _meta. Na prática, isso significa que qualquer request pode cair em qualquer instância do servidor atrás de um load balancer round-robin, sem estado compartilhado. MCP deixou de exigir infra especial e passou a rodar em HTTP comum.

Junto vieram mudanças que interessam a quem opera:

• Roteamento por header. Mcp-Method e Mcp-Name agora são obrigatórios, então gateway consegue rotear e medir sem fazer parse de JSON.
• Resultados cacheáveis. tools/list, prompts/list, resources/list e resources/read passaram a devolver ttlMs e cacheScope.
• Tasks saiu do core e virou extensão oficial (io.modelcontextprotocol/tasks), com tasks/get por polling.
• Deprecações com prazo. Dynamic Client Registration cede lugar a CIMD; Roots, Sampling, Logging e o transporte legado HTTP+SSE têm ao menos 12 meses de estrada antes de sumir.

O que ainda é hype: a ideia de que plugar mais servidores MCP deixa o agente melhor. Deixa pior. Definição de tool ocupa contexto, e contexto é recurso escasso. A própria Anthropic mostrou o tamanho do problema no Code execution with MCP: num exemplo trabalhado, trocar chamadas de tool diretas por código que carrega só as definições necessárias sob demanda levou o consumo de 150 mil para 2 mil tokens — 98,7% de redução.

Leia de novo. O gargalo não era o modelo. Era o catálogo de ferramentas que você empurrou pra dentro da janela antes de ele ler a pergunta.

A conclusão prática é chata e correta: MCP é excelente para integração — parar de escrever adapter custom pra cada sistema, reaproveitar servidor que já existe, padronizar auth. É péssimo como estratégia de capacidade. Vinte servidores conectados não é um agente poderoso, é um agente com contexto entupido.

A árvore de decisão: 5 perguntas antes de instalar qualquer coisa

Roda na ordem. Para na primeira que der "não".

1. O fluxo tem ciclo, ramificação condicional ou paralelismo? Se é sequência linear de passos, você não precisa de grafo. Precisa de função. Não → sem LangGraph.

2. Uma queda no meio da execução custa caro? Custa caro = perder trabalho de minutos, dinheiro gasto em tokens ou uma ação parcialmente aplicada em sistema externo. Sim → o checkpointer do LangGraph paga o próprio peso. Não, é request de 3 segundos → um retry resolve.

3. Alguém precisa aprovar algo no meio do caminho? Human-in-the-loop com espera longa exige estado persistido e retomada. Isso é a especialidade do LangGraph e é chato de fazer na mão. Não → segue o loop.

4. O agente precisa lembrar de fatos que atravessam sessões e se contradizem no tempo? Não, só preciso de trechos parecidos → pgvector. Não, é stateless → nada. Sim → aí sim uma camada de memória dedicada, com a ressalva do OSS vs. Platform.

5. Você vai integrar com sistema que já tem servidor MCP pronto? Sim → use MCP, é economia de código real. Não, é a sua própria API → uma função Python com um schema JSON é mais simples, mais rápida e mais barata em contexto que subir um servidor MCP pra falar com você mesmo.

Cinco "não" é um resultado legítimo e mais comum do que parece. Significa: SDK do modelo, um while, suas funções, seu Postgres. Esse stack aguenta produção.

E tem a pergunta zero, que vem antes das cinco: você já tem tracing? Se você não consegue reconstruir por que o agente decidiu o que decidiu, trocar de framework não vai resolver nada — só vai mudar o lugar onde você não enxerga. Essa parte tem post próprio em observabilidade de agentes de IA.

Limitações e pontos de atenção

Framework não é neutro em custo de contexto. Abstração que monta prompt por você monta prompt que você não leu. Antes de culpar o modelo por uma resposta ruim, logue o payload final que saiu pra API. Já vi caso de prompt de sistema dobrado de tamanho por middleware que "ajudava".

Memória gerenciada é superfície de vazamento. Mandar conversa de cliente pra serviço de memória de terceiro é processamento de dado pessoal. Sob LGPD, isso quer dizer base legal, contrato de operador, política de retenção e um caminho de exclusão que funcione de verdade. Se essa conversa ainda não aconteceu no seu time, self-host resolve o problema jurídico e te devolve o problema de infra.

MCP amplia superfície de ataque. Servidor MCP de terceiro é código que descreve ferramentas pro seu modelo — e descrição de ferramenta é texto que entra no contexto. Prompt injection via tool description é vetor real e já rendeu guia de segurança dedicado da NSA. Trate servidor MCP externo com o mesmo cuidado de uma dependência com permissão de escrita.

Benchmark de vendor mede o caso do vendor. Os números do Mem0 são do Mem0. Provavelmente estão certos no cenário que eles testaram. O seu cenário é outro. Meça no seu dado antes de assinar qualquer plano.

FAQ rápido

LangChain e LangGraph são a mesma coisa? Não. LangGraph é o runtime de grafo com estado e checkpoint; LangChain é a camada de conveniência (modelo, tools, create_agent, middleware) que roda em cima dele. Dá pra usar LangGraph sozinho. Dá pra usar LangChain sem nunca desenhar um grafo.

Preciso de LangChain pra usar MCP? Não. MCP é protocolo com SDKs oficiais em TypeScript, Python, Go e C#. Você fala MCP direto do seu código, sem framework de agente nenhum no meio.

Vale migrar um agente que já roda em while puro pra LangGraph? LangGraph vale a pena quando você já sentiu uma das quatro dores: execução durável, human-in-the-loop com espera longa, ciclo condicional ou fan-out paralelo. Migrar "pra ficar mais profissional" é refatoração sem hipótese — você troca código que entende por abstração que ainda não entende.

Qual a melhor alternativa ao LangChain? Depende do que te incomoda nele. Se é o peso da abstração, a alternativa é o SDK do modelo direto — Anthropic, OpenAI ou Gemini — com as suas funções. Se é o ecossistema, existem opções mais enxutas e tipadas como Pydantic AI, e no mundo PHP o Prism cobre o mesmo terreno. Não existe substituto único porque LangChain não faz uma coisa só.

Mem0 OSS dá conta ou preciso da Platform? Dá conta se você quer extração e reconciliação de fatos com storage seu. Se precisa de graph memory, memory decay ou temporal reasoning, esses recursos não existem no OSS e o parâmetro retorna erro — é Platform ou é implementação sua.

O que fica

O ecossistema não está confuso. Está em camadas, e as camadas ficaram claras: protocolo (MCP), runtime (LangGraph), conveniência (LangChain), memória (Mem0 e concorrentes). O que confunde é a suposição, que ninguém escreveu mas todo mundo carrega, de que você precisa de uma peça em cada camada pra ser levado a sério.

Não precisa. Precisa de um loop que você entende, tools que você testou, contexto que você controla e um número que diz se está funcionando.

Escreva o while primeiro. Rode em produção. Quando doer, o nome da dor vai te dizer exatamente qual peça instalar — e você vai instalar uma, não seis. Essa é a diferença entre escolher arquitetura e colecionar dependência.