📊 LangGraph: workflows como grafos
O LangGraph e uma extensao do LangChain que permite modelar workflows de agentes como grafos dirigidos com estado. Em vez de definir agentes com papeis (como no CrewAI), voce define nos (funcoes que processam estado), arestas (conexoes que definem o fluxo) e um estado tipado (TypedDict ou Pydantic model) que flui pelo grafo. Essa abordagem oferece controle maximo sobre cada passo da execucao.
A filosofia do LangGraph e explicitude sobre conveniencia. Enquanto CrewAI abstrai o fluxo com metaforas de equipe, LangGraph expoe cada decisao de roteamento como codigo. Isso significa mais trabalho na configuracao inicial, mas total transparencia e controle sobre o comportamento do sistema. Para workflows complexos com muitas condicoes, loops e pontos de aprovacao humana, LangGraph e a escolha predominante em 2026 — especialmente em organizacoes que precisam de auditabilidade completa.
💡 Conceitos fundamentais
Os tres pilares do LangGraph:
- • StateGraph: O container principal — define o tipo de estado e o grafo de nos/arestas
- • Nodes: Funcoes Python que recebem estado, processam e retornam estado atualizado
- • Edges: Conexoes entre nos — fixas (sempre segue) ou condicionais (if/else baseado no estado)
- • Checkpointing: Persistencia automatica do estado a cada passo — retomar apos falhas
📊 Numeros e adocao
- LangGraph Cloud: Plataforma de deploy gerenciada disponivel desde 2025
- LangChain Academy: Curso gratuito 'Introduction to LangGraph' — melhor recurso de aprendizado
- Adocao enterprise: Padrao para workflows com compliance em financeiro, saude e governo
- Integracao: LangSmith para observabilidade, LangServe para deploy, LangChain para tools
🔲 Nos: unidades de processamento
Um no (node) no LangGraph e simplesmente uma funcao Python que recebe o estado atual, processa e retorna uma atualizacao do estado. O estado e um dicionario tipado (geralmente um TypedDict) que carrega toda a informacao necessaria para o workflow. Cada no pode ser um agente LLM, uma ferramenta, uma validacao de negocio ou qualquer logica Python — nao ha restricao sobre o que acontece dentro do no.
A beleza dos nos esta na composicao. Voce pode ter um no que chama um LLM para classificar uma mensagem, seguido por um no que executa codigo baseado na classificacao, seguido por um no que valida o resultado. Cada no e uma funcao Python testavel e reutilizavel. Isso torna o LangGraph particularmente atrativo para equipes de engenharia que valorizam testes unitarios, code review e manutencao a longo prazo.
💡 Anatomia de um Node
Como nos processam e transformam estado:
- • Input: O no recebe o estado completo do grafo (TypedDict ou Pydantic model)
- • Processamento: Qualquer logica Python — chamada de LLM, API, banco de dados, validacao
- • Output: Retorna um dicionario com as chaves do estado que devem ser atualizadas
- • Reducers: Para listas, voce pode definir como novos valores se combinam com existentes (append, replace)
📊 Tipos comuns de nos
- Agent node: Chama um LLM com tools — o agente raciocina e possivelmente chama funcoes
- Tool node: Executa uma ferramenta especifica e retorna o resultado no estado
- Logic node: Logica de negocio pura — validacao, transformacao, decisao sem LLM
- Human node: Pausa execucao e aguarda input humano — essencial para aprovacoes
➡️ Arestas: fluxo de controle
As arestas (edges) definem como o controle flui entre nos. Existem dois tipos: arestas fixas (o no A sempre vai para o no B) e arestas condicionais (uma funcao examina o estado e decide para qual no ir). As arestas condicionais sao onde a logica de roteamento vive — e o equivalente a um "if/else" ou "switch" no fluxo do grafo.
O poder das arestas condicionais esta na flexibilidade. Voce pode criar roteamento baseado em classificacao de intencao ("se o usuario quer suporte, va para o no de suporte"), baseado em qualidade ("se o score de confianca e menor que 0.8, va para o no de revisao") ou baseado em estado ("se ja tentamos 3 vezes, va para o no de fallback"). Esse controle explicito e o que diferencia LangGraph de frameworks mais opinados — nada e magico, tudo e codigo que voce pode inspecionar e testar.
💡 Tipos de arestas
Como definir o fluxo entre nos:
- • add_edge(A, B): Aresta fixa — apos no A, sempre execute no B
- • add_conditional_edges(A, func, mapping): Funcao examina estado e retorna o nome do proximo no
- • START → primeiro no: Define onde o grafo comeca
- • no → END: Define condicoes de termino do grafo
📊 Padroes de roteamento
- Router pattern: No de classificacao → arestas condicionais para especialistas
- Loop pattern: No de execucao → no de avaliacao → se ok END, senao volta para execucao
- Fan-out: Um no dispara multiplos nos em paralelo (send API do LangGraph)
- Fallback pattern: Se condicao de erro, roteia para no de recuperacao
💾 Checkpointing: execucao duravel
O checkpointing e um dos recursos mais poderosos do LangGraph para producao. A cada transicao entre nos, o estado completo do grafo e automaticamente salvo em um backend de persistencia (SQLite, PostgreSQL, Redis). Se a execucao falha no meio — timeout de API, crash do servidor, rate limit — voce pode retomar exatamente de onde parou, sem reprocessar os nos anteriores.
Para swarms de longa duracao que podem levar minutos ou horas para completar, checkpointing e essencial. Imagine um workflow de revisao de documentos com 15 etapas: sem checkpointing, uma falha na etapa 12 forca voce a recomecar do zero. Com checkpointing, voce retoma da etapa 12 com todo o estado preservado. O custo adicional de persistencia e negligivel comparado ao custo de reprocessar chamadas de LLM.
💡 Como checkpointing funciona
O mecanismo de persistencia e recuperacao:
- • Save automatico: Estado salvo a cada transicao entre nos — sem intervencao do desenvolvedor
- • Thread ID: Cada execucao tem um identificador unico para rastrear e retomar
- • Backends: SQLite (dev), PostgreSQL (producao), Redis (alta performance)
- • Resume: Passar o thread_id para retomar execucao exatamente de onde parou
📊 Beneficios em producao
- Resiliencia: Falhas de API, timeouts e crashes nao perdem trabalho ja feito
- Human-in-the-loop: Pausar execucao, esperar aprovacao humana, retomar — dias depois se necessario
- Debugging: Inspecionar estado em qualquer ponto da execucao para entender o que aconteceu
- Replay: Re-executar um workflow com o mesmo estado inicial para reproduzir bugs
👤 Human-in-the-loop
O human-in-the-loop do LangGraph permite inserir pontos de aprovacao humana em qualquer lugar do grafo. Usando a funcao interrupt(), voce pausa a execucao do workflow e aguarda input do usuario. O estado e automaticamente salvo via checkpointing, e quando o humano responde (minutos, horas ou dias depois), a execucao retoma exatamente de onde parou.
Esse recurso e fundamental para cenarios de governanca: antes de executar uma transacao financeira, o agente pausa e pede aprovacao humana. Antes de enviar um email importante, o agente mostra o rascunho para revisao. Antes de fazer deploy em producao, o agente apresenta o plano e espera confirmacao. O human-in-the-loop transforma agentes autonomos em sistemas de colaboracao homem-maquina com nivel de confianca adequado para enterprise.
💡 Implementacao de HITL
Como inserir pontos de aprovacao humana:
- • interrupt(): Funcao que pausa execucao e envia estado atual para o usuario
- • Checkpointing automatico: Estado preservado enquanto aguarda resposta humana
- • Resume com input: Humano envia aprovacao/rejeicao/modificacao e execucao continua
- • Multiplos pontos: Voce pode ter varios interrupts em diferentes pontos do grafo
📊 Casos de uso enterprise
- Aprovacao financeira: Agente prepara transacao, humano aprova ou rejeita
- Revisao de conteudo: Agente gera texto, humano revisa antes de publicar
- Deploy safety: Agente prepara deploy, humano confirma antes de aplicar em producao
- Compliance: Pontos de auditoria obrigatorios onde humano valida conformidade
🏗️ Supervisors e subgraphs
Para workflows muito complexos, o LangGraph permite compor grafos dentro de grafos usando subgraphs. Um supervisor e um no que contem um subgrafo inteiro — ele recebe estado, executa o subgrafo completo e retorna o resultado. Isso permite criar hierarquias onde um supervisor de alto nivel coordena supervisores de area, cada um com seus proprios agentes especializados.
Na pratica, voce pode ter um supervisor principal com tres subgrafos: "pesquisa" (com agentes de busca e analise), "desenvolvimento" (com agentes de codigo e teste) e "documentacao" (com agentes de escrita e revisao). Cada subgrafo e um LangGraph completo com seus proprios nos, arestas e logica. O supervisor principal decide qual subgrafo acionar baseado na tarefa. Essa composicao permite escalar para sistemas muito complexos mantendo cada parte gerenciavel.
💡 Composicao hierarquica
Como construir sistemas complexos com subgrafos:
- • Subgraph: Um grafo completo encapsulado como um unico no no grafo pai
- • Supervisor pattern: No principal que decide qual subgrafo acionar baseado no estado
- • State mapping: Mapear estado do grafo pai para estado do subgrafo e vice-versa
- • Reutilizacao: O mesmo subgrafo pode ser usado em multiplos grafos pais
📊 Padroes arquiteturais
- Supervisor + Workers: Supervisor roteia tarefas para subgrafos especializados
- Pipeline de subgrafos: Subgrafo A → Subgrafo B → Subgrafo C em sequencia
- Supervisor hierarquico: Supervisor principal → supervisores de area → agentes worker
- Subgrafo condicional: Acionar subgrafos diferentes baseado na classificacao da tarefa
📚 Resumo do Modulo
Proximo:
Modulo 2.4 - oh-my-openagent