El framework que elige es una apuesta de abstracción

La trampa es tratarlas como competidoras en un solo eje. No lo son. Cada una se construyó para resolver una capa distinta del sistema, y muchos sistemas de producción usan dos de ellas juntas:

• LangChain es un conjunto de herramientas de orquestación: encadena plantillas de prompts, llamadas al modelo, analizadores de salida, memoria y herramientas en flujos de varios pasos. Su equipo ahora desarrolla LangGraph para agentes con estado basados en grafos, que es adonde se movió el trabajo real de agentes en producción.
• LlamaIndex es un conjunto de herramientas de recuperación: ingesta, fragmentación, embeddings, indexación y consulta. Mientras LangChain orquesta lo que pasa entre un paso y otro, LlamaIndex hace que el paso de recuperación en sí sea preciso y barato.
• Las llamadas directas a la API no son el recurso primitivo que a veces se dice. Son una postura sobre cuánta abstracción se necesita en realidad, y cada vez más es aquella hacia la que regresan los equipos de producción.

Así que la pregunta nunca es “qué framework gana”. Es: dado lo que de verdad estoy construyendo, ¿qué capa de abstracción se gana su costo?

En 2022, envolver de forma confiable las llamadas a herramientas y las cadenas de prompts requería un framework, porque las APIs de los proveedores eran inconsistentes. En 2026 esa razón casi desapareció: OpenAI y Anthropic integraron en sus SDK nativos las llamadas a herramientas, el streaming, los esquemas de funciones y la memoria de varios turnos. Las abstracciones del framework ya no ocultan diferencias relevantes: ocultan el camino que sigue el código. Y el costo de eso se puede medir; no es retórica:

Una comparación documentada encontró que LangChain costaba 2.7× lo que una implementación nativa en un proceso RAG básico: abstracción que consume tokens que el trabajo no necesitaba. Los equipos que lo dejan reportan entre 40 y 60% menos código y entre 70 y 90% menos mantenimiento del framework. Ese es el giro: el consejo por defecto solía ser “empiece directo y gradúese a un framework”. El patrón que vale la pena observar ahora es el inverso.

Cifras de la comparación de frameworks de MachineLearningMastery (julio de 2026), que reúne varios benchmarks independientes (en inglés). Tómelas como orientativas, no como resultados de laboratorio.

Nada de esto hace malos a los frameworks: los hace situacionales. El valor de una abstracción depende por completo de si oculta una complejidad que usted realmente enfrenta:

• El SDK directo gana en trabajo simple, de una sola llamada y sensible a la latencia: lo más rápido de escribir, lo más rápido de ejecutar y, cuando falla, usted sabe exactamente dónde buscar. Cada mensaje es una lista simple que puede inspeccionar.
• LlamaIndex justifica la dependencia en cuanto la recuperación se vuelve seria: varios documentos, estrategia de fragmentación, reordenamiento, filtrado por metadatos, búsqueda híbrida. Hacerlo a mano cuesta ~30–40% más código y peor precisión.
• LangGraph la justifica en agentes con estado: sus puntos de control (pausar a media tarea, guardar el estado completo y reanudar horas después) son de verdad difíciles de construir bien a mano.

La regla en la que coinciden la mayoría de los equipos no es un solo framework, sino un sistema por capas y una disciplina: empiece con la opción mínima que resuelve el requisito de hoy y agregue un framework cuando se tope con el problema específico para el que se construyó, no antes. Un problema de recuperación es una razón para agregar LlamaIndex. Un problema de estado es una razón para agregar LangGraph. Agregar cualquiera de los dos antes de tiempo solo compra mantenimiento para un futuro que quizá no llegue en la forma que usted imaginó.

Esta es la decisión que ya tomamos. Nuestro constructor de chatbots y Switchyard se apoyan a propósito en el SDK directo con una envoltura delgada: un registro de manejadores con lista blanca (una tabla de despacho simple, nunca eval), un armado del prompt que se puede leer en un solo archivo y una ruta crítica sin framework, para que la petición de un cliente no pague entre 100 y 500 ms de impuesto de orquestación en cada paso. Cuando un cliente necesita sus propios datos, agregamos una consulta acotada y protegida contra SSRF, no un framework, y mantenemos el código a la vista. Es la recomendación del artículo, a la que llegamos por nuestra cuenta.

Queda exactamente una decisión que todo framework fija en silencio: el nombre del modelo. LangChain lo pone en ChatOpenAI(model=…); un agente directo lo pone en la llamada. En ambos casos es una constante fijada al construir: una suposición congelada en el código. Esa suposición es lo único que nuestro enrutamiento medido convierte en una cifra: la capa transparente de calidad y costo bajo la decisión, no otra envoltura encima de ella. Y la señal honesta del artículo también es la señal de nuestra hoja de ruta: el día en que el bot de un cliente necesite una recuperación real sobre varios documentos, ese será el momento en que una capa de recuperación hecha a propósito se gane su lugar, y ni un paso antes.