Deep Agents

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 1 de 16. Crear un coding agent desde cero es divertido durante una hora. Luego, tu modelo alcanza el context limit, olvida por completo la tarea original y sobrescribe un archivo crítico con basura. Para evitar que tu asistente destruya su propio espacio de trabajo, necesitas lo que se conoce como el patrón agent harness. La gente suele descubrir este patrón a través de una librería llamada Deep Agents. Primero, una aclaración rápida. Deep Agents no es LangChain, y no es LangGraph. Es una librería independiente de Python que se asienta sobre esas herramientas, empaquetándolas en un coding assistant listo para usar. Si intentas crear un coding assistant por tu cuenta, normalmente empiezas con un script básico. Coges un prompt del usuario, lo envías a un Large Language Model e imprimes el código que devuelve. Eso es simplemente un chat loop sencillo. Funciona bien para responder a una sola pregunta. Pero pronto quieres que el modelo implemente una feature en varios archivos de tu máquina. Aquí es donde se rompe la ilusión. Te das cuenta de que tienes que escribir manualmente herramientas para leer archivos, buscar en directorios y aplicar code diffs de forma segura. Necesitas un sistema para mantener el contexto a lo largo de decenas de pasos sin agotar el token limit. Tienes que crear una lista de tareas persistente para que el modelo recuerde lo que acaba de hacer y lo que necesita hacer a continuación. Terminas dedicando todo tu tiempo a escribir boilerplate del file system y state management, en lugar de centrarte en el agent behavior. Esto es exactamente lo que resuelve el patrón agent harness. Un harness es la capa de infraestructura que envuelve al raw language model. Convierte un chat loop frágil y stateless en un agente duradero y long-running. En Deep Agents, este harness proporciona el memory management, las operaciones del file system y la lógica de planificación paso a paso, todo out of the box. Le das un objetivo de alto nivel y lo apuntas a un directorio local. El harness se encarga del trabajo repetitivo de darle al modelo un entorno seguro para planificar, editar y verificar código. Aquí está la clave. La principal ventaja de usar un harness independiente como Deep Agents es que es completamente model-agnostic. Las soluciones tightly integrated, como el Claude Agent SDK o ecosistemas más antiguos como OpenAI Codex, están muy optimizadas, pero te atan a un único proveedor. Si mañana sale un modelo más barato o más inteligente, migrar tu agente tightly coupled es un dolor de cabeza enorme. Como Deep Agents abstrae el entorno del motor de razonamiento, el modelo de lenguaje se convierte en un componente totalmente reemplazable. El harness gestiona las listas de tareas, lee el file system y se encarga del error recovery. Esa lógica sigue siendo idéntica tanto si usas Anthropic, OpenAI o un modelo local open-weight. El harness es el chasis del coche, y el modelo de lenguaje es solo el motor. El verdadero valor de este patrón es la fiabilidad. Un agente es tan capaz como el entorno en el que opera, y sin un harness que lo ancle a un file system real y a un plan concreto, incluso el modelo más inteligente es solo un generador de texto patinando en el vacío. Si quieres ayudar a que el programa siga adelante, puedes buscar DevStoriesEU en Patreon; cualquier apoyo allí es de gran ayuda y siempre se agradece. Eso es todo por este episodio. ¡Gracias por escuchar, y a seguir programando!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 2 de 16. No necesitas un diagrama de arquitectura enorme ni cientos de líneas de boilerplate para que un modelo de lenguaje planifique su trabajo de forma autónoma. Solo necesitas una function call para activar el Core Loop. El entry point para este comportamiento es una función llamada create deep agent. En esta función es donde defines el cerebro de tu aplicación. En lugar de importar client libraries por separado y escribir wrappers personalizados, le indicas a la función qué modelo usar mediante un simple string separado por dos puntos. Le pasas el provider, dos puntos y el nombre exacto del modelo. Podrías usar anthropic dos puntos claude-sonnet-4-6, o openai dos puntos gpt-5.4. El framework lee este string y gestiona la inicialización específica por debajo. Un agente necesita una forma de interactuar con el mundo, que tú le proporcionas mediante tools. Una tool es simplemente una función estándar de Python que realiza una acción específica. Digamos que estás creando un agente de investigación en internet. Escribirías una función que recibe una query, llama a una search API y devuelve texto. Le pasas esta función de búsqueda directamente a tu llamada a create deep agent como parte de una lista. Tu agente ya está listo. Para iniciar el proceso, llamas al método run de tu nuevo agente y le pasas un prompt, como pedirle que investigue y sintetice noticias recientes sobre computación cuántica. Ahora el Core Loop toma el control. Aquí está la clave. Los desarrolladores suelen asumir que deben escribir system prompts complejos para forzar al modelo a dividir las tareas, o crear parsers personalizados para seguir su progreso. No tienes que hacer nada de eso. Al llamar a create deep agent, el harness inyecta automáticamente una tool integrada llamada write todos. Nunca tienes que escribir ni gestionar esta tool tú mismo. Forma parte del core engine. Antes de que el agente toque tu tool de búsqueda, el Core Loop fuerza al modelo a usar la tool write todos. El agente evalúa tu prompt y genera una lista estructurada de pasos. Solo después de finalizar este plan comienza la fase de ejecución. El loop itera sobre el plan paso a paso. El agente examina su primera tarea, reconoce que necesita información y llama a tu tool de búsqueda en internet. Lee el raw text que devuelve el motor de búsqueda y actualiza su memoria interna. A continuación, el loop comprueba si se ha cumplido el objetivo principal. Si los resultados de la búsqueda son incompletos, el agente pasa al siguiente elemento de su todo list, quizás formulando una nueva search query para encontrar los detalles que faltan. Este ciclo de seleccionar una tool, observar el resultado y comprobar el plan continúa de forma autónoma. Cuando el loop confirma que todas las tareas necesarias se han completado, deja de llamar a las tools. El agente analiza los datos recopilados, genera una respuesta sintetizada final y te la devuelve. La característica principal del Core Loop es que convierte un generador de texto estático en un solucionador de problemas activo, forzándolo estructuralmente a planificar antes de actuar. Eso es todo por ahora. Gracias por escuchar, ¡y sigue desarrollando!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 3 de 16. Darle a un agente autónomo acceso directo a tu ordenador es una excelente manera de borrar accidentalmente tu directorio personal. Si un agente decide reorganizar tus archivos o probar un script, tienes que asegurarte de que esté confinado en un área segura. Por eso usamos The Pluggable Filesystem. Cuando le das a un Deep Agent tools para leer o editar un archivo, esas tools no se conectan directamente a tu sistema operativo. En su lugar, se mapean a un backend. Un backend es un entorno de almacenamiento que determina dónde y cómo viven realmente los archivos. El entorno por defecto es el StateBackend. Es una unidad fantasma efímera que se mantiene completamente en memoria. Imagina que le pides a un agente que escriba un borrador rápido de un email o que manipule algunos datos de texto. El agente crea el archivo, lo vuelve a leer y lo edita, todo dentro del StateBackend. Cuando tu script termina de ejecutarse, esa memoria se limpia y los archivos desaparecen. Está completamente aislado y es totalmente seguro. Pero, ¿qué pasa cuando quieres que el agente genere un proyecto de Python real en tu disco local? La memoria ya no es suficiente. Aumentas los permisos del agente conectando un FilesystemBackend. Esto conecta las tools de archivos del agente a tu disco duro real. Para mantener esto seguro, inicializas el backend con un parámetro llamado virtual mode en true. Aquí está la clave. El virtual mode crea un límite de ruta estricto. Defines un directorio base, y el agente opera dentro de él. Si el agente intenta leer un archivo sensible del sistema fuera de esa carpeta, el backend bloquea la petición. Atrapa al agente en un workspace designado. Sin embargo, aquí hay un malentendido peligroso. Muchos desarrolladores asumen que habilitar el virtual mode crea una sandbox completamente segura. Y no es así. El FilesystemBackend solo controla las operaciones de archivos. Si también quieres que tu agente ejecute comandos de terminal, tienes que conectar un tercer tipo de backend llamado LocalShellBackend. El LocalShellBackend le da al agente una nueva tool llamada execute. Esto le permite al agente ejecutar comandos de shell en tu máquina host. Si conectas un LocalShellBackend, el virtual mode de tu FilesystemBackend no te protegerá de comandos de terminal destructivos. El agente podría ejecutar un script de borrado a nivel de sistema, y la shell lo ejecutaría, saltándose por completo tus restricciones de ruta de archivos. El acceso a archivos y la ejecución de la shell son capacidades distintas mapeadas a backends distintos. Si tu agente solo necesita escribir código, quédate con el FilesystemBackend. Conecta el LocalShellBackend solo si el agente necesita absolutamente compilar o ejecutar ese código en local. El agente autónomo más seguro no es el que tiene los prompts más inteligentes, sino el que tiene un deploy con un StateBackend efímero que físicamente no puede tocar tu sistema operativo host. Eso es todo por hoy. Gracias por escuchar, ve a crear algo genial.

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 4 de 16. El error más común en el diseño de agentes es escribir un system prompt enorme, de cuatro mil palabras, que detalle exactamente cómo funciona cada tool y hardcodear datos de sesión específicos. Acabas con un prompt frágil, context windows agotadas y una pesadilla al gestionar múltiples usuarios. Los system prompts dinámicos resuelven esto ensamblando sobre la marcha las instrucciones exactas que necesita el modelo de lenguaje. Piensa en el context engineering en Deep Agents como una cadena de montaje dinámica. En lugar de escribir un bloque de texto estático, el prompt final que se envía al modelo de lenguaje se construye a partir de tres capas distintas. Estas capas son el system prompt estático, los tool prompts y el runtime context. Se fusionan en el momento exacto de la ejecución para formar el input context completo. La primera capa es el system prompt estático. Esta es la parte que escribes a mano. Define la personalidad del agente, sus reglas principales y su objetivo final. Es deliberadamente simple. Puedes decirle al agente que es un asistente de consultas a la base de datos, pero no le dices cómo conectarse a ella, qué formato espera la tool, ni cuál es el ID de sesión del usuario. Mantienes esta capa estrictamente enfocada en la lógica de negocio de alto nivel. La segunda capa consiste en los tool prompts, y aquí es donde entra en juego el framework. Deep Agents inyecta automáticamente las instrucciones de uso necesarias para las tools específicas que le añades al agente. Si le das al agente una tool para leer un archivo, el framework añade dinámicamente el schema exacto para esa tool. Junto con los schemas, inyecta un planning prompt integrado. Este planning prompt le indica al modelo cómo secuenciar las tools disponibles de manera efectiva para resolver un problema. Nunca tienes que escribir a mano las instrucciones sobre cómo el modelo debe formatear una tool call o planificar sus pasos de ejecución. El framework gestiona esa mecánica automáticamente. Cuando añades o quitas una tool del agente, los tool prompts subyacentes se actualizan al instante sin que tengas que tocar el system prompt principal. Ahora, tenemos que aclarar una fuente común de confusión entre el system prompt estático y el runtime context. El prompt estático se define cuando inicializas el agente. El runtime context, sin embargo, se inyecta justo cuando invocas al agente para que haga su trabajo. Imagina un escenario en el que estás construyendo una aplicación multi-tenant. Cuando un usuario específico hace una pregunta, el agente necesita el ID de conexión a la base de datos único de ese usuario para obtener sus datos. Si pusieras ese identificador en el system prompt estático, tendrías que recrear todo el agente desde cero para cada petición del usuario. En su lugar, usas el runtime context. Aquí está la clave. Pasas un objeto de contexto mediante una feature llamada ToolRuntime justo en el paso de invocación. Le pasas al framework un diccionario que contiene el ID de conexión a la base de datos específico para esa sesión. El framework coge este runtime context, lo fusiona con tu prompt estático y las instrucciones de las tools autogeneradas, y lo conecta directamente a las tools que lo necesitan. La tool se ejecuta utilizando el ID de conexión correcto, proporcionado dinámicamente. Tu system prompt estático se mantiene completamente limpio de identificadores temporales, API keys o tokens de sesión. En el milisegundo de la ejecución, la cadena de montaje dinámica termina su trabajo. Deep Agents concatena tus instrucciones principales, los schemas de las tools generados dinámicamente, los planning prompts y los datos de invocación específicos en un input context cohesivo. El modelo recibe un conjunto completo de instrucciones, formateadas a la perfección y adaptadas a ese usuario específico y a esa tarea en particular. Los agentes más escalables desconocen su entorno hasta el momento exacto en que se les pide que actúen. Eso es todo por este episodio. ¡Hasta la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 5 de 16. La mayoría de los agentes de IA fallan o se cuelgan silenciosamente en el momento en que leen un system log o un data dump que supera el tamaño máximo de su prompt. Deep Agents evita esto tratando los límites de contexto igual que un sistema operativo gestiona la memoria virtual. Esto se llama compresión y offloading de contexto. Los grandes modelos de lenguaje tienen un límite estricto en la cantidad de texto que pueden procesar a la vez. Si un agente intenta mantener demasiados datos en su prompt activo, el modelo lanza un error y se detiene. Deep Agents gestiona este token overflow monitorizando constantemente el tamaño de los datos de la conversación. Funciona exactamente igual que un ordenador haciendo paginación de la memoria RAM a un disco duro cuando la memoria se llena. El espacio de trabajo activo se mantiene ligero, mientras que el grueso de los datos se aparta de forma segura. Este mecanismo funciona en dos fases distintas. La primera fase maneja los picos de datos masivos e inmediatos de tools externas. El framework vigila el conteo de tokens de cada input y resultado de las tools. El umbral estricto para esta comprobación es de veinte mil tokens. Si una operación supera este límite, el sistema intercepta el payload antes de que llegue al modelo de lenguaje. Imagina un agente ejecutando una consulta que extrae un dump de base de datos masivo de treinta mil tokens. Un agente estándar intenta insertar todo ese payload directamente en el historial de la conversación, lo que provoca inmediatamente un token overflow. Deep Agents toma un camino diferente. Intercepta esa respuesta masiva, hace un offload del texto completo a un nuevo archivo en el filesystem del backend, y reemplaza el payload en la conversación con una sencilla preview de diez líneas. El agente lee la preview y recibe un file path que apunta a los datos completos. El agente sabe exactamente lo que ha encontrado, pero el prompt activo se mantiene completamente despejado. Esto se encarga de los picos repentinos de datos. La segunda fase maneja la acumulación lenta de una conversación estándar. A medida que un agente ejecuta un proceso largo de varios pasos, el historial continuo de ida y vuelta se come lentamente los tokens disponibles. Deep Agents monitoriza el uso total de la context window frente a los límites del modelo. Cuando el prompt activo alcanza el ochenta y cinco por ciento del total de la context window disponible, se dispara automáticamente un proceso de resumen en background. El sistema coge el bloque de mensajes más antiguo del historial actual y utiliza un modelo de lenguaje para generar un resumen denso y factual de esos eventos. Luego, reemplaza ese bloque de mensajes más antiguo en el prompt activo con el resumen recién generado, bajando instantáneamente el conteo de tokens a un nivel de trabajo seguro. Aquí está la clave. Los desarrolladores suelen asumir que resumir la conversación destruye permanentemente el historial original. Eso no es cierto. Antes de que se haga ningún resumen, los mensajes originales se escriben en el filesystem como un registro permanente y canónico. El raw data no se pierde. Si más adelante el agente determina que necesita un detalle muy específico de un paso anterior que no entró en el resumen, puede usar sus tools de búsqueda para consultar ese filesystem y recuperar el texto original exacto. Al combinar offloads inmediatos al filesystem para resultados masivos de las tools con resúmenes dinámicos para historiales largos, un agente puede operar indefinidamente sin asfixiarse en su propio contexto. ¡Gracias por escuchar, feliz programación a todos!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 6 de 16. Si tu agente principal de IA lee diez páginas web para responder una sola pregunta, acabará olvidando cuál era el prompt original. Todo ese ruido intermedio ahoga las instrucciones. La solución a esto es el Aislamiento de Contexto con Subagentes Síncronos. Piensa en esto como un patrón de arquitectura limpia para tus modelos de lenguaje. Cuando un solo agente tiene acceso a docenas de tools y ejecuta largos bucles iterativos, su ventana de contexto se llena rápidamente con datos en crudo, mensajes de error y outputs de las tools. Esta sobrecarga de contexto degrada la capacidad de razonamiento del modelo. En lugar de un agente enorme que intenta hacerlo todo, necesitas un supervisor. El agente principal actúa como manager. Delega el trabajo sucio y que consume muchos tokens a especialistas, y solo recibe un informe final limpio y formateado. La gente suele confundir los subagentes con una sala de chat multiagente continua, donde diferentes modelos se sientan a debatir ideas de un lado a otro. Ese no es el caso aquí. Los subagentes síncronos son estrictamente efímeros. Se lanzan para ejecutar un trabajo específico, se ejecutan de forma totalmente autónoma en su propio espacio de memoria aislado hasta que terminan el trabajo, y devuelven un único resultado final al supervisor. Una vez que entregan ese resultado, desaparecen. Imagina un escenario específico. Tu agente principal tiene la tarea de escribir un informe de mercado, y necesita datos sobre tendencias económicas recientes. En lugar de que el supervisor invoque directamente una tool de búsqueda web cinco veces y contamine su propia ventana de contexto con texto en crudo de sitios web, delega el problema. Activa un subagente investigador. Este investigador efímero se va a su propio loop aislado. Hace las cinco búsquedas en Google, lee los resultados sucios, sintetiza los hallazgos y escribe un único párrafo de resumen. Le pasa solo ese párrafo de vuelta al supervisor. El supervisor obtiene exactamente lo que necesita, y su contexto se mantiene impoluto. Para configurar esto, defines a tus especialistas usando diccionarios sencillos. Se los pasas al parámetro subagents cuando construyes tu agente principal. Cada diccionario es una especificación de subagente que requiere cuatro datos. Primero, proporcionas un nombre, como investigador o calculadora. Segundo, proporcionas una descripción. Esta es la parte que importa. El supervisor lee esta descripción para decidir qué especialista contratar para un problema determinado. Tercero, proporcionas las tools, dándole a este subagente específico acceso aislado a cosas como un web scraper o un cliente de base de datos. Finalmente, proporcionas un system prompt, que gobierna cómo se comporta el subagente. Una vez que le entregas esta lista de configuraciones al agente principal, automáticamente obtiene acceso a una tool integrada llamada task. El supervisor no necesita saber cómo instanciar los subagentes. Cuando encuentra un problema que coincide con la descripción de un especialista, simplemente llama a la tool task. Le pasa dos argumentos: el nombre del subagente a utilizar, y una instrucción en texto plano sobre lo que se debe hacer. La ejecución del supervisor se pausa. El subagente arranca, trabaja con sus tools, y finalmente termina. Para el supervisor, la tool task simplemente devuelve la respuesta final en texto como si fuera una function call estándar. Incluso si no defines explícitamente ningún diccionario, el framework te da un fallback. Hay un subagente por defecto de propósito general integrado. El agente principal puede usar este especialista por defecto para delegar pasos de razonamiento complejos. Actúa como una pizarra en blanco, dándole al modelo una nueva ventana de contexto para resolver un denso rompecabezas lógico sin ensuciar la memoria del supervisor. Aquí está la clave. Al imponer límites estrictos entre tareas aisladas, evitas que el trabajo intermedio de scratchpad degrade la calidad de razonamiento del flujo principal de tu aplicación. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 7 de 16. Dejar que un sistema autónomo ejecute SQL queries a ciegas es una excelente manera de hacer un drop accidental en una base de datos de producción. Si quieres que tu agente opere en el mundo real, necesitas un mecanismo para interceptarlo antes de que haga algo destructivo. Ahí es donde entran en juego las intervenciones Human-in-the-Loop. La idea principal es simple. Pausas el agente justo antes de que ejecute una operación delicada, le pides instrucciones a un humano y luego reanudas la ejecución basándote en ese feedback. Antes de ver cómo funciona, hay un error común que debes evitar. LangGraph requiere memoria para pausar y reanudar el estado. Si intentas configurar una intervención Human-in-the-Loop sin configurar un checkpointer, la intervención fallará. El sistema necesita una capa de persistencia, como un memory saver, para congelar el execution graph y guardar las variables actuales mientras espera a que un humano responda. Añade siempre un checkpointer primero. No todas las tools necesitan revisión humana. Consultar el tiempo o leer un log file por lo general es seguro. Eliminar archivos o modificar registros de la base de datos requiere un control estricto. Esta categorización de riesgos la gestionas usando el parámetro de configuración interrupt on. Cuando inicializas tu agente o defines tu tool node, le pasas una lista de nombres de tools a este parámetro. Si el agente intenta llamar a una tool que no está en la lista, se ejecuta inmediatamente. Si intenta llamar a una tool que sí está en la lista, la ejecución se pausa. Veamos un escenario concreto. Tienes un agente con una tool de base de datos llamada execute. Añades execute a tu lista de interrupt on. El agente decide que necesita borrar algunos datos antiguos e intenta ejecutar un comando drop en la base de datos. El sistema intercepta la llamada y pausa el execution graph. Cuando ejecutas tu agente, monitorizas el objeto result devuelto por el framework. En concreto, compruebas una propiedad llamada interrupts. Si la lista interrupts del result contiene datos, el agente ha llegado a una barrera de seguridad y está esperando tu input. En este punto, el operador humano evalúa la acción pendiente. Tienes tres decisiones permitidas que puedes devolverle al agente. Son approve, reject o edit. Si haces approve, el agente ejecuta la tool con los argumentos originales. Si haces reject, el tool call falla de forma controlada, y el agente recibe un mensaje de error con un prompt para que intente un enfoque diferente. Aquí es donde la cosa se pone interesante. La decisión edit te permite modificar la acción prevista del agente antes de que ocurra. En nuestro escenario de base de datos, el agente está intentando un comando drop peligroso. Puedes interceptar esa petición, reescribir los argumentos de la tool para ejecutar una select query segura en su lugar, y enviar ese payload modificado de vuelta al sistema. Para reanudar el agente, lo invocas de nuevo, pero esta vez le pasas un objeto command usando el parámetro resume. Dentro de ese parámetro resume, proporcionas tu decision string junto con cualquier argumento modificado. El checkpointer recupera el estado congelado, inyecta tu decisión humana directamente en el graph como si el agente lo hubiera planeado así originalmente, y la ejecución continúa. Lo más importante que debes recordar es que las intervenciones Human-in-the-Loop te dan mucho más que un simple botón de parada de emergencia. La capacidad de editar los argumentos de la tool sobre la marcha te permite guiar a un agente de forma segura a través de workflows complejos sin tener que empezar de cero. Si quieres apoyar el programa, busca DevStoriesEU en Patreon. Eso es todo por este episodio. Gracias por escuchar, ¡y a seguir programando!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 8 de 16. Al ver a un agente leyendo un fichero local, podrías pensar que esa capacidad está hardcodeada en lo más profundo del loop de ejecución principal. Pero no es así. La magia detrás del file system de un agente está impulsada totalmente por middleware composable que puedes extender tú mismo. Hoy veremos cómo extender el harness con middleware. Deep Agents no es una caja negra. El harness que impulsa el pipeline de ejecución es altamente extensible. Al equipar a un agente con un file system o una todo list, simplemente estás conectando middleware preempaquetado a ese harness. El middleware se sitúa exactamente en la frontera entre la decisión del agente de invocar una tool y la ejecución real de esa tool. Es un interceptor. Te da control absoluto sobre qué entra, qué sale y qué se registra durante el intercambio. Para escribir tu propio middleware custom, creas una función interceptora y aplicas un decorador específico llamado wrap tool call. Este decorador registra tu función en el harness. Cuando el agente lanza una tool, el harness pausa el flujo por defecto y cede el control a tu wrapped function. Dentro de este interceptor, recibes los raw input arguments generados por el agente, una referencia a la tool que se está llamando y el graph state actual. Ejecutas la tool original manualmente desde dentro de tu función, capturas su output y luego devuelves ese output al harness. Imagina un middleware custom creado para monitorizar una API externa. Quieres interceptar cada tool call a la API, loguear los argumentos exactos que usó el agente y trackear las métricas de uso para evitar rate limits. Tu función wrap tool call atrapa la request antes de que llegue a la red. Extrae el payload, lo escribe en los logs de tu aplicación y luego ejecuta la request real a la API. Una vez que la request termina, el middleware recibe los datos de la response. Ahora necesita registrar que se hizo una llamada. Presta atención a esta parte. Al trackear métricas de uso, los desarrolladores a menudo intentan usar variables de instancia de clase estándar. Simplemente escriben algo como self punto api call count más igual a uno. Esto es un error fatal. Deep Agents ejecuta tools y subagents en paralelo de forma rutinaria. Si múltiples tools se resuelven en el mismo momento e intentan mutar la misma propiedad de instancia directamente, causarás race conditions. Tus contadores se sobrescribirán entre sí, se perderán updates y tus métricas estarán completamente mal. Para gestionar los datos de forma segura, en su lugar debes actualizar el graph state. El graph state está diseñado explícitamente para manejar la ejecución en paralelo. En lugar de modificar una variable local, tu middleware lee la métrica actual del graph state, calcula el nuevo valor y hace un yield de un state object actualizado junto con el tool result. El execution harness toma el control a partir de ahí. Procesa todos los state updates entrantes de las ejecuciones paralelas de las tools y los fusiona limpiamente sin colisiones. Al enrutar todos los side effects y el tracking de métricas a través del graph state, tu middleware se mantiene completamente thread-safe. Entender este patrón desbloquea todo el framework. Dejas de tratar al agente como un sistema cerrado y empiezas a verlo como un pipeline transparente donde cada acción puede ser interceptada y medida de forma segura. Eso es todo por esta vez. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 9 de 16. Tener un asistente de código con IA es genial, hasta que tienes que recordarle por vez número cincuenta que tu proyecto requiere tipado estricto y variables en snake case. La solución son las Convenciones de Proyecto mediante Archivos de Memoria. La ergonomía del desarrollador exige que tus herramientas se adapten a tu codebase, no al revés. No deberías tener que pegar una guía de estilo en cada prompt. Deep Agents soluciona esto dándole al agente una memoria persistente a través de un archivo específico llamado AGENTS punto md. A veces la gente confunde la memoria con las skills. La memoria proporciona tu base universal. Siempre se carga en el startup, lo que la hace perfecta para convenciones globales y reglas de arquitectura. Las skills son herramientas funcionales que el agente carga dinámicamente solo cuando una tarea específica las requiere. Hoy, nos vamos a centrar estrictamente en la memoria. Cuando inicializas un agente y le pasas el parámetro de memoria, el framework inyecta automáticamente el contenido del archivo AGENTS punto md directamente en el contexto del agente antes de que haga cualquier trabajo. Esta operación se basa en el protocolo memory-first, que dicta tres fases distintas para el agente: Research, Response y Learning. En la fase de Research, el agente lee el archivo de memoria para entender el entorno. En la fase de Response, genera el código o responde al prompt. Luego viene la fase de Learning. Aquí está la clave. No tienes que escribir manualmente el archivo AGENTS punto md. El agente actualiza este archivo de forma autónoma basándose en tu feedback. Pongamos un escenario concreto. Le pides al agente que genere un nuevo endpoint de la API. Escribe código funcional, pero formatea las variables en CamelCase. Rechazas la pull request y le respondes que este proyecto usa estrictamente snake case. El agente corrige el código, pero no se detiene ahí. Entra en la fase de Learning, abre el archivo AGENTS punto md local y añade una nueva regla que exige snake case para todas las futuras variables. La próxima vez que pidas un endpoint, el agente lee ese archivo de memoria durante su fase de Research y escribe de forma nativa en snake case desde el principio. Este sistema de memoria persistente opera en dos scopes diferentes. El primero es el scope global. Este archivo vive en tu directorio home de usuario, dentro de una carpeta punto deepagents. Lo usas para tus preferencias personales de desarrollador. Si siempre prefieres Python asíncrono frente al código síncrono en todos tus proyectos, el agente lo aprende aquí. El segundo es el scope del proyecto. Este archivo vive directamente dentro de la carpeta de tu repositorio local. Aquí es donde van las reglas específicas del repositorio. Cuando se ejecuta un agente, carga ambos archivos. Primero aplica tus preferencias globales y luego superpone las convenciones específicas del proyecto. Como el archivo de memoria con scope de proyecto vive en tu repositorio, le haces commit al control de versiones. Cuando un nuevo desarrollador se une al equipo y ejecuta el agente, su instancia local hereda al instante todas las decisiones de estilo que el agente ya ha aprendido. Cada error corregido mejora permanentemente la comprensión que el agente tiene de tu repositorio, pasando de ser un generador de código genérico a un mantenedor altamente contextualizado. Eso es todo por este episodio. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 10 de 16. Si metes cincuenta guías de documentación de API diferentes en tu system prompt, tu agente no se volverá más inteligente. Simplemente se distraerá y fallará en tareas básicas. Necesitas una forma de dotar a un agente de conocimientos avanzados sin sobrecargar la context window. El Progressive Disclosure con skills resuelve exactamente este problema. Una skill en Deep Agents funciona como una actualización modular del cerebro. Te permite empaquetar lógica compleja, como reglas de deploy de AWS o workflows personalizados de data science, en un directorio aislado. Para crear una, simplemente creas una nueva carpeta, le pones el nombre de tu skill y metes dentro un archivo llamado exactamente skill punto md. Un error muy común es pensar que el framework simplemente añade todo el contenido de este archivo al system prompt. No es así. Hacer eso nos llevaría de vuelta al problema de sobrecargar la context window, degradando el rendimiento y aumentando los costes. En su lugar, el framework se basa en un patrón llamado Progressive Disclosure, que ocurre en tres pasos: Match, Read y Execute. En la parte más alta de tu archivo skill punto md, escribes un bloque de frontmatter. Este tiene un formato YAML básico y contiene solo un nombre y una breve descripción. Aquí está la clave. El framework solo carga esa breve descripción en el system prompt inicial. El agente lee la descripción y decide si coincide con la petición actual del usuario. Esta es la fase de Match. Si el agente decide que la skill es relevante, no se pone a adivinar qué hacer a continuación. Utiliza activamente una tool interna para obtener el resto del archivo skill punto md. Esta es la fase de Read. Ahora, el agente tiene las instrucciones completas y detalladas cargadas temporalmente en su memoria de trabajo para este turno específico. Finalmente, pasa a la fase de Execute, donde sigue esas instrucciones detalladas para completar la tarea. Cuando la conversación cambia de tema, se descarta el payload pesado y el agente vuelve a su estado base. Imagina un escenario en el que quieres crear una skill llamada langgraph-docs. El frontmatter de tu skill punto md tiene una descripción que indica que esta skill proporciona instrucciones y URLs internas para buscar en la documentación de LangGraph. El cuerpo del archivo contiene esas URLs internas reales y la metodología de búsqueda específica. Cuando un usuario pregunta qué es LangGraph, el agente revisa sus skills activas. Ve la breve descripción, se da cuenta de que necesita más información para responder a la pregunta y solicita el documento completo. Lee las URLs, realiza la búsqueda y formula una respuesta precisa. Sin el Progressive Disclosure, tendrías que pegar todas esas URLs en el prompt principal para cada conversación. Al crear una librería de skills, podrías encontrarte con conflictos donde dos skills intentan definir instrucciones para tareas similares. Deep Agents resuelve esto mediante la precedencia de origen. La regla es simple: la última gana. La skill que se cargue en último lugar hará override de las instrucciones conflictivas de las anteriores. Esto te permite apilar primero skills amplias y genéricas, y luego añadir overrides muy específicos más adelante en tu configuración. La ejecución de todo tu workflow agéntico depende de lo bien que escribas ese frontmatter. Mantén tus descripciones precisas y los cuerpos de tus skills muy detallados, porque el agente solo leerá el archivo completo si se lo vendes bien en la descripción primero. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 11 de 16. Un asistente inteligente no debería preguntarte qué base de datos usas cada vez que inicias una nueva conversación. Sin embargo, out of the box, la mayoría de los agentes sufren de amnesia total en el momento en que termina un thread. Para solucionar esto, necesitas Long-term Memory Stores. Cuando ejecutas un agente, genera archivos. Los oyentes suelen asumir que si un agente escribe un archivo, este vive para siempre. Pero no es así. Por defecto, todo es efímero. Deep Agents usa un StateBackend, que almacena los archivos dentro del state del thread de la conversación actual. Cuando ese thread termina, esos archivos desaparecen. Si quieres una verdadera personalización, donde el agente construya una base de datos de por vida con las preferencias del usuario y el conocimiento del proyecto, necesitas un enfoque diferente. Necesitas el StoreBackend. Este se conecta directamente a un LangGraph Store persistente, manteniendo los datos a salvo a través de múltiples threads. Pero no quieres persistir cada archivo temporal que crea tu agente. Necesitas un mecanismo para separar el trabajo efímero de scratchpad de las memorias duraderas. Aquí es donde entra en juego el CompositeBackend. Piénsalo como un router de tráfico para el file system de tu agente. Configuras el CompositeBackend con un fallback por defecto, normalmente el StateBackend efímero. Luego, registras explícitamente una ruta para tu almacenamiento a largo plazo. Le dices al router que cualquier file path que empiece con el prefijo de directorio barra memories barra debe ser gestionado por el StoreBackend. Presta atención a esta parte. Esta persistencia no es automática. Debes enrutar específicamente el path barra memories barra al Store. Si te saltas este paso de enrutamiento, el agente simplemente escribirá los archivos de memoria en el state efímero, y se borrarán cuando termine el thread. Una vez que introduces una base de datos persistente, te enfrentas a un nuevo problema. No puedes tener a un usuario leyendo las preferencias almacenadas de otro usuario. Para evitar esto, el StoreBackend usa namespace factories. Un namespace factory es simplemente una función que inyecta una capa de aislamiento basada en el contexto actual. En lugar de guardar un archivo globalmente, el factory genera un array de prefijos, como la palabra users seguida del ID de usuario único. Cada vez que el agente interactúa con el StoreBackend, la base de datos limita automáticamente la operación a ese namespace de usuario exacto. Veamos cómo fluye esto en la práctica. Inicias la conversación uno. Mencionas que estás construyendo una aplicación en React. El agente toma nota de esto y escribe un resumen en un archivo llamado project notes punto txt, colocándolo específicamente dentro del directorio barra memories barra. El CompositeBackend ve ese prefijo de directorio, intercepta el comando de escritura, y lo enruta al StoreBackend duradero bajo tu namespace de usuario aislado. Mañana, inicias la conversación dos. Este es un thread completamente nuevo con cero contexto inmediato. Haces una pregunta sobre frameworks de state management. Antes de responder, el agente comprueba su directorio barra memories barra. El CompositeBackend enruta la petición de lectura al store persistente. El agente lee tus project notes, ve los detalles de React, y proporciona una respuesta muy relevante adaptada a tu stack específico. El contexto se traslada perfectamente, aunque los threads estén separados. La persistencia cross-thread requiere un diseño deliberado, enrutando directorios específicos a un store persistente y protegiéndolos con namespaces específicos del usuario. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 12 de 16. Dejar que una IA escriba código es impresionante. Dejar que esa IA ejecute a ciegas el código que acaba de escribir directamente en tu portátil es una pésima idea. Para solucionar esto, necesitas un lugar seguro donde el agente pueda verificar su lógica sin poner en riesgo tu máquina host. De eso precisamente hablaremos hoy, ejecutar código en sandboxes. Si un agente no puede ejecutar código, no puede verificar si su código realmente funciona. Depende puramente de sus datos de entrenamiento para adivinar si un script es correcto. Los sandboxes dan al agente un entorno seguro para iterar, fallar y arreglar errores basándose en el output de ejecución real. Antes de ver la mecánica, tenemos que aclarar un malentendido común. Podrías pensar que hay que hacer deploy del propio agente y ejecutarlo dentro del sandbox. No es así. Deep Agents se basa en el patrón de sandbox como tool. La lógica, la memoria y los prompts del agente viven de forma segura en tu servidor. El agente simplemente envía comandos de shell y código a través de una API a un entorno remoto y aislado. Esta interacción ocurre a través de la tool execute. Cuando el agente decide que necesita ejecutar un script, llama a la tool execute y le pasa el bloque de código generado. Esta tool reenvía el payload a un backend del sandbox. Proveedores como Modal, Daytona y Runloop proporcionan estos entornos. Provisionan un contenedor seguro, ejecutan el código y devuelven el standard output o los logs de error al agente. El sandbox crea un límite de aislamiento estricto entre el espacio de ejecución y tu sistema. Imagina un agente encargado de crear un pequeño paquete de Python y ejecutar una test suite usando pytest. El agente está en tu servidor. Usa la tool execute para conectarse a un servidor remoto efímero. Primero, envía un comando para instalar las librerías necesarias. Luego, escribe los archivos de Python en el directorio del sandbox. Finalmente, envía un comando para ejecutar pytest. El sandbox ejecuta estos pasos y devuelve el output de la terminal. Si un test falla, el agente lee el error de la respuesta de la API, actualiza el código y vuelve a llamar a la tool execute. El agente puede hacer build, testear y hacer borrón y cuenta nueva, todo mientras tu máquina host permanece completamente intacta. Cuando configuras un backend de sandbox, tienes que definir su ciclo de vida. Hay dos enfoques principales. El primero es thread-scoped. Aquí, el sandbox está vinculado a un thread de conversación específico. Cuando empieza la conversación, se levanta un sandbox nuevo. Cuando termina la sesión del usuario, el sandbox se destruye. Esto asegura un entorno limpio para cada interacción y es ideal para operaciones de una sola tarea donde los datos no necesitan persistir. El segundo enfoque es assistant-scoped. En este modelo, el sandbox está vinculado al propio agente, independientemente de la conversación activa. Cada thread que interactúa con ese agente comparte exactamente el mismo estado del sandbox. Si un thread instala una versión específica de una librería o descarga un dataset grande, esos archivos siguen disponibles para el siguiente thread. Esta es la opción correcta cuando tu agente actúa como un worker persistente que requiere un espacio de trabajo estable y continuo. Aquí está la clave. El entorno de ejecución dicta la capacidad del agente. Al controlar el ciclo de vida del sandbox y aplicar límites estrictos en la API, le das al agente la libertad de cometer errores sin comprometer tu infraestructura. El verdadero poder de un agente no es solo generar código, sino iterar sobre el fallo, y los sandboxes remotos proporcionan la única forma segura de dejar que esa iteración ocurra automáticamente. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 13 de 16. Lanzas una query compleja, tu agente supervisor delega en tres subagentes en paralelo, y tu usuario se queda mirando un loading spinner genérico durante dos minutos seguidos. Eso es una experiencia de usuario terrible, y para arreglarlo, tienes que exponer exactamente lo que está pasando por debajo. La respuesta es Subgraph Streaming UX. Los workflows multiagente son inherentemente asíncronos y lentos. Cuando un agente principal delega tareas, crea una caja negra. Si simplemente esperas el resultado final combinado, el usuario asume que la aplicación se ha quedado colgada. Tienes que hacer stream de la actividad de los subagentes directamente al frontend. Un error común que cometen los desarrolladores aquí es asumir que cuando los subagentes hacen stream de tokens, esos tokens simplemente se añaden a ciegas al stream de salida del agente principal. Si eso fuera cierto, los outputs en paralelo se entrelazarían en un desastre de texto incomprensible. En su lugar, el framework gestiona esto aislando cada evento en su propio namespace. Para que esto funcione, usas el formato de streaming de la versión dos y pasas un flag poniendo subgraphs a true cuando llamas a tu stream. Cuando haces esto, el stream ya no devuelve chunks de texto en crudo. Devuelve diccionarios. Cada diccionario contiene tres keys específicas: type, ns y data. Type te dice qué tipo de evento estás viendo. Data contiene el payload real o el token de texto. Y ns significa namespace. Esta es la parte que importa. El namespace es una tupla que define la ruta exacta del nodo que generó el evento. Si un chunk viene del agente principal, la tupla del namespace está vacía. Si viene de un subagente, el namespace contiene la ruta. Se ve como una tupla que contiene la palabra tools seguida de un ID único de subagente. Imagina que estás construyendo un dashboard en el frontend. Un usuario le pide al sistema que planifique unas vacaciones. El agente supervisor lanza tres subagentes separados: uno para vuelos, uno para hoteles y uno para actividades. En tu código del frontend, haces un loop sobre el stream entrante. Al comprobar la key del namespace en cada chunk del diccionario, sabes exactamente qué subagente generó ese token específico. Luego puedes rutear esos datos a componentes de la UI separados. En lugar de un único spinner atascado, tu usuario ve tres barras de carga individuales o ventanas de texto llenándose con outputs en tiempo real una al lado de la otra. A veces necesitas hacer stream de información que no es solo un token de un modelo de lenguaje. Quizás quieres hacer push de una actualización de estado personalizada, como notificar a la UI de que se está llamando a una API externa. Puedes hacer esto desde dentro de un nodo usando la función get stream writer. Recuperas el writer, le pasas tu diccionario personalizado, y este inyecta esos datos directamente en el stream general bajo el namespace del subagente actual. El frontend lo recibe exactamente como cualquier otro evento y actualiza la barra de carga específica correcta. Si quieres ayudar a que el programa siga adelante, puedes apoyarnos buscando DevStoriesEU en Patreon. La transparencia multiagente es fundamentalmente un problema de routing; mapear tuplas de namespace a componentes de la UI independientes es lo que convierte una caja negra frustrante en una experiencia de usuario premium. Eso es todo por este episodio. Gracias por escuchar, ¡y sigue construyendo!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 14 de 16. ¿Qué pasaría si pudieras conectar tu agente local de terminal a la base de datos propietaria de tu empresa sin escribir una sola línea de código Python? Precisamente esa capacidad es la razón por la que analizamos la CLI de Deep Agents y las External MCP Tools. El SDK de Deep Agents proporciona una interfaz de línea de comandos integrada de fábrica. Inicias el proceso y obtienes un prompt de terminal donde puedes chatear con tu agente. Puedes gestionar el cerebro central del agente directamente desde este prompt. Si necesitas un motor de razonamiento más potente, simplemente escribes barra model seguido del identificador del nuevo modelo. La CLI hace un hot-swap del proveedor al instante y continúas tu sesión. Pero un agente de terminal que solo chatea no es muy útil. Necesita acceso a tu trabajo real. Normalmente, darle a un agente acceso a un repositorio de GitHub o a una base de datos local requiere escribir código wrapper personalizado en Python para manejar las API calls. La CLI evita esto por completo usando el Model Context Protocol, ampliamente conocido como MCP. A menudo hay confusión sobre qué es MCP en realidad. No es una library de Python que importas en el código de tu agente. Un servidor MCP es un proceso completamente independiente o una URL remota. Actúa como un wrapper estandarizado alrededor de un sistema externo. Cuando la CLI arranca, habla con este proceso independiente, le pregunta qué tools proporciona y las carga dinámicamente. Configuras esta conexión usando un simple archivo de texto llamado punto mcp punto json. Este archivo es el núcleo de las integraciones zero-code. Cuando lanzas la CLI de Deep Agents, hace un auto-discovery. Busca esta configuración json en tu directorio actual. Si la encuentra, se conecta a los servidores listados dentro, registra sus tools y se las entrega a tu agente. Este archivo de configuración admite dos mecanismos de transporte. El primero es la entrada y salida estándar, o stdio. Esto es para servidores locales. La CLI lanza el servidor como un proceso en background en tu máquina y se comunica con él a través de streams estándar de terminal. El segundo tipo de transporte se basa en HTTP y Server-Sent Events. Esto lo usas cuando tu servidor MCP está alojado de forma remota, quizás situado dentro de una red corporativa privada. Como los servidores stdio ejecutan comandos locales, la seguridad es una prioridad. La CLI mantiene un trust store local para los servidores a nivel de proyecto. La primera vez que la CLI detecta un nuevo comando de servidor local en tu archivo punto mcp punto json, se detiene y pide permiso explícito. Una vez que lo apruebas, el hash de ese comando se guarda en tu trust store, y las futuras ejecuciones se conectan automáticamente. Veamos un escenario específico. Quieres que tu agente lea archivos de tu disco local. Creas un archivo punto mcp punto json. Dentro, defines un bloque de servidor y lo nombras local-filesystem. Estableces el tipo de transporte a stdio. Para la línea de comandos, le indicas que ejecute la tool del gestor de paquetes de node, npx, apuntando a un servidor de la comunidad preconstruido llamado server-filesystem, junto con la ruta del directorio que quieres exponer. Guardas el archivo y lanzas la CLI de Deep Agents. Aquí está la clave. La CLI lanza automáticamente ese comando npx en background. El servidor del sistema de archivos arranca y hace un broadcast de que tiene tools para leer archivos y listar directorios. La CLI capta ese broadcast y equipa a tu agente. Puedes escribir inmediatamente en tu terminal, pidiéndole al agente que lea tu archivo de log del sistema. El agente entiende que tiene la tool, llama al proceso en background, recupera el contenido del archivo y responde a tu pregunta. Le acabas de dar a un sistema de IA acceso seguro a tu disco local usando unas pocas líneas de texto de configuración. Al desacoplar la lógica de la tool de tu aplicación Python, MCP convierte tu terminal de una interfaz de chat básica en un centro de control extensible. Eso es todo por este episodio. ¡Nos vemos en la próxima!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 15 de 16. ¿Por qué conformarte con un asistente de código genérico cuando puedes inyectar tu propio agente de LangGraph altamente personalizado directamente en tu editor de código? El protocolo que saca a tu agente a medida de la terminal y lo lleva a tu flujo de trabajo diario es la integración con editores a través de ACP. Antes de seguir, tenemos que aclarar una colisión de acrónimos. Probablemente hayas oído hablar de MCP, o Model Context Protocol. MCP conecta tu agente a herramientas externas, permitiéndole buscar en una base de datos o leer un sistema de archivos. ACP, el Agent Client Protocol, es completamente distinto. ACP conecta tu agente a IDEs externos, como Zed o VSCode. Uno conecta el agente a datos externos, el otro lo conecta a tu workspace. ACP es una capa de comunicación estandarizada. Define exactamente cómo un entorno de desarrollo integrado envía selecciones de texto, estructuras de archivos y prompts del usuario a un agente de IA. También dicta cómo ese agente devuelve inserciones de código, diffs de archivos y respuestas de chat. Al implementar este protocolo, tu deep agent personalizado se comporta exactamente como un asistente estándar dentro de tu editor. La diferencia es que posee todas las estructuras de memoria específicas, los templates de prompts personalizados y las herramientas internas especializadas que tú le has integrado. Para salvar esta distancia, instalas el paquete deepagents-acp. La integración requiere un script de Python muy corto que actúe como entry point. En este script, instancias tu deep agent preconfigurado. Luego, en lugar de arrancar un servidor web o un bucle de línea de comandos, envuelves tu agente en una interfaz de servidor ACP. Esto lo consigues llamando a una función run dedicada y pasándole un objeto AgentServerACP, que a su vez envuelve la lógica subyacente de tu agente. Aquí está la clave. Cuando configuras este servidor, lo ajustas para usar standard input y standard output, comúnmente conocido como modo stdio. Esto es crucial porque significa que no hay puertos de red que gestionar, reglas de firewall que saltarse, ni WebSockets que depurar. El proceso del agente simplemente escucha los strings de texto entrantes en el standard input e imprime sus respuestas estructuradas en el standard output. A continuación, tienes que conectar tu editor a este script. Imagina el editor Zed como un escenario concreto. Dentro de Zed, abres tu archivo JSON de configuración de usuario. Añades un bloque de configuración indicando al editor que use un agente personalizado. En lugar de apuntar Zed a un endpoint de una API REST remota, lo apuntas directamente a tu ejecutable local de Python, pasándole la ruta a tu nuevo script ACP como argumento principal. Cuando inicias una sesión, el editor lanza tu script de Python como un proceso oculto en segundo plano. Cada vez que pides una edición inline o seleccionas una función para refactorizar, el editor envía un mensaje ACP estructurado a través del standard input directamente a tu script en ejecución. Tu agente personalizado procesa la petición, recorre su grafo de nodos interno, consulta su memoria e imprime la respuesta en formato ACP de vuelta en el standard output. El editor captura ese output y aplica los cambios de código de forma nativa en la ventana de tu aplicación. La conclusión más valiosa aquí es el control. Al enrutar tu agente personalizado a través de ACP sobre stdio, dejas de depender de un asistente genérico y empiezas a colaborar con una entidad que entiende intrínsecamente las convenciones específicas de tu codebase. Eso es todo por este episodio. ¡Gracias por escuchar y sigue programando!

Hola, soy Alex de DEV STORIES DOT EU. Deep Agents, episodio 16 de 16. Le pides a tu agente un refactor masivo del codebase y la interfaz de chat se congela inmediatamente. Te quedas mirando un spinner durante veinte minutos, sin poder hacer preguntas ni cambiar de opinión. Para solucionar esto, necesitas Background Workers con Async Subagents. Los subagents estándar son síncronos. Bloquean el main thread. El supervisor asigna una tarea y simplemente espera a que termine. Los async subagents cambian completamente esta dinámica al ejecutarse como background workers no bloqueantes. Cuando el supervisor asigna trabajo, no espera el resultado. Recibe inmediatamente un job ID y devuelve el control al usuario. La interfaz de usuario sigue respondiendo mientras el trabajo pesado ocurre en otro lugar. Configuras estos background workers usando la especificación Async SubAgent. Cuando haces deploy de tu aplicación en LangSmith Deployments, estos async subagents se alojan de forma independiente. El supervisor principal se comunica con ellos a través de transport protocols estándar. Si haces deploy del worker exactamente en el mismo servidor que el supervisor, se comunican usando ASGI, que es muy eficiente para el local routing. Si el worker reside en un servidor remoto independiente, el supervisor se conecta a él por HTTP. Para orquestar estos workers remotos, el supervisor cuenta con un conjunto específico de async tools. Piensa de nuevo en esa petición de refactor del codebase. El usuario pide la reescritura. El supervisor decide que esto llevará mucho tiempo y llama a la tool start async task. Esta tool arranca el coder subagent y le entrega al supervisor un job ID. El supervisor responde al usuario, confirmando que el background job se está ejecutando. Como el main thread está libre, el usuario puede continuar la conversación. Unos minutos después, el usuario podría preguntar cómo va el refactor. El supervisor llama a la tool check async task, pasándole el job ID, y recupera el estado de ejecución actual del worker. Aquí está la clave. El usuario no se queda bloqueado fuera del proceso mientras se ejecuta el worker. Si el usuario de repente se da cuenta de que necesita que el refactor aplique strict type hinting, simplemente se lo puede decir al supervisor. Entonces, el supervisor llama a la tool update async task. Esto envía nuevas instrucciones de mid-flight steering directamente al subagent en ejecución sin reiniciar el job desde cero. Si el usuario decide que el refactor fue una mala idea en general, el supervisor usa la tool cancel async task para terminar limpiamente el background process. Un punto común de confusión es cómo el supervisor recuerda estos jobs durante una sesión larga. Con el tiempo, los historiales de chat se compactan para ahorrar context tokens. Si el job ID solo existiera como texto en el historial de la conversación, el supervisor acabaría olvidándolo y perdería el rastro del worker. Para evitar esto, los metadatos de la tarea nunca se almacenan solo en el chat log. Se guardan en un state channel dedicado llamado async tasks. Este state channel funciona independientemente de la lista de mensajes, garantizando que los job IDs activos sobrevivan a cualquier compactación de la conversación. Pasar de blocking calls a background workers transforma tu arquitectura de una simple interfaz de chat a un motor de orquestación paralelo capaz de gestionar cargas de trabajo masivas. Dado que con esto finaliza nuestra serie actual, te animo a leer la documentación oficial, a probar a hacer deploy de un async worker tú mismo, o a visitar devstories dot eu para sugerir temas para nuestra próxima entrega. Gracias por pasar unos minutos conmigo. Hasta la próxima, cuídate.