LangGraph se ha convertido en el marco de trabajo predeterminado para equipos que construyen flujos de trabajo de IA agentiva. Sin embargo, su popularidad creciente lleva a muchos equipos a utilizarlo por defecto sin verificar si realmente necesitan un orquestador basado en grafos o algo más simple. Este artículo no es un tutorial, sino una guía estratégica: explica qué es LangGraph, qué problemas resuelve y cuándo es la arquitectura adecuada.
LangGraph organiza la lógica de un flujo de trabajo en un grafo con nodos (unidades de trabajo) y aristas (lógica de enrutamiento). Cada nodo recibe un estado, lo procesa y devuelve un estado actualizado. La característica clave es la gestión de estado: cuando hay múltiples llamadas de IA que dependen entre sí, con enrutamiento condicional y necesidad de reanudar tras fallos, el estado se vuelve complejo. LangGraph ofrece estructura para manejar esa complejidad sin construirla desde cero. Además, incluye checkpointing (persistencia del estado para reanudar ejecuciones interrumpidas) e integración humano-en-el-bucle (pausar la ejecución para esperar una decisión humana).
LangGraph tiene sobrecarga. Tiene sentido cuando la lógica de decisión en un paso depende de salidas de pasos anteriores de formas no predecibles, cuando hay múltiples llamadas de IA que comparten estado, cuando se necesitan puntos de revisión humana o cuando el flujo debe adaptar su camino dinámicamente. En cambio, para flujos deterministas (como los de Airflow o Prefect) o para trabajos agentivos simples (una llamada de IA con tres ramas condicionales), herramientas más ligeras o Python puro son mejores opciones.
Antes de escribir código, los equipos experimentados diseñan el esquema de estado del grafo, la lógica de enrutamiento y los puntos de revisión humana. El esquema de estado debe ser mínimo: cada nodo recibe exactamente lo que necesita y descarta datos intermedios. El enrutamiento condicional debe explicitarse en el diseño, porque los errores suelen aparecer solo en producción. Los puntos de revisión humana deben planificarse desde el principio: qué condiciones los activan, qué información ve el revisor, qué acciones puede tomar y cómo su decisión retroalimenta la ejecución.
Un ejemplo real es un pipeline financiero de 19 nodos que procesa transacciones de siete fuentes de datos. El grafo se organiza en capas: extracción, clasificación (con razonamiento de IA) y validación (con patrón maker-checker). Cuando el maker y el checker discrepan, la transacción se envía a revisión humana con ambos resultados y las entradas que causaron el desacuerdo. Este patrón ha detectado errores que las pruebas deterministas no pudieron, como una clasificación incorrecta de jurisdicción fiscal que ningún test unitario habría capturado.