LangChain v1.0 Orchestration Framework

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 1 de 20. Es increíblemente fácil crear un prototipo de agente de IA, pero es notoriamente difícil crear uno lo suficientemente fiable como para ponerlo en producción. La brecha entre una demo chula de fin de semana y una aplicación de nivel empresarial es enorme. La solución para cerrar esa brecha es lo que llamamos la Era de la Orquestación. Primero, aclaremos un malentendido muy común. La gente suele confundir LangChain con un proveedor de modelos. LangChain no entrena, aloja ni sirve grandes modelos de lenguaje. Es la capa de orquestación que se sitúa directamente sobre esos modelos. Piénsalo como el centro de control que gestiona cómo interactúa tu aplicación con el modelo que elijas usar. Para entender por qué es necesaria una capa de orquestación, tenemos que ver cómo ha evolucionado la tecnología. Allá por 2022, interactuar con un modelo de lenguaje era sencillo. Enviabas un string de texto y recibías un string de texto a cambio. Unos simples prompt chains eran suficientes para hacer el trabajo. No necesitabas un framework pesado para gestionar un flujo de trabajo básico de text-in, text-out. Podías escribir fácilmente un script donde el output del prompt A simplemente se pegaba en el prompt B. Pero a medida que avanzamos por 2025 y miramos hacia 2026, el panorama es completamente diferente. Los modelos ya no solo procesan texto plano. Ingieren y generan bloques multimodales complejos. Una sola interacción puede implicar enrutar un prompt del usuario, activar un tool call externo, procesar una imagen y devolver un bloque de datos estructurado. Un modelo podría devolver una petición de búsqueda en base de datos junto a un resumen de texto. Si el código de tu aplicación tiene que inspeccionar manualmente cada respuesta para averiguar si es un string, un tool call o un archivo de imagen, tu codebase se convertirá rápidamente en un desastre frágil e imposible de mantener. Aquí está la clave. Pasarle el contexto exacto a un modelo en el momento justo es mucho más difícil que simplemente elegir el modelo más potente del mercado. Puedes cambiar al motor de razonamiento más inteligente disponible, pero si recibe datos desordenados y sin estandarizar, toda la interacción fallará. Por eso, LangChain evolucionó de una simple librería de chaining a una capa de orquestación estandarizada para su versión 1.0. Proporciona un formato de mensaje estándar que funciona de forma consistente con todos los principales proveedores de modelos. En lugar de escribir lógica de parsing personalizada para cada API diferente, usas una estructura uniforme. Al estandarizar el formato del mensaje, LangChain garantiza que un tool call de un proveedor se vea exactamente igual en tu código que un tool call de un proveedor de la competencia. Defines una secuencia donde entra un mensaje del usuario, la capa de orquestación lo normaliza, lo envía al modelo, captura la respuesta multimodal y traduce esa respuesta de vuelta a un formato estándar que tu aplicación realmente pueda usar. Escribes la lógica de tu aplicación una sola vez y la capa de orquestación se encarga de la traducción. El modelo en sí ya no es toda la aplicación, es simplemente el motor de razonamiento, y la capa de orquestación es la que determina si ese motor realmente resuelve tu problema de negocio. Si quieres ayudarnos a seguir haciendo estos episodios, puedes apoyar el programa buscando DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar y sigue creando!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 2 de 20. ¿Qué pasaría si pudieras reemplazar todo tu complejo reasoning loop por un solo function call de diez líneas? Pasas horas escribiendo parsers y while-loops personalizados solo para conseguir que un modelo de lenguaje ejecute una función de forma fiable. La Unified Agent Abstraction es la arquitectura que te libera de este problema. Para entender por qué esto es importante, debemos aclarar una confusión común sobre las versiones anteriores del framework. En la versión cero punto x, los desarrolladores tenían que navegar por un laberinto de agent classes específicas. Tenías conversational agents, zero-shot agents y custom chains complejas. Si estás actualizando tu código, puedes olvidarte de todo eso. La Unified Agent Abstraction reemplaza por completo todas las chains antiguas y los legacy agents. Proporciona un entry point claro y estandarizado a través de una función llamada simplemente create agent. Esta función existe para gestionar el ReAct loop. ReAct significa Reason and Act. Cuando un usuario hace una pregunta compleja, un modelo de lenguaje no puede simplemente ejecutar código. Debe razonar sobre el problema, decidir tomar una acción, devolver un output de texto solicitando esa acción, y luego esperar una observation antes de poder razonar de nuevo. Gestionar este ciclo manualmente es tedioso. Tienes que parsear el texto generado por el modelo, mapearlo a una función local, ejecutar esa función, formatear el output, volver a pasarlo al modelo y evaluar si la tarea ha terminado. La función create agent abstrae todo este proceso de orquestación. Veamos una implementación sencilla usando una tool para consultar el tiempo. Primero, defines tu tool específica, quizás una función llamada get weather que recibe el nombre de una ciudad. A continuación, inicializas tu modelo de lenguaje elegido. Después viene la abstracción. Llamas a la función create agent y le pasas tres argumentos. Le pasas tu modelo de lenguaje, una lista que contiene tu tool get weather, y un system prompt que dicta las reglas para el agent. Este único call devuelve un objeto agent ejecutable. Finalmente, invocas este objeto con una user query, preguntando por el tiempo actual en Londres. Aquí está la clave del execution flow. Cuando invocas al agent, estás iniciando el ReAct loop. El agent envía la query y las descripciones de las tools al modelo. El modelo decide que necesita datos en tiempo real y genera un tool call estandarizado. La abstracción del agent intercepta este call automáticamente. Ejecuta tu tool get weather con el argumento Londres, toma los datos de temperatura resultantes y se los pasa de vuelta al modelo como una nueva observation. El modelo evalúa estos datos, se da cuenta de que tiene la respuesta a la user query y genera una respuesta final. No escribiste ni un solo loop, y no escribiste un output parser. Solo proporcionaste las tools, el modelo y las instrucciones. El poder de la Unified Agent Abstraction reside en establecer un límite arquitectónico estricto. Aísla completamente la mecánica del reasoning cycle, permitiéndote dedicar todo tu esfuerzo de ingeniería a perfeccionar la calidad de tus tools y la claridad de tus prompts. Eso es todo por ahora. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 3 de 20. Los distintos proveedores de modelos tienen APIs muy diferentes, lo que significa que probar un nuevo modelo suele obligarte a reescribir la mitad de tu aplicación. Acabas atascado con un proveedor simplemente porque el coste técnico de cambiar es demasiado alto. Estandarizar este caos es exactamente de lo que trata este episodio. Antes de entrar en los detalles de cómo LangChain soluciona esto, conviene aclarar una confusión común. Si has trabajado con modelos de lenguaje antiguos, probablemente estés familiarizado con las clases LLM legacy que aceptan un único string de texto sin formato como input. Los modelos de chat modernos son diferentes. Requieren estrictamente una secuencia estructurada de mensajes, donde cada mensaje tiene un rol específico asignado, como system, human o AI. Todo lo que vamos a comentar ahora se aplica a estos modelos de chat modernos, no a los antiguos de text completion. Cuando construyes una aplicación, hacer hardcoding de un proveedor específico crea un vendor lock-in inmediato. Para romper esta dependencia, LangChain introduce una única factory function llamada init chat model. Piénsalo como un traductor universal para inicializar clientes de inteligencia artificial. En lugar de importar una clase específica para OpenAI, otra para Anthropic y otra para Google, dependes exclusivamente de esta única función. Aquí está la clave. La función init chat model utiliza una sintaxis de string muy simple para saber qué construir. Proporcionas un string formateado con el nombre del proveedor, seguido de dos puntos, y seguido de la versión específica del modelo. Imagina un agente que actualmente se ejecuta en el GPT-5 de OpenAI. Inicializas tu modelo simplemente pasándole el string openai dos puntos gpt-5. Ahora, supón que Anthropic lanza un nuevo modelo que maneja mejor la generación de código, y quieres probarlo. Como usaste la función init chat model, no tocas la lógica de tu agente. No importas un nuevo paquete del cliente. Simplemente cambias ese único string de inicialización a anthropic dos puntos claude-sonnet-4-6. LangChain resuelve dinámicamente el string y carga la clase de integración subyacente correcta. Eso se encarga del modelo en sí, pero los proveedores también discrepan en los ajustes de configuración. Una API podría esperar un parámetro llamado max sampled tokens, mientras que otra espera max length. La función init chat model resuelve esto aceptando parámetros estándar. Cuando inicializas tu modelo, puedes pasar argumentos como temperature o max tokens directamente a la función. Si ajustas tu temperature a cero coma dos y max tokens a mil, LangChain mapea esos términos genéricos a las keys exactas del payload que requiera el proveedor que especificaste en tu string. Configuras tu modelo una sola vez usando la terminología estándar, y el framework lo traduce para la API de destino. Al separar el código de tu aplicación de los detalles de implementación específicos del vendor, ganas agilidad arquitectónica, lo que te permite evaluar modelos de la competencia en segundos en lugar de días. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 4 de 20. Si aún pasas strings de texto plano a tus modelos de lenguaje, estás limitando considerablemente tus aplicaciones. Los strings planos pierden contexto. No pueden contener de forma segura referencias a imágenes, resultados de ejecución de tools ni roles de interacción específicos. Para solucionar esto, LangChain utiliza objetos message estandarizados, que actúan como el lenguaje universal de los LLMs. Un message en LangChain es una estructura de datos que contiene un rol específico, el payload y metadatos opcionales. Los distintos proveedores de API gestionan los roles de conversación y los inputs multimodales de forma diferente en sus APIs raw. LangChain abstrae esta fricción en cuatro clases distintas. La primera es el SystemMessage. Este objeto establece las reglas de fondo, la personalidad o las restricciones estrictas para la interacción. A continuación está el HumanMessage, que representa el prompt del usuario o los archivos subidos. Luego tenemos el AIMessage, que captura la respuesta generada por el modelo. Finalmente, está el ToolMessage. Este objeto transporta específicamente el resultado de la ejecución de una función externa de vuelta al modelo, separando claramente el input raw del usuario de los datos factuales generados por el sistema. Orquestas las conversaciones pasándole un array de estos objetos message al modelo. Puedes construir manualmente este array para dar forma al output. Primero, creas una lista e insertas un SystemMessage asignándole al modelo el rol de un experto en poesía con formato estricto. Segundo, añades un HumanMessage pidiendo un haiku sobre migraciones de bases de datos. Aquí está la clave. No tienes que esperar a que el modelo genere la siguiente respuesta. Puedes instanciar manualmente un AIMessage e inyectarlo en el array justo después del prompt humano, con una línea inicial específica. Cuando le pasas todo este array al modelo, este interpreta tu AIMessage inyectado como su propio comportamiento pasado. Continuará el haiku sin problemas desde tu punto de partida exacto, respetando la estructura que le has impuesto. Cuando finalmente recibes un AIMessage de vuelta del modelo, necesitas extraer lo que realmente ha producido. Los desarrolladores suelen confundir el atributo content raw con el payload parseado. Cada objeto message tiene una propiedad content. Sin embargo, este atributo content raw refleja directamente lo que haya devuelto el proveedor de LLM específico. Dependiendo del proveedor del modelo y del prompt, esto podría ser un simple string de texto, o podría ser una lista de diccionarios muy anidada que contenga chunks de texto mixto, URLs de imágenes e identificadores de tools. Parsear esto manualmente hace que tu código sea increíblemente frágil. En lugar de leer el content raw, deberías usar la propiedad content blocks. La propiedad content blocks es la representación estandarizada y de tipado estricto de LangChain para el payload del message. Cuando lees de los content blocks, LangChain traduce la respuesta específica del proveedor en una lista uniforme de objetos block. Puedes iterar sobre esta lista de forma segura. Primero compruebas si un block es un text block, y si es así, extraes el payload de texto. A continuación compruebas si es un tool call block, y extraes los argumentos. Construir tu lógica de parseo en torno a la propiedad estandarizada content blocks es la única forma de garantizar que tu aplicación permanezca completamente desacoplada de los formatos de respuesta cambiantes de los proveedores de modelos individuales. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 5 de 20. Un agente de IA sin acceso al mundo exterior es solo un generador de texto. Para convertirlo en un sistema que realmente haga el trabajo, tienes que darle manos. Hoy hablamos de potenciar agentes con tools, específicamente usando el decorator at-tool. Un tool en LangChain es un puente entre el motor de razonamiento de un modelo de lenguaje y tus sistemas externos. Pero aquí hay un malentendido muy común. Muchos desarrolladores asumen que el modelo de lenguaje de alguna manera analiza la lógica dentro de su función de Python para averiguar cómo usarla. Pues no lo hace. El modelo de lenguaje nunca ve tu código de Python. Solo ve un schema que describe la función. Para crear un tool, escribes una función de Python estándar y colocas el decorator at-tool justo encima. Este decorator hace algo crucial. Inspecciona la signature de tu función, extrae el nombre de la función, lee los type hints de cada parámetro y parsea el docstring. Coge todos estos metadatos y los empaqueta en un formato estructurado que el modelo de lenguaje realmente puede leer. Como el modelo solo lee este schema generado, la precisión en tu código es crítica. Veamos un escenario. Supón que escribes una función llamada search database. Si le pones un docstring flojo que solo dice, busca en la base de datos, y omites los type hints por completo, el modelo de lenguaje va a ciegas. No sabe qué tipo de base de datos es, y no sabe qué argumentos pasarle. Podría intentar pasar una frase conversacional completa como query de búsqueda, haciendo que tu función de Python falle al ejecutarse. Aquí está la clave. Cuando usas el decorator at-tool, debes escribir tus docstrings para el modelo de lenguaje, no para el desarrollador humano. En lugar de una descripción vaga, escribes una instrucción clara, como, busca en la base de datos de clientes por dirección de email para recuperar el historial de facturación. Después, aplicas type hints estrictos a tus parámetros de entrada. Especificas que el argumento email debe ser un string. Incluso podrías añadir una descripción al propio argumento. Cada pieza de información de tipado que añades le da al modelo de lenguaje un límite más estricto sobre lo que tiene permitido generar. Cuando le pasas este tool recién decorado a un agente, el agente lee el schema detallado antes de hacer cualquier otra cosa. Cuando un usuario pregunta por el reembolso de un cliente, el agente escanea sus tools disponibles y reconoce que el tool search database es el ideal basándose en tu docstring preciso. Gracias a tu type hint estricto, sabe exactamente cómo formatear el argumento. Extrae el string del email del prompt del usuario, detiene su generación de texto y emite un tool call. LangChain intercepta ese tool call. Coge el string del email que generó el modelo, lo pasa a tu función de Python subyacente y ejecuta el código. Tu función habla con la base de datos, saca el historial de facturación y le devuelve los datos en crudo directamente a LangChain. Luego LangChain le pasa esos datos de vuelta al agente como una observation. El agente retoma su proceso de pensamiento, pero ahora tiene los datos reales que le acabas de proporcionar. La capacidad de actuar del modelo de lenguaje está completamente limitada por la calidad de la signature de tu función. Trata tus docstrings y type hints como restricciones de ingeniería estrictas, porque para el modelo de lenguaje, son las únicas instrucciones que existen. Eso es todo por este episodio. Gracias por escuchar, y sigue programando.

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 6 de 20. Si dependes de un modelo de lenguaje para pasar correctamente un token de autenticación o la identidad de un usuario a una tool de base de datos, te expones a una grave brecha de seguridad. El modelo no sabe quién es el usuario actual y, desde luego, no deberías confiar en que lo adivine. Necesitas una forma de pasar datos sensibles del backend directamente a tus tools, saltándote el modelo por completo. Esto es exactamente lo que resuelve inyectar el Tool Context. Cuando creas una tool, algunos argumentos están pensados para que el modelo los genere, como un search string o un rango de fechas. Otros argumentos son estrictamente para tu infraestructura de backend. Aquí es donde entra en juego el objeto ToolRuntime. Te permite inyectar configuración estática en una tool justo en el momento en que se ejecuta. Puede que pienses que basta con pasar un diccionario de configuración como un argumento normal de la tool y decirle al prompt que lo ignore. No lo hagas. Cuando defines un parámetro llamado config o runtime en la función de tu tool, LangChain los trata como palabras clave reservadas. Los oculta a propósito del esquema de la tool que se envía al modelo de lenguaje. El modelo nunca los ve. Solo ve los argumentos que se encarga de proporcionar. Esto significa que el modelo no puede alucinar una configuración falsa ni intentar saltarse tus límites de seguridad. Imagina un escenario concreto. Estás creando una tool get account info para una aplicación bancaria. La tool requiere un ID de usuario para recuperar los registros correctos de la base de datos. Si el modelo proporciona este ID, un prompt injection ingenioso podría engañar al modelo para que solicite datos de un cliente completamente distinto. En su lugar, diseñas la función de tu tool para que acepte dos argumentos. El primero es el tipo de cuenta, que proporcionará el modelo. El segundo es un argumento llamado runtime. Dentro del código principal de tu aplicación, antes de invocar la tool, rellenas este objeto runtime. En concreto, utilizas la propiedad runtime punto context. Metes el ID de usuario real y autenticado de la persona que hace la petición directamente en este contexto. También podrías meter ahí una conexión activa a la base de datos o la dirección de un endpoint regional. El modelo evalúa la petición del usuario y decide llamar a la tool get account info. Analiza el esquema, ve que necesita proporcionar un tipo de cuenta y devuelve la palabra ahorros. No devuelve nada más. LangChain intercepta esta llamada de ejecución. Toma el tipo de cuenta del modelo, lo combina de forma transparente con el runtime context de tu backend y ejecuta la función de Python. Dentro de la función, extraes el ID de usuario del contexto y ejecutas tu consulta a la base de datos de forma segura. Este mecanismo te da una inyección de dependencias segura. Puedes inyectar cualquier cosa que tu tool necesite para funcionar y que el modelo no tenga por qué saber. Las API keys para servicios de facturación de terceros, las rutas del sistema de archivos o los tenant identifiers en una arquitectura multi-tenant pertenecen al runtime context. Esta es la clave. Ocultar los argumentos de configuración detrás del runtime context garantiza que tu modelo actúe puramente como un router lógico, mientras que el código de tu aplicación mantiene un control absoluto y sin concesiones sobre el acceso a los datos y la seguridad de ejecución. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 7 de 20. Sin memoria, cada interacción con tu agente de IA parece una escena de 50 primeras citas. El modelo empieza completamente en blanco, olvidando todo lo que comentaste hace unos segundos. La solución es la persistencia a nivel de thread. Los modelos de lenguaje grandes son totalmente stateless. Procesan texto y devuelven texto, sin conservar absolutamente nada entre requests. Para mantener una conversación, un agente necesita una forma de almacenar y recuperar interacciones pasadas. En el contexto de una única sesión activa, gestionamos esto mediante memoria a corto plazo, que se administra como parte del state del agente y se persiste usando checkpointers. La gente suele pensar que la memoria en IA es una capacidad interna del modelo donde la red neuronal te recuerda por arte de magia. No es así. La memoria es simplemente el historial de mensajes. La persistencia a nivel de thread consiste simplemente en coger la lista de mensajes en curso, guardarla en una base de datos después de cada paso y volver a inyectarla en el prompt antes de que el modelo vea el siguiente input. El checkpointer se encarga de esto automáticamente, para que no tengas que escribir a mano la lógica de almacenamiento y recuperación. En LangGraph, el state se guarda por thread. Un thread representa una sesión continua. Para habilitar esto, necesitas un checkpointer. Para desarrollo y testing, puedes usar el In Memory Saver. Al compilar el graph de tu agente, pasas este objeto saver como argumento del checkpointer. Esta integración le dice al agente que, al final de la ejecución de cada node, debe hacer un snapshot de su state actual y pasárselo al saver. El state incluye todo lo que hayas definido en tu graph, que normalmente es una lista continua de mensajes. Veamos un escenario concreto. Compilas tu agente con un In Memory Saver. Ahora, quieres invocar al agente. En lugar de pasar solo un mensaje de usuario, también pasas un objeto de configuración que contiene un thread ID específico. Usemos el valor de string conversation one. Envías el mensaje, me llamo Bob. El agente lo recibe, genera un saludo cortés y termina. Por debajo, el checkpointer guarda el state actualizado, que ahora contiene el mensaje que indica que te llamas Bob, indexado bajo conversation one. Más tarde, invocas al agente por segunda vez. Envías un nuevo mensaje preguntando, cómo me llamo. Lo crucial aquí es que pasas exactamente el mismo objeto de configuración con el thread ID conversation one. Aquí está la clave. Antes de que el agente dirija tu nueva pregunta al modelo, el checkpointer intercepta el proceso. Busca conversation one en el In Memory Saver. Recupera el snapshot del state de tu turno anterior, carga el historial de mensajes guardado y añade tu nueva pregunta al final. El modelo de lenguaje recibe el contexto histórico completo, ve el mensaje anterior donde te presentaste y responde correctamente que te llamas Bob. Si cambiaras el thread ID a conversation two y preguntaras cómo te llamas, el checkpointer buscaría ese nuevo ID, no encontraría ningún state existente e inicializaría una lista de mensajes nueva y vacía. El agente no tendría ni idea de quién eres. El thread ID es la única clave que vincula una secuencia de llamadas al modelo aisladas y stateless en una sesión coherente de memoria a corto plazo. El checkpointer abstrae el trabajo repetitivo de gestionar arrays de mensajes y consultar bases de datos, garantizando que tu agente pueda reanudar su trabajo exactamente donde lo dejó, siempre que le pases el thread ID correcto. Gracias por escuchar. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 8 de 20. Cuanto más se alarga una conversación, más se distrae un large language model con información obsoleta. Pierdes precisión mientras pagas mayores costes de tokens por cada turno. Comprimir el contexto con un middleware soluciona exactamente este problema. A medida que crece el historial del chat, acabas alcanzando el límite de la context window de tu modelo. Incluso antes de llegar a ese límite estricto, pasarle miles de tokens de conversaciones antiguas degrada el rendimiento. La solución es el SummarizationMiddleware de LangChain. En lugar de simplemente cortar los mensajes antiguos, los comprime en un único bloque de resumen. Esto conserva el significado semántico de la conversación sin el enorme overhead de tokens. Hay un malentendido muy común sobre cómo se ejecuta esto. La gente suele asumir que el agent principal tiene que hacer el resumen por sí mismo. No es así, y la verdad es que no debería. Quieres que tu agent principal se ejecute en tu modelo más inteligente y capaz para manejar la lógica compleja. Resumir es una tarea mucho más sencilla. Le asignas un modelo más pequeño y barato al SummarizationMiddleware exclusivamente para este trabajo. Configurar el middleware requiere definir dos parámetros principales. El primero es el trigger. El trigger le dice al middleware cuándo debe intervenir. Puedes configurar el trigger para que se active cuando el recuento total de tokens de la conversación llegue a los 4000 tokens. El segundo parámetro es la keep condition. Esto le dice al middleware cuánto contexto reciente debe dejar completamente intacto. Podrías establecer el valor de keep en 20, lo que significa que los 20 mensajes más recientes se quedan intactos. Este es el flujo lógico en la práctica. Tu usuario está chateando con el agent principal. La conversación crece. En el siguiente turno, el historial total de mensajes cruza el umbral de los 4000 tokens. Antes de que el agent principal siquiera vea el nuevo input del usuario, el SummarizationMiddleware intercepta la request. Escanea el historial e identifica todo lo que sea más antiguo que los 20 mensajes más recientes. Coge ese chunk más antiguo de la conversación y se lo pasa a tu modelo más pequeño designado. Digamos que configuraste el middleware para usar gpt-4.1-mini. Ese modelo más pequeño lee los mensajes antiguos y genera un párrafo conciso resumiendo lo que se ha hablado. Luego, el middleware reescribe el array del historial. Reemplaza todos esos mensajes antiguos individuales con un único system message que contiene el nuevo resumen. Si ya había un resumen más antiguo de un ciclo de compresión previo, el middleware lo incluye en el prompt para que el nuevo resumen actualice la narrativa en curso. El paquete final que se envía a tu agent principal está altamente optimizado. Contiene el nuevo mensaje de resumen, seguido de los 20 mensajes recientes sin comprimir, seguidos del último input del usuario. Aquí está la clave. El agent principal nunca se da cuenta de que el historial se ha comprimido en segundo plano. Simplemente recibe una context window limpia y muy relevante. Conservas el significado semántico a largo plazo del chat, mantienes el modelo enfocado y reduces drásticamente tus costes de tokens en cada turno posterior. Si estos episodios te resultan útiles y quieres apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 9 de 20. Desarrollar software que dependa de parsear respuestas en lenguaje natural con expresiones regulares es una bomba de relojería. Le pides a un modelo de lenguaje un objeto de datos simple y te devuelve datos perfectos, excepto que añade un saludo al principio y lo envuelve todo en formato markdown. Tu parser falla al instante. Los formatos de datos garantizados son la forma de solucionar esto para siempre. El structured output obliga al modelo de lenguaje a devolver la información exactamente como la espera tu aplicación. Convierte la generación de texto impredecible en objetos de software fiables. Imagina un sistema que procesa mensajes de atención al cliente entrantes. Un usuario envía un párrafo desordenado y sin estructura quejándose de un problema de login, pero escondiendo su nombre, email y número de teléfono en algún lugar del texto. Necesitas esos tres datos para lanzar una consulta a la base de datos. En lugar de escribir un prompt complejo rogándole al modelo que formatee su respuesta correctamente, defines un modelo Pydantic estándar. Creas una clase llamada ContactInfo y defines name, email y phone como campos obligatorios. Luego, simplemente le pasas este schema de Pydantic al parámetro response format de la configuración de tu modelo de lenguaje. No necesitas proporcionar ejemplos ni escribir scripts de validación personalizados. Esta es la parte que importa. Cuando le pasas ese schema de Pydantic, LangChain determina automáticamente la forma más fiable de aplicarlo. Lo hace seleccionando de forma transparente entre dos rutas de ejecución diferentes. Primero, comprueba si el modelo de lenguaje que has elegido tiene una feature oficial de structured output integrada en su API. Si la tiene, LangChain autoselecciona la Provider Strategy. Esta estrategia envía tu schema directamente al provider, aprovechando sus restricciones nativas server-side para garantizar el formato de salida. Pero el hardware cambia y los modelos se sustituyen. Si decides usar un modelo diferente que no tiene structured output nativo, LangChain detecta esta falta de capacidad. Automáticamente hace un fallback a la Tool Strategy. Por debajo, traduce tu schema ContactInfo a una function signature. Le dice al modelo que hay una tool ficticia que requiere exactamente un name, un email y un phone para ejecutarse. El modelo intenta llamar a esta tool, y al hacerlo, genera los argumentos estructurados exactos que necesitas. El código de tu aplicación nunca tiene que cambiar para adaptarse al cambio. Cuando la operación termina, los desarrolladores a menudo buscan sus datos en el lugar equivocado. Podrías asumir que el output se devuelve como raw text que todavía tienes que parsear. No es raw text. LangChain intercepta el payload e instancia el objeto Pydantic por ti. Coloca este objeto Python completamente validado directamente en el state de tu aplicación. Lo encontrarás capturado en la key structured response de tu dictionary de state. Simplemente haces referencia a esa key, e inmediatamente tienes tu objeto ContactInfo, con campos type-safe listos para pasar al resto de tu aplicación. Al trasladar la carga de la validación del schema desde la lógica de parsing personalizada hacia la capa del framework, las integraciones de tu modelo de lenguaje se vuelven tan predecibles como una llamada a una API estándar. Gracias por escuchar. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 10 de 20. Si tu agente falla silenciosamente en producción, suele ser porque no estás supervisando lo que sucede entre los pasos de su loop de razonamiento. El modelo falla, el loop se rompe y te quedas mirando un run incompleto. Interceptar el loop del agente con un middleware personalizado es la forma de recuperar el control. Cuando un agente ejecuta un ciclo ReAct, le cede el control constantemente al modelo de lenguaje. El middleware proporciona hooks para ejecutar tu lógica justo cuando la necesitas durante ese intercambio. Hay dos tipos principales de hooks que vas a usar: hooks de estilo node y hooks de estilo wrap. Un error común es tratarlos indistintamente. Los hooks de estilo node se ejecutan secuencialmente. Los hooks de estilo wrap realmente encapsulan la ejecución y pueden capturar excepciones. Los hooks de estilo node usan decorators llamados before model y after model. Cuando le añades un hook before model a una función, el framework ejecuta tu lógica por completo, y solo entonces llama a la API del modelo de lenguaje. Cuando el modelo responde, se ejecuta un hook after model. Estos hooks son excelentes para registrar el prompt exacto enviado a la API, inyectar contexto o limpiar caracteres no válidos del output de texto final. Pero como se ejecutan estrictamente en secuencia, no ofrecen ninguna protección contra fallos. Si la API del modelo de lenguaje da un timeout, tu hook after model nunca se ejecuta. El error se propaga y crashea todo el loop del agente. Esta es la parte que importa. Si necesitas gestionar la inestabilidad, usas un hook de estilo wrap. El decorator para esto es wrap model call. Un hook wrap envuelve por completo la ejecución del modelo. Tu función se ejecuta, hace algo de setup, y luego le cede explícitamente el control al modelo. Como tu código personalizado envuelve la llamada de red real, puedes meter esa ejecución dentro de estructuras estándar de manejo de errores. Considera crear un middleware wrap model call para gestionar los rate limits de la API con un loop de reintentos con exponential backoff. Escribes una función decorada con wrap model call. Dentro de esta función, creas un loop de reintentos. Pones el comando que le cede el control al modelo dentro de un bloque try. Si el modelo tiene éxito, capturas la respuesta, la devuelves y el loop termina. Si el modelo lanza un error, tu bloque catch lo intercepta. En lugar de hacer fallar al agente, tu bloque catch activa una pausa. Calculas un pequeño delay, esperas, y luego dejas que el loop intente la llamada de nuevo, duplicando el delay cada vez. El orchestrator del agente nunca ve los fallos. El middleware captura las excepciones, gestiona la lógica de reintentos de forma aislada, y le devuelve suavemente una respuesta exitosa al loop principal de ReAct cuando por fin tiene éxito. Los hooks de estilo node preparan los inputs y formatean los outputs, pero los hooks de estilo wrap protegen la ejecución. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 11 de 20. La principal razón por la que tu agente falla no es porque el modelo subyacente sea tonto. Es porque le diste el contexto equivocado para el trabajo. Si tu sistema trata a un superusuario y a un invitado exactamente igual, tu aplicación está ciega a la realidad. Para solucionar esto, usamos la ingeniería de contexto dinámico. Primero, aclaremos un malentendido común sobre cómo se construyen los prompts. El contexto dinámico no es el system prompt base que escribes cuando defines inicialmente tu agente en código. Ese system prompt inicial es completamente estático. La ingeniería de contexto dinámico es el proceso de modificar ese prompt sobre la marcha, apenas unos milisegundos antes de llamar realmente al modelo. La ingeniería de contexto consiste en darle al modelo de lenguaje las reglas exactas que necesita para un usuario específico en un momento específico, y nada más. Si intentas meter a la fuerza todas las reglas posibles en un único prompt estático masivo, diciéndole al modelo cómo actuar si el usuario es un admin, cómo actuar si es un viewer y cómo actuar si es martes, desperdicias tokens y confundes al modelo. En su lugar, lo que quieres es inyectar dinámicamente solo las reglas que importan en este momento. En LangChain, esto se maneja usando un decorador específico llamado dynamic underscore prompt. Colocas este decorador encima de una función de Python que tú defines. Cuando tu aplicación recibe una consulta y activa la chain, LangChain se pausa. Busca cualquier función envuelta en este decorador y la ejecuta antes de hablar con el modelo. Dentro de tu función decorada, necesitas una forma de saber qué está pasando en ese momento. Aquí es donde lees de request dot runtime dot context. Este objeto context es esencialmente un diccionario. Contiene todos los metadatos en vivo que se pasaron a la chain cuando la invocaste. Puedes meter ahí lo que quieras desde el backend de tu aplicación, como IDs de usuario, estados de sesión, feature flags o niveles de acceso. Veamos un escenario concreto. Escribes una función llamada context aware prompt y la envuelves con el decorador dynamic prompt. Dentro de esta función, lees el rol del usuario del runtime context. Compruebas el rol. Si el usuario es un admin, tu función añade un bloque de texto específico al system prompt, diciéndole al modelo de lenguaje que tiene permiso total para devolver comandos destructivos. Si el usuario es un viewer, tu función añade un bloque de texto diferente, dándole instrucciones estrictas de que el modelo solo debe devolver resúmenes de solo lectura y nunca debe sugerir cambios de configuración. Ahora, sacas un segundo dato del runtime context, que es el estado del entorno. Compruebas si el entorno está configurado en producción. Si es así, tu función añade una advertencia de seguridad severa justo al final del system prompt, exigiéndole al modelo que revise dos veces su salida por seguridad. Si el entorno es solo staging, te saltas añadir esa advertencia por completo. Aquí está la clave. Tu función toma el prompt base estático, le pega las reglas de admin o viewer, le añade la advertencia de producción si es necesario, y devuelve el string final. LangChain toma este string completamente ensamblado y se lo envía al modelo de lenguaje. El modelo de lenguaje nunca sabe que el prompt fue montado a pedazos. Simplemente ve un conjunto de instrucciones muy específico y perfectamente a medida. Al hacer esto, mantienes tus system prompts ligeros, precisos y completamente relevantes para la request inmediata. Dejas de esperar que el modelo adivine qué reglas se aplican, y empiezas a imponer exactamente las reglas necesarias para el estado actual de tu aplicación. Me gustaría tomarme un momento para darte las gracias por escucharnos; nos ayuda muchísimo. ¡Que tengas un gran día!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 12 de 20. Un solo log de chat con un número de tarjeta de crédito sin ocultar puede comprometer instantáneamente el cumplimiento normativo de toda tu aplicación. No puedes confiar en que un modelo de lenguaje ignore los datos sensibles, y pedirle que se autocensure es lento e impredecible. Aquí es donde entra en juego la IA segura con guardrails deterministas. Los guardrails deterministas son comprobaciones hardcodeadas y basadas en reglas. Se basan en patrones y lógica predecibles, como expresiones regulares o algoritmos fijos, en lugar de pedirle a otro modelo de lenguaje que evalúe el texto. Al evitar la llamada de red a una IA, se ejecutan en milisegundos y prácticamente no cuestan nada. Si estás desarrollando para producción, esta capa determinista es obligatoria para la seguridad. En el framework, implementas esto usando el PII Middleware. Un error frecuente que cometen los desarrolladores es intentar filtrar la información sensible a posteriori, analizando el output del modelo. Pero para proteger la privacidad del usuario, el PII Middleware está diseñado para interceptar el mensaje raw justo cuando el usuario le da a enviar. Procesa el texto antes de que se inicie la llamada al modelo. Configuras este comportamiento explícitamente poniendo el parámetro apply to input a true. Veamos un ejemplo con un agente de atención al cliente. Un usuario estresado envía un mensaje indicando que su cuenta está bloqueada, incluyendo su dirección de email personal, y luego pega su número de tarjeta de crédito de dieciséis dígitos para verificar su compra. Si tu código le pasa esa string raw a un proveedor de IA de terceros, has violado la normativa básica de datos. Necesitas una estrategia para neutralizar el texto, y el middleware te da tres acciones integradas: block, redact y mask. Si usas la estrategia block, el middleware actúa como un muro infranqueable. En el momento en que detecta el formato de la tarjeta de crédito, lanza un error estricto y termina la chain por completo. La request se rechaza directamente. Si eliges la estrategia redact, el middleware elimina quirúrgicamente los datos específicos y pone un placeholder limpio. La dirección de email personal se elimina por completo de la string y se reemplaza por la palabra email entre corchetes. El modelo de lenguaje sigue leyendo una oración coherente y entiende que se proporcionó un email, pero los datos reales ya no están. La tercera estrategia es mask. El masking conserva una parte segura de los datos originales. El middleware reemplaza los primeros doce dígitos de la tarjeta de crédito con asteriscos, dejando expuestos solo los últimos cuatro números. Esto es muy efectivo cuando tu sistema backend necesita verificar una cuenta sin exponer el registro financiero completo. Implementar esto requiere configurar el middleware antes de que se ejecute tu chain. Instancias el PII Middleware y le pasas una lista de entidades objetivo. En este caso, especificas email y tarjeta de crédito. Luego, asignas las estrategias elegidas a esas entidades, por ejemplo, eligiendo redact para el email y mask para la tarjeta. Finalmente, acoplas este componente middleware a tu chain principal, asegurándote de configurar el parámetro apply to input. En el momento en que el usuario envía su mensaje, las reglas deterministas limpian el texto, y la IA solo recibe un prompt sanitizado. Aquí está la clave. La forma más segura de manejar información personal sensible en cualquier arquitectura de IA generativa es garantizar que el modelo de lenguaje nunca llegue a verla. Eso es todo por ahora. ¡Gracias por escuchar, y seguid construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 13 de 20. Un agente autónomo es increíblemente potente, justo hasta el momento en que envía de forma autónoma un borrador de tus datos financieros al cliente equivocado. Algunas acciones son simplemente demasiado arriesgadas para ejecutarlas sin la supervisión de un humano. Precisamente por eso utilizamos la pausa para aprobación humana. Los agentes ejecutan tools automáticamente basándose en los prompts del usuario. Este comportamiento es ideal para leer datos, pero es peligroso para acciones destructivas o irreversibles. Necesitamos una forma de pausar la ejecución, preguntarle a un humano si una acción es segura, y luego reanudar o abortar. Antes de hablar de la mecánica, tenemos que aclarar un punto de fallo muy común. A veces, los ingenieros configuran interrupts y luego se preguntan por qué el agente simplemente se cuelga o se reinicia. Tienes que tener un checkpointer habilitado. No puedes pausar un agente si no puede recordar dónde se quedó. Toda la memoria del agente y su progreso actual deben guardarse en la persistence layer mientras espera a que un humano responda. Sin checkpointer, no hay pausa. Con la persistencia activa, puedes gestionar la ejecución de tools de forma segura usando el middleware Human In The Loop. Imagina una configuración donde tu agente tiene dos tools: una tool de búsqueda y una tool para borrar la base de datos. Quieres que el agente busque libremente, pero bajo ningún concepto quieres que borre tablas sin permiso. Cuando configuras este middleware, le pasas un argumento llamado interrupt on. Le pasas los nombres específicos de las tools que requieren supervisión. En nuestro caso, configuras interrupt on para que vigile solo la tool de borrar la base de datos. El middleware ignora la tool de búsqueda y esta se ejecuta inmediatamente cada vez que el agente la llama. Sin embargo, cuando el agente decide que necesita usar la tool de borrar la base de datos, el middleware intercepta la petición. Pausa el graph, guarda el estado actual en tu checkpointer y detiene la ejecución por completo. El graph queda ahora suspendido en la persistence layer, a la espera de intervención humana. El operador humano revisa la tool call pendiente y tiene tres formas de responder al middleware. El primer tipo de decisión es aprobar. El humano mira los parámetros que ha generado el agente, está de acuerdo en que son correctos y envía un comando de aprobación. El graph se despierta y ejecuta el borrado exactamente como el agente lo había planeado. El segundo tipo de decisión es rechazar. El operador ve que el agente está intentando borrar el objetivo equivocado y envía un rechazo. La tool no se ejecuta. En su lugar, el agente recibe una observación indicando que la acción fue bloqueada por un humano. Luego, el agente procesa este feedback y puede intentar un enfoque diferente o pedirle una aclaración al usuario. Aquí está la clave. La tercera opción es editar. A veces el agente casi acierta pero comete un error menor, como apuntar al entorno de producción en lugar del entorno de staging. En lugar de rechazar la acción por completo y obligar al agente a razonar el problema de nuevo, el operador puede modificar los parámetros de entrada de la tool directamente. El humano cambia el entorno de destino a staging y envía la tool call corregida. El agente se reanuda y ejecuta la acción usando los parámetros modificados, avanzando sin problemas. Al usar este middleware, proteges tu sistema de errores peligrosos. Pausar para pedir aprobación humana no solo previene catástrofes, sino que transforma a tu agente de una entidad impredecible en un colaborador supervisado que puede manejar con seguridad operaciones de alto riesgo. Eso es todo por este episodio. ¡Gracias por escuchar y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 14 de 20. A los usuarios no les importa esperar diez segundos por una respuesta compleja, siempre y cuando les muestres qué está haciendo el cerebro durante esos diez segundos. Una pantalla en blanco parece una aplicación rota. La solución a la latencia percibida es el feedback del agent en tiempo real. Para solucionar la pantalla en blanco, LangChain expone un parámetro llamado stream mode cuando ejecutas tu agent o graph. Controla exactamente qué tipo de datos devuelve el agent por la conexión mientras se está ejecutando. El primer modo que debes conocer es el messages mode. Este se encarga del clásico efecto de escritura. Hace stream de los tokens raw del modelo de lenguaje a medida que se generan. Si el modelo está escribiendo un párrafo, tu aplicación recibe los chunks de texto uno a uno, permitiendo que tu interfaz de usuario se actualice de forma fluida en lugar de esperar el bloque de texto entero. La gente suele confundir hacer stream de los tokens de la respuesta final con hacer stream del razonamiento intermedio. Son cosas totalmente diferentes. Si tu agent decide llamar a una tool de búsqueda, la generación de tokens se detiene. El modelo de lenguaje se queda esperando a que la tool termine. Si esa tool tarda cinco segundos en ejecutarse, tu interfaz de usuario se congela durante cinco segundos. El messages mode por sí solo no le dice al usuario qué está haciendo realmente el agent en segundo plano. Solo muestra lo que el modelo de lenguaje está diciendo. Para solucionar el problema de la tool silenciosa, usas el custom mode. El custom mode permite que tus tools y nodos internos emitan sus propias actualizaciones de estado en tiempo real directamente al stream. Para implementar esto, usas una utilidad de LangChain llamada get stream writer. Llamas a esta función dentro del código de tu tool. Te devuelve un objeto writer, que puedes usar para emitir eventos custom de vuelta al cliente en cualquier momento durante la ejecución de la tool. Piensa en una tool lenta para consultar el tiempo. Tu agent recibe un prompt pidiendo el pronóstico y decide llamar a la tool del tiempo. Dentro de la función de Python para esa tool, coges el stream writer. A medida que la tool empieza a consultar una API remota lenta, usas el writer para emitir un evento custom con un estado como Acquired data. Tu frontend recibe este evento custom inmediatamente y muestra un spinner de carga con ese texto. El usuario sabe que el agent está trabajando. Una vez que la API remota devuelve los datos, la tool termina y el modelo de lenguaje retoma el control. Toma los datos raw del tiempo, formula una respuesta amigable para el usuario, y el stream de messages vuelve a arrancar, escribiendo el pronóstico final en la pantalla. Aquí está la clave. No tienes que elegir solo un modo. Puedes pasar una lista que contenga tanto messages como custom al parámetro stream mode. LangChain intercalará automáticamente los tokens del modelo de lenguaje y los logs de tu tool custom en un único feed continuo. Tu frontend simplemente comprueba el tipo de evento a medida que llega. Si es un evento custom, actualizas el indicador de estado. Si es un evento message, añades el token a la burbuja de chat. La latencia percibida cae a cero porque el sistema siempre le está hablando al usuario. Si quieres ayudar a que estos episodios sigan llegando, puedes apoyar el programa buscando DevStoriesEU en Patreon. Gracias por escuchar, ¡feliz coding a todos!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 15 de 20. Para crear un asistente verdaderamente personalizado, este debe recordar que prefieres respuestas breves, incluso si se lo dijiste hace tres semanas en un chat completamente diferente. Si solo dependes de la memoria de conversación estándar, esa preferencia desaparece en cuanto inicias un nuevo thread. El mecanismo que evita esta amnesia es la persistencia entre sesiones usando el paradigma de Store. Muchos desarrolladores confunden el checkpointer con el store. Aquí está la diferencia. Un checkpointer gestiona el state a corto plazo. Recuerda un único thread de conversación. Cuando el usuario crea un nuevo chat, el checkpointer empieza de cero. El store trasciende esos límites del thread. Permite que tus agentes persistan y recuperen información globalmente, en todas las interacciones con un usuario específico. En esencia, la memoria a largo plazo en LangChain es simplemente un store jerárquico de key-value. Persiste documentos JSON. La jerarquía se basa en namespaces. Un namespace es una secuencia de strings que funciona exactamente como la ruta de una carpeta en tu ordenador. Si quieres guardar datos de perfil, puedes usar un namespace que contenga el string users, seguido del identificador de usuario. Dentro de ese namespace, guardas elementos. Cada elemento requiere una key única de tipo string y un dictionary que represente el valor JSON. Aquí es donde la cosa se pone interesante. Las tools interactúan con este store directamente a través del runtime context. Nunca pasas el store manualmente a través de tu graph state. Considera una tool personalizada llamada save user info. Su función es capturar la preferencia de idioma hablado. Durante el setup, inicializas tu aplicación con un store de respaldo, como un in-memory store para pruebas locales. Dentro de la lógica de tu tool, accedes a la instancia del store directamente desde la runtime configuration inyectada. Extraes el identificador de usuario del context actual. Luego, llamas al método put del store. Le pasas la tupla del namespace que contiene la palabra users y el ID de usuario. Defines una key, como language preference, y finalmente pasas el dictionary JSON que contiene el valor, por ejemplo, español. El store persiste este documento. Semanas después, el usuario inicia una conversación completamente nueva. El thread state está vacío. Pero como el agente tiene acceso a una retrieval tool, puede llamar al método get del runtime store usando exactamente el mismo namespace y key. Recupera el documento JSON, lee la preferencia y responde inmediatamente en español. Separar el context conversacional a corto plazo de la memoria fáctica a largo plazo mantiene tu aplicación ligera. El checkpointer no se sobrecarga con años de historial del usuario, y el state permanece limpio. El store solo carga los documentos JSON específicos que el agente decide recuperar explícitamente. Tratar el context y la persistencia como dos sistemas completamente distintos es la única manera de escalar un agente de forma fiable. El checkpointer guarda el presente, mientras que el store guarda el pasado. Eso es todo por hoy. Gracias por escuchar, ve a construir algo genial.

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 16 de 20. Cuando tu único agente de IA empieza a fallar por su enorme lista de tools y sus instrucciones contradictorias, meterle una context window más grande no va a solucionar el problema. Es hora de dejar de construir un script monolítico y empezar a contratar a un equipo. Aquí es precisamente donde entra en juego el paradigma multiagente. Construimos sistemas multiagente porque los agentes individuales se chocan contra un muro cognitivo. Dale a un agente treinta tools, cinco páginas de system prompts y un historial de conversación larguísimo, y perderá el foco. Llamará a la tool equivocada u olvidará las restricciones. El enfoque multiagente divide todo esto. Permite el desarrollo distribuido, donde diferentes equipos gestionan diferentes agentes. Permite la ejecución en paralelo. Y lo más importante, garantiza un estricto aislamiento de contexto. Hoy nos centramos en una arquitectura específica llamada patrón de Subagents. Esto implica un agente supervisor principal que delega tareas a subagents especializados. La gente suele confundir un supervisor con un simple router. Un router es solo una función estática que mira una query y la envía por una ruta fija. Un supervisor es un agente activo y pensante. Mantiene el state de la conversación, decide qué subagents invocar a lo largo de múltiples turnos y sintetiza sus respuestas. Aquí está la clave. Los subagents proporcionan un aislamiento de contexto perfecto. Cuando el supervisor le pide a un subagent que haga algo, el subagent arranca con una context window completamente limpia. Solo tiene las instrucciones y tools específicas que necesita para su trabajo exacto. El subagent puede cometer errores, llamar a tools tres veces y llenar su propio scratchpad mientras averigua la respuesta. El supervisor nunca ve ese desorden. Solo recibe el resultado final limpio. Esto protege a tu agente principal del context bloat y evita las alucinaciones. Para conectar el supervisor con los subagents, envuelves los subagents como tools. Hay dos maneras de hacerlo en LangChain. El primer método es tool-per-agent. Le das al supervisor una tool específica para cada subagent. Si tienes cinco subagents, el supervisor tiene cinco tools. El segundo método es una single-dispatch tool. Aquí, el supervisor recibe exactamente una tool llamada algo así como delegate task. Esta tool requiere dos inputs: el nombre del agente target y la descripción de la tarea. Imagina un escenario single-dispatch. Tienes un agente principal, un agente de investigación y un agente de redacción. Un usuario pide un informe de mercado complejo. El agente principal decide que necesita datos primero. Llama a la single-dispatch tool, pasándole el agente de investigación como target y la query de mercado como payload. El agente de investigación arranca en su propio contexto aislado, busca en la web, parsea documentos y devuelve un párrafo de resumen. El agente principal recibe este texto. A continuación, el agente principal vuelve a llamar a la dispatch tool, esta vez apuntando al agente de redacción, pasándole el resumen de la investigación y las instrucciones de formato. El agente de redacción redacta el informe final y se lo devuelve al agente principal, quien se lo entrega al usuario. Puedes ejecutar estas subtareas de forma diferente según tus necesidades. Puedes ejecutar los subagents de forma síncrona, donde el supervisor espera a que el agente de investigación termine antes de realizar cualquier otra acción. Si tienes tareas independientes, como investigar a tres competidores diferentes, puedes ejecutar los subagents de forma asíncrona. El supervisor despacha las tres tareas a la vez, se ejecutan en paralelo, y el supervisor espera a que todas devuelvan un resultado antes de continuar. Agrupar tareas en subagents no es solo para organizar tu código, se trata de controlar estrictamente lo que el modelo de lenguaje se ve obligado a mantener en memoria en un momento dado. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 17 de 20. No necesitas cargar el cerebro de tu agente con todos los escenarios posibles desde el principio. Meter cincuenta páginas de instrucciones en un solo system prompt solo hace que tu modelo se confunda, sea más lento y más caro. Solo necesitas enseñarle a pedir el manual adecuado cuando llegue el momento. Este es el mecanismo principal detrás de los State-Driven Agents. Los State-Driven Agents funcionan bajo un principio muy simple. El comportamiento del agente cambia dinámicamente basándose en el state actual de la aplicación. Manejamos esto usando dos patrones principales, que son Skills y Handoffs. Ambos patrones dependen de tools para actualizar las variables de state, que a su vez dictan qué pasa después en el workflow. Veamos primero el patrón de Skills. Este patrón trata sobre la exposición progresiva de conocimiento. En lugar de darle a un agente todas sus instrucciones al principio, le das una tool. Cuando el agente decide que necesita más información para resolver un problema, llama a esta tool. La tool se ejecuta, pero hace mucho más que simplemente devolver un string al modelo. Actualiza una variable de state específica en tu aplicación. Tu capa de orquestación monitoriza este state. Cuando detecta el cambio, inyecta dinámicamente un nuevo set de instrucciones o capacidades en el system prompt del agente para el siguiente turno. Piensa en un agente de atención al cliente estándar. Al principio, su único trabajo es averiguar qué quiere el cliente. Un usuario pregunta por un producto roto. El agente llama a una tool para recoger un ID de garantía. La ejecución de esta tool actualiza una variable de state para indicar que hay una reclamación de garantía activa. La aplicación lee este nuevo state y carga dinámicamente una skill especializada en reembolsos en el prompt. Esta skill podría incluir las reglas específicas para procesar devoluciones y acceso a una base de datos de inventario segura. Las capacidades del agente evolucionaron a mitad de la conversación, impulsadas completamente por una actualización del state. Ahora bien, ¿qué pasa si la tarea requerida es demasiado compleja para que el agente inicial la maneje, incluso con nuevas skills? Ahí es donde entra en juego el patrón de Handoff. Los Handoffs también usan tools para actualizar el state, pero en lugar de cargar nuevas instrucciones en el agente actual, el cambio de state transfiere el control a un agente completamente diferente. Volviendo a nuestro escenario. El agente de soporte recoge el ID de la garantía, pero en lugar de procesar el reembolso él mismo, llama a una tool de handoff. Esta tool actualiza una variable de enrutamiento en el state, cambiando el agente activo del bot de triaje a un agente especialista diseñado exclusivamente para devoluciones de alto valor. La capa de orquestación ve este cambio de state y dirige el siguiente paso del workflow al especialista. Este punto de transición es donde las cosas suelen fallar. Al hacer un handoff entre agentes, el nuevo agente necesita el contexto de la conversación. Muchos desarrolladores intentan limpiar el historial pasándole simplemente los mensajes raw del usuario al nuevo agente. No hagas esto. Al hacer un handoff entre agentes, debes incluir el mensaje de la IA que contiene la tool call real que inició el handoff, y el Tool message resultante que confirma que el handoff ocurrió. Si omites la tool call y el Tool message del array de mensajes, el historial de la conversación se rompe. El nuevo modelo pierde la chain lógica de eventos. No sabrá cómo ha llegado hasta ahí, y probablemente repetirá preguntas que el usuario ya ha respondido. Pasa siempre el historial de mensajes intacto. Aquí está la clave. El state no es solo un almacén de memoria pasivo, sino el control plane que dicta exactamente lo que tu sistema es capaz de hacer en cualquier milisegundo. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 18 de 20. A veces, no quieres que un agente de IA decida libremente qué hacer a continuación. Simplemente quieres que ejecute un diagrama de flujo estricto y determinista. Los workflows personalizados y los routers te dan exactamente ese nivel de control. Cuando dependes únicamente de un loop de agente estándar, confías en que el modelo de lenguaje determine cada paso por sí solo. Podría buscar en una base de datos, darse cuenta de que necesita más datos, buscar de nuevo y, finalmente, responder. Esto es potente, pero es impredecible y a menudo lento. Los workflows personalizados en LangGraph te permiten salir de ese loop. Tú dibujas el mapa. Puedes combinar sin problemas la lógica determinista, como ejecutar scripts exactos de recuperación de datos, con el razonamiento no determinista del agente. Pones el modelo de lenguaje dentro de una secuencia estricta de eventos. Antes de crear uno, tenemos que aclarar una confusión común entre un router y un supervisor. Un supervisor orquesta activamente una conversación de varios turnos. Observa a los agentes hablar, decide quién habla a continuación y gestiona el diálogo a lo largo del tiempo. Un router no es eso. Un router es simplemente un paso de clasificación. Analiza el input, decide qué ruta debe seguir el workflow, enruta los datos y su trabajo termina. Puede ser stateless o stateful, pero no es un gestor conversacional. Veamos un escenario concreto. Estás creando una herramienta de base de conocimiento con múltiples fuentes. Un usuario hace una pregunta y la respuesta podría estar enterrada en pull requests de GitHub, threads de Slack, o en ambos. No quieres que un solo agente adivine a ciegas dónde buscar. Quieres un workflow estructurado. Primero, creas un nodo de routing. Pasas la query del usuario a un modelo de lenguaje y le pides que devuelva una lista simple de destinos. Si la query es sobre un bug fix reciente, el modelo podría devolver las palabras GitHub y Slack. Esta es la parte que importa. No tienes que elegir una sola ruta. Puedes ejecutar múltiples agentes exactamente al mismo tiempo usando la API Send. En LangGraph, en lugar de devolver un único siguiente paso desde tu lógica condicional, tu función de routing devuelve una lista de comandos Send. Cada comando asocia un nodo de destino con los datos específicos que necesita. El graph ve múltiples comandos Send y ejecuta automáticamente todos esos nodos de destino en paralelo. A esto se le llama fanning out. Durante el fanning out, el workflow llega a tus nodos de agente. En un workflow personalizado, invocar un agente es muy sencillo. Un agente es simplemente un proceso runnable ejecutado dentro de una función de nodo estándar. El nodo de Slack recibe la query, ejecuta un agente de Slack dedicado para buscar en los canales, extrae el contexto y lo devuelve al state general del graph. El nodo de GitHub hace lo mismo simultáneamente para los repositorios de código. Aislar estos agentes dentro de nodos específicos garantiza que solo realicen la tarea para la que fueron diseñados. Finalmente, todas esas ramas paralelas deben converger. Haces un fan in. Creas un nodo sintetizador que espera a que los agentes paralelos terminen. Lee el state general del graph, coge el contexto recopilado de Slack y el contexto recopilado de GitHub, se los pasa a un modelo de lenguaje final y genera una respuesta única y limpia para el usuario. El verdadero poder de los workflows personalizados es envolver la naturaleza impredecible de los grandes modelos de lenguaje dentro de la fiabilidad predecible del routing de software estándar. Eso es todo por hoy. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 19 de 20. ¿Qué pasa cuando un agente creado en Python necesita conversar de forma nativa con un agente creado por un equipo completamente diferente, ejecutándose en un servidor totalmente distinto? Si dependes de llamadas a funciones internas hardcoded, tu sistema falla en el momento en que cruza una frontera de red. La solución es la comunicación Agent-to-Agent. Agent-to-Agent, o A2A, es un protocolo de comunicación que permite sistemas multiagente verdaderamente distribuidos. Permite que los agentes alojados en servidores completamente diferentes mantengan una conversación continua sin necesidad de compartir el mismo codebase subyacente o espacio de memoria local. En lugar de encapsular todo en una única aplicación masiva, enrutas las requests a través de la red. La comunicación se basa estrictamente en un formato de endpoint definido: barra a2a barra, seguido del ID del asistente. Cada agente que participa en esta red distribuida expone esta ruta de endpoint exacta. Cuando un agente necesita ayuda de otro, envía una request HTTP POST allí. El payload enviado a este endpoint se estructura como un mensaje JSON-RPC estándar. Para mantener la conversación coherente a través de múltiples saltos de red y diferentes servidores, el protocolo utiliza dos identificadores distintos en su payload. Los desarrolladores a veces confunden estos dos, así que vamos a definir sus límites. El primero es el Context ID. El Context ID es responsable de la continuidad general del thread. Representa todo el historial general de la conversación, desde el primer prompt hasta el output final. El segundo es el Task ID. El Task ID identifica la request o el paso específico dentro de ese único turno. El Context ID abarca toda la sesión. El Task ID cambia cada vez que un agente le pide al otro que realice una nueva acción. Considera un escenario práctico donde el Agente A está corriendo en un servidor escuchando en el puerto 2024, y el Agente B está corriendo en un servidor diferente en el puerto 2025. El Agente A se da cuenta de que necesita que el Agente B se encargue de una subtarea específica, tal vez comprobar el inventario externo. El Agente A prepara un mensaje JSON-RPC. Dentro de este mensaje, incluye el Context ID existente para que el Agente B sepa a qué conversación en curso pertenece. El Agente A también genera un Task ID totalmente nuevo para esta request de inventario específica. El Agente A envía este payload al endpoint A2A en el puerto 2025, insertando el ID de asistente específico del Agente B directamente en la ruta de la URL. El Agente B recibe la request. Lee el Context ID para recordar cualquier estado previo necesario, procesa la tarea solicitada en los parámetros JSON-RPC y calcula el resultado. Luego, el Agente B construye una respuesta JSON-RPC. Esta respuesta incluye explícitamente el Task ID exacto que el Agente A proporcionó originalmente. El Agente B envía esta respuesta de vuelta al Agente A en el puerto 2024. El Agente A recibe el resultado, asocia el Task ID con su request pendiente y continúa su propia ejecución interna. Aquí está la clave. Como el protocolo impone el estándar JSON-RPC y aísla el seguimiento del estado en identificadores específicos de Context y Task, ninguno de los agentes necesita saber cómo opera el otro internamente. No mantienen una conexión de socket constante y abierta. Simplemente se turnan para pasarse mensajes estructurados de un lado a otro a través de fronteras HTTP estándar. Un servidor hace una pregunta, el otro responde, y la tarea general avanza. Cuando separas el thread de conversación a largo plazo de la ejecución individual de tareas a corto plazo, puedes escalar redes multiagente a través de diferentes servidores y frameworks indefinidamente. Si estos episodios te resultan útiles y quieres ayudar a apoyar el programa, puedes buscar DevStoriesEU en Patreon. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. LangChain v1.0 Orchestration Framework, episodio 20 de 20. Cada vez que quieres que tu agente hable con una nueva base de datos o API, acabas escribiendo un wrapper personalizado. Tu codebase se llena de integraciones frágiles que se rompen cada vez que cambia una API externa. Esto limita lo rápido que puedes escalar tus aplicaciones. La solución a este cuello de botella de integración es el Model Context Protocol, o MCP. Piensa en MCP como el USB-C para los agentes de IA. Estandariza cómo las tools y el contexto se exponen a los large language models. Antes de este protocolo, si querías que tu agente consultara una base de datos y comprobara un servicio meteorológico, tenías que escribir funciones de Python específicas para ambos, definir manualmente sus input schemas y vincularlos a tu modelo. Con MCP, el propio servicio externo proporciona una interfaz estandarizada. Tu agente simplemente se enchufa a él y entiende al instante qué tools están disponibles, qué argumentos requieren y cómo ejecutarlas. Un malentendido común es pensar que usar un servidor MCP remoto significa que la lógica de tu agente viaja por la red. Aquí está la clave: tu agente se mantiene completamente local. El servidor remoto no ejecuta tu agente ni controla su razonamiento. Simplemente expone una lista de JSON schemas estandarizados que representan las tools que soporta. Tu agente local lee esos schemas, decide qué tool usar basándose en el prompt del usuario, y envía una petición de ejecución de vuelta al servidor. La ejecución ocurre allí, y el resultado raw se devuelve a tu agente local. En LangChain, gestionas estas conexiones usando el MultiServerMCPClient. Este componente actúa como un hub central. Permite a un único agente conectarse a múltiples servidores MCP distintos simultáneamente, recopilando tools de todos ellos. El cliente maneja la comunicación subyacente usando diferentes transport layers. Los dos transports principales que vas a configurar son standard input y output, conocidos como stdio, y HTTP. Veamos un escenario concreto. Estás construyendo un agente que necesita realizar cálculos complejos usando un script de Python local, mientras también obtiene datos meteorológicos en tiempo real de un servicio remoto. En lugar de escribir tool wrappers personalizados para estas tareas, configuras el MultiServerMCPClient para que maneje ambas. Primero, defines tu servidor matemático local usando el transport stdio. Configuras el cliente con el comando a ejecutar, como el ejecutable de Python de tu sistema, y la ruta a tu script matemático. Cuando el cliente se inicializa, levanta este script como un background process local. El cliente de LangChain y el script se pasan mensajes directamente a través de los streams de standard input y standard output. A continuación, defines el servidor meteorológico usando el transport HTTP. Para esto, simplemente proporcionas la URL del endpoint del servicio meteorológico remoto. Esta configuración normalmente se basa en Server-Sent Events para mantener una conexión persistente, permitiendo al agente solicitar acciones y hacer stream de las respuestas a través de la web. Una vez que ambos transports están definidos, inicializas el MultiServerMCPClient. El cliente se conecta inmediatamente al proceso matemático local vía stdio y a la URL meteorológica remota vía HTTP. Pide a ambos servidores que le entreguen las definiciones de sus tools. Recopila los schemas, los fusiona en una lista continua, y se los proporciona a tu agente de LangChain. Desde la perspectiva del agente, solo ve una lista unificada de tools disponibles. Desconoce por completo que una tool se ejecuta en un proceso binario local y la otra lanza una petición HTTP a un servidor al otro lado del mundo. El cambio hacia protocolos estandarizados significa que puedes dedicar tu tiempo a construir una mejor lógica para el agente en lugar de mantener interminables API wrappers. Como este es el último episodio de la serie, te animo muchísimo a que leas la documentación oficial de LangChain y pruebes a configurar un servidor MCP local de forma práctica. Si tienes sugerencias sobre temas que te gustaría ver en nuestra próxima serie, visita devstories dot eu y envíanos un mensaje. El verdadero poder de un agente no reside en lo que sabe, sino en a qué puede conectarse de forma fluida. Eso es todo por este episodio. ¡Gracias por escuchar, y sigue construyendo!