Tecnologia
Consultoria e implementação de LangGraph
O agente impressionou na demonstração. Em produção ele trava no meio de uma tarefa longa, e a única saída é começar do zero. Ninguém sabe em que passo ele parou, o que já tinha decidido nem quanto aquilo custou. O que funcionava na tela de quem construiu não sobrevive a uma chamada de API que falha.
Como a gente encara.
Começamos pela decisão, não pelo desenho. Cada ramo que o agente pode tomar vira aresta explícita no grafo; o que ficar dentro do prompt não é fluxo, é aposta. O estado ganha forma declarada e um checkpointer, para que a execução retome do passo onde caiu. Cada ferramenta recebe limite de efeito antes de ser exposta ao modelo. E o critério de parada é escrito por quem entende a tarefa, não herdado da trava da biblioteca.
Onde costuma quebrar
Os erros que aparecem sempre, e que ninguém conta na demonstração.
- 01
Grafo desenhado como fluxograma enquanto a decisão real continua dentro de um prompt gigante. Os nós existem, as arestas existem, e o caminho que o agente toma não está em nenhum dos dois — está numa instrução em texto que ninguém revisa.
- 02
Agente sem critério de parada próprio. Existe um limite de recursão (recursion limit) que interrompe o grafo, mas ele é trava de segurança, não regra de negócio: quando dispara, você já pagou todos os passos e não tem resultado nenhum.
- 03
Execução sem checkpointer. O estado vive na memória do processo, então uma falha de rede no meio do caminho apaga tudo o que o agente já havia apurado, e retomar significa reexecutar — e repagar — desde o começo.
- 04
Ferramenta exposta ao modelo sem limite de efeito. A que escreve no seu sistema entra na lista junto com a que só consulta, e um erro de raciocínio deixa de ser resposta ruim e vira alteração no dado.
- 05
Aprovação humana montada como espera dentro do código, e não como interrupção do grafo (interrupt). A interrupção depende de checkpointer para guardar onde parou; sem ele, o processo fica de pé segurando a execução, e quem aprova depois de um reinício encontra o trabalho perdido.
O que custa mais do que parece
- Cada passo que consulta o modelo é uma chamada paga. Um agente que reflete, revisa e tenta de novo acumula gasto entre passos, enquanto a única coisa que aparece no painel é a resposta final: o custo sobe onde ninguém está olhando.
- Depurar agente exige rastro por passo — qual estado entrou, o que o modelo respondeu, qual ferramenta foi acionada. Ninguém instrumenta isso antes de precisar, e a primeira vez que se precisa é com alguém esperando do outro lado.
- O checkpointer que resolve a retomada guarda o estado inteiro, e o estado inteiro costuma incluir todo o histórico da conversa. Você passa a operar um banco que cresce a cada execução e a decidir por quanto tempo guarda o que o agente leu pelo caminho.
O que você recebe
- Grafo com as decisões em arestas e cada nó com entrada e saída declaradas.
- Estado tipado e checkpointer configurado, com a retomada testada a partir de uma falha provocada de propósito.
- Catálogo de ferramentas com o efeito de cada uma classificado: o que apenas lê, o que escreve e o que exige confirmação humana.
- Critério de parada e teto de passos por execução, com o procedimento do que acontece quando o teto é atingido.
- Rastro por passo em ferramenta de observabilidade, ligando estado, chamada de modelo e ferramenta acionada.
O que fazemos com LangGraph
Open source ou enterprise, a frente é a mesma.
Implantar
Do zero, com a arquitetura decidida no diagnóstico e não pelo catálogo do fornecedor.
Migrar
De outra ferramenta, ou de uma versão antiga, com o que já roda continuando a rodar.
Desenvolver em cima
Aplicação, integração e automação construídas sobre LangGraph, incluindo o que a ferramenta não faz sozinha.
Sustentar
Operação, custo sob controle e correção de rota depois que entra em produção.
Perguntas diretas.
- LangGraph é uma versão nova do LangChain?
- Não. Eles resolvem coisas diferentes. LangChain é um conjunto de abstrações para compor chamadas, recuperação de contexto e ferramentas. LangGraph trata de fluxo de controle e de estado: quais passos existem, como se decide entre eles e o que sobrevive entre uma execução e outra. Dá para escrever cada nó usando componentes do LangChain ou chamando o provedor direto, e essa escolha é sua, não da biblioteca.
- Eu preciso mesmo de um agente, ou uma sequência fixa resolve?
- Se as etapas da tarefa são conhecidas de antemão e sempre as mesmas, você não tem um agente: tem um pipeline com uma chamada de modelo dentro. Uma função com os passos em ordem é mais barata, mais rápida e você consegue testar sem simular raciocínio. Agente se justifica quando o caminho depende do que foi descoberto no meio do percurso, e quando tomar o caminho errado de vez em quando é aceitável. Se não é o seu caso, LangGraph acrescenta grafo, estado e um banco para manter, e nenhum deles resolve um problema que você tem.
- Dá para adotar LangGraph num agente que já existe, sem reescrever tudo?
- Dá, e o caminho costuma ser o inverso do esperado. O agente atual entra como um nó só, e o grafo nasce em volta dele: estado, checkpointer e rastro primeiro, comportamento depois. A partir daí cada decisão sai do prompt e vira aresta, uma de cada vez, com o comportamento antigo ainda de pé para comparar. A reescrita de uma vez é o que costuma travar, porque ninguém consegue dizer se o novo ficou melhor ou apenas diferente.
Antes de escolher a ferramenta
A ferramenta é consequência da arquitetura. Nunca a premissa.
Esta página existe porque alguém procura por esse nome. Mas a escolha certa sai do diagnóstico do seu cenário, não do catálogo de quem vende. Se a resposta for outra ferramenta, ou nenhuma, é isso que você vai ouvir.
Não está na lista? Não é impedimento, é conversa. O que decide não é o nome do produto, é o problema que ele precisa resolver.