No son competidores, son capas distintas del mismo ecosistema. La pregunta correcta no es cuál es mejor sino qué forma de control de flujo necesita tu problema.
LCEL modela flujos como un grafo acíclico dirigido (DAG): cada paso se ejecuta una vez, en un orden determinado por la composición del pipe. Es la abstracción correcta cuando el flujo es fundamentalmente lineal o paralelo: recuperar, formatear, generar. LangGraph modela flujos como una máquina de estados con `StateGraph`: los nodos pueden ejecutarse en cualquier orden determinado dinámicamente, incluyendo ciclos —volver a un nodo anterior— y ramificación condicional basada en el estado acumulado, no solo en la salida del paso inmediatamente anterior.
Esta diferencia no es cosmética. Un agente que decide, tras leer el resultado de una herramienta, que necesita volver a llamar al modelo con más contexto, o repetir una búsqueda con una consulta reformulada, requiere un ciclo. LCEL puro no expresa ciclos de forma nativa; LangGraph sí.
Si tu flujo se puede dibujar como una línea recta o un abanico de pasos paralelos que convergen una sola vez, LCEL es la herramienta correcta y más simple de mantener:
Casos típicos: clasificación, resumen, extracción de entidades, un RAG simple de una sola vuelta de recuperación. Añadir LangGraph aquí es complejidad sin beneficio: más código boilerplate para un flujo que nunca necesitó estado mutable ni ciclos.
La señal más clara es la presencia de al menos una de estas condiciones: el flujo necesita recordar estado entre pasos que no es simplemente "la salida anterior" (por ejemplo, un contador de reintentos, una lista acumulada de herramientas usadas); el flujo puede necesitar repetir un paso (un agente ReAct que llama herramientas hasta satisfacer la consulta); o el flujo requiere pausar para intervención humana antes de continuar.
El ciclo `modelo -> herramientas -> modelo` es exactamente lo que LCEL no puede expresar de forma nativa sin recursión manual fuera del framework.
LangGraph no reemplaza LCEL: lo usa como bloque de construcción. Cada nodo de un `StateGraph` puede ser, y en la práctica casi siempre es, una cadena LCEL completa. Es común tener un nodo que internamente es `prompt | llm | parser`. LangGraph aporta el control de flujo de alto nivel (cuándo ejecutar qué, cuántas veces, con qué estado); LCEL aporta la composición eficiente dentro de cada paso.
LangGraph introduce conceptos que LCEL no tiene: definición explícita de esquema de estado (`TypedDict` o `Pydantic`), checkpointers para persistencia, y un modelo mental de grafo dirigido con aristas condicionales. Para un equipo que recién empieza con LLMs, este salto de complejidad debe justificarse con un requisito real de ciclos, estado persistente entre sesiones, o intervención humana. Empezar todo proyecto nuevo directamente con LangGraph "por si acaso" añade fricción de desarrollo sin beneficio si el flujo termina siendo lineal.
En nuestros proyectos aplicamos una regla simple: si puedes dibujar el flujo en una pizarra sin flechas que regresen hacia atrás, usa LCEL. En el momento en que dibujas una flecha que vuelve a un nodo anterior —o necesitas que el sistema "recuerde" algo más complejo que el mensaje inmediatamente anterior— migra ese flujo específico a LangGraph, mientras el resto del sistema sigue en LCEL.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel