Deep Agents en LangChain: planificación, subagentes y una pasarela bancaria

Muchos equipos pueden hacer que un agente trabaje desde una laptop. Muchos menos logran mantener uno operativo en entornos reales, y es en esa brecha donde los agentes avanzados ganan su relevancia. La idea no es solo un término de moda; es una respuesta a una limitación concreta: un bucle simple de llamadas a herramientas deja de funcionar cuando el trabajo se vuelve extenso, complejo o desorganizado.

La limitación del bucle simple

El agente más básico es un LLM que funciona en un bucle y llama a herramientas. Tal agente suele ser superficial, lo que significa que no puede planificar tareas extensas ni completar operaciones complicadas con múltiples pasos. Maneja bien una sola pregunta, pero tropieza ante cualquier tarea más compleja.

Productos como Deep Research, Manus y Claude Code lograron superar este problema gracias a cuatro elementos: una herramienta de planificación, subagentes, un sistema de archivos y una instrucción detallada. El proyecto deepagents surgió de un intento por comprender qué hacía que Claude Code fuera tan versátil y por llevar eso aún más lejos. El término de LangChain para este tipo de agentes es “deep agents”, ya que pueden planificar tareas complejas y llevarlas a cabo durante períodos prolongados. En esencia, representa el enfoque de LangChain para crear agentes autónomos al estilo de Claude Code capaces de manejar tareas reales y multifase, no solo preguntas puntuales.

deepagents es una biblioteca independiente desarrollada a partir de los componentes básicos para crear agentes de LangChain y que funciona con el entorno de ejecución LangGraph, el cual ofrece una ejecución fiable, soporte para transmisiones en tiempo real y la participación humana en el proceso. Una buena descripción sería un conjunto de herramientas para agentes: el mismo ciclo de llamadas a herramientas que otros frameworks, pero con herramientas y capacidades adicionales integradas.

Los cuatro componentes esenciales

Planificación. Una herramienta integrada llamada write_todos permite al agente dividir una tarea compleja en pasos discretos, seguir el progreso y modificar el plan a medida que llega nueva información.

Un sistema de archivos para el contexto. Herramientas como ls, read_file, write_file y edit_file permiten que el agente guarde grandes cantidades de contexto en la memoria o en el disco, evitando que la ventana de contexto se sobrecargue y permitiendo manejar resultados de herramientas de cualquier tamaño. Los mensajes antiguos se resumen automáticamente cuando la conversación se alarga.

Subagentes. Una herramienta de tareas integrada genera subagentes especializados con un contexto aislado. El agente principal permanece organizado mientras un asistente se enfoca en una subtarea específica.

Prompts de sistema extensos. Los prompts reconstruidos a partir de Claude Code son largos y contienen instrucciones detalladas sobre el uso de las herramientas, además de ejemplos de cómo actuar en situaciones concretas. Sin ellos, estos agentes serían mucho menos capaces. La formulación de los prompts sigue siendo crucial.

Su lugar en la pila de LangChain

Existen tres capas, cada una basada en la que está debajo. LangGraph es el entorno de ejecución de agentes, adecuado para combinar flujos de trabajo y agentes. LangChain es el marco de agentes, adecuado para utilizar el bucle principal y crear prompts y herramientas desde cero. Deep Agents es la plataforma de soporte, adecuada para agentes autónomos que funcionan durante mucho tiempo y que se benefician de la planificación integrada, un sistema de archivos y otros recursos similares. Esta plataforma se construye sobre la abstracción de agentes de LangChain, que a su vez se basa en LangGraph.

Un ejemplo bancario

Imagínese un banco que ofrece cinco herramientas específicas: encontrar cajeros automáticos por código postal, listar a los asesores de inversión en una ciudad, obtener la información de las empresas incluidas en el portafolio de inversión del banco, proporcionar detalles sobre planes de jubilación y localizar sucursales en diferentes regiones. Cada una de estas herramientas realiza bien una tarea concreta. Los problemas surgen cuando un usuario solicita algo que involucre varias de ellas al mismo tiempo:

¿Puede enumerar los centros de cajeros automáticos del banco XYZ, junto con las empresas de su cartera de inversiones, y también indicar las ubicaciones de sus responsables de inversiones en Chicago?

Responder a esto implica detectar varias intenciones en una sola solicitud, elegir y coordinar las herramientas adecuadas, mantener el contexto entre diferentes dominios de datos y combinar los resultados en una respuesta coherente. Las arquitecturas diseñadas para flujos simples o lineales suelen fracasar en este caso. Esta es la situación para la cual están hechos los agentes avanzados.

La secuencia se desarrolla de la siguiente manera.

1. Planificación. El orquestador principal lee la pregunta compuesta y utiliza write_todos para dividirla en tres tareas: obtener los centros de cajeros automáticos, obtener las empresas de la cartera y localizar a los responsables en Chicago.

Generación. En lugar de procesar los tres tareas de forma secuencial en un único contexto sobrecargado, se inician tres subagentes, uno por tarea, cada uno con su propia ventana de contexto para que no interfieran entre sí.

Llamada a herramientas. Cada subagente utiliza exactamente la herramienta adecuada de las cinco: get_atm_centers(zipcode=...), get_trusted_portfolio_companies() y get_investment_officers(city="Chicago").

Síntesis. Los resultados vuelven al orquestador, que los combina en una respuesta bien formateada y marca como completadas las tareas.

Un agente básico para llamar a herramientas manejaría los tres casos en secuencia dentro de un mismo contexto. Podría olvidar los resultados anteriores, perder la noción de a qué pregunta estaba respondiendo o alcanzar el límite de contexto. Un agente avanzado mantiene las tareas separadas y sigue el progreso a través de la lista de pendientes, de modo que incluso si una llamada falla o devuelve datos parciales, el coordinador sabe cuál es la situación actual.

La estructura es sencilla:

from deepagents import create_deep_agent

agent = create_deep_agent(
    tools=[
        get_atm_centers,         # your ATM tool
        get_investment_officers, # your officers tool
        get_portfolio_companies, # your portfolio tool
        get_retirement_plans,    # your retirement tool
        get_bank_locations,      # your locations tool
    ],
    system_prompt="You are XYZ Bank's AI assistant. Always answer completely and cite sources."
)

result = agent.invoke({"messages": [{"role": "user", "content": "Can you give me a list of ATM centers for XYZ bank and also list the name of companies XYZ has in its investment portfolio? Also can you give me the location of XYZ investment agents in Chicago?"}]})

El agente decide qué herramientas llamar, en qué orden y cómo combinar los resultados obtenidos. Usted no tiene que escribir la lógica de enrutamiento por sí mismo, y ese es el verdadero valor del framework.

ReAct frente a agentes avanzados cuando falta una herramienta

Tome la misma solicitud y agregue una cuarta pregunta para la cual no existe herramienta alguna: una lista de opciones de tarjetas de crédito para estudiantes. Aquí se muestra cómo cada diseño maneja esta situación.

Un agente avanzado verifica su registro de herramientas y crea la lista de tareas antes de actuar, por lo que al principio detecta que no existe ninguna herramienta para tarjetas de crédito. Lanza subagentes para las tres tareas a realizar, los cuales operan en paralelo y finalizan con normalidad; marca el ítem relacionado con la tarjeta de crédito como “no hay herramienta disponible” y devuelve una respuesta sintetizada. Esa respuesta aborda completamente las tres preguntas e indica claramente al usuario que no está configurada ninguna herramienta para tarjetas de crédito y que podría ser necesario agregar una. Nada falla, y el éxito parcial se reporta de manera clara.

ReAct, abreviatura de Reasoning plus Acting, sigue un ciclo estricto de Pensar, Actuar y Observar paso a paso, sin planificación previa. Esto genera tres problemas:

• Funciona de forma secuencial: primero los cajeros automáticos, luego el portafolio y finalmente los empleados. La carencia de herramienta para tarjetas de crédito solo se detecta al final, después de haberse completado todo lo demás.

Nunca escanea las herramientas disponibles. Encuentra la que falta en tiempo de ejecución cuando intenta llamarla, y dependiendo del LLM y la implementación puede detenerse, intentarlo de nuevo con un nombre de herramienta inventado o, lo peor de todo, crear una lista creíble de tarjetas de crédito porque espera que exista una respuesta.

Dado que el fallo ocurre a mitad del proceso, nada garantiza que los tres resultados anteriores lleguen al usuario de forma correcta. El agente podría simplemente fallar y no devolver nada.

ReAct es adecuado para tareas cortas y bien definidas en las que se sabe con certeza que existen todas las herramientas. Los agentes avanzados están pensados para el mundo real, más complejo, donde las preguntas son compuestas, las herramientas pueden faltar y aún así se desea obtener tanto valor como sea posible con lo que se tiene.

La pregunta de diseño: ¿un agente con todas las herramientas?

¿Significa esto que deberíamos crear muchas herramientas y exponerlas todas a través de un único agente? No. Un solo agente que contenga 50 o más herramientas constituye un patrón antiétnico. La estructura más adecuada es una jerarquía de agentes. Imagine un agente cuya configuración enumera cientos de herramientas, desde búsquedas en la web y correos electrónicos hasta reservas de vuelos y lanzamientos de cohetes, con la instrucción de “resolverlo por sí mismo”. Puede funcionar en ocasiones, y de vez en cuando responde a una queja por envío tardío reservando un vuelo, presentando impuestos y pidiendo una pizza. Nadie quiere eso.

Propiedad del dominio

La regla guía es que cada agente de dominio posea un grupo pequeño y coherente de herramientas, idealmente de tres a cinco, provenientes de una misma área de negocio. Un agente de pasarela nunca interactúa con las herramientas; solo lee la intención, redirige la solicitud al agente de dominio adecuado y combina las respuestas. Se trata de la misma separación de responsabilidades que se utiliza en los microservicios.

En el caso de la banca, la división natural es:

• Un agente de sucursales y cajeros automáticos con get_atm_centers y get_bank_locations, que se encarga de la presencia física: códigos postales, ciudades y horarios de atención.
• Un agente de inversiones con get_portfolio, get_officers y get_retirement_plans, que se ocupa de la gestión financiera, incluyendo regulaciones financieras, certificaciones de los empleados y tipos de planes.
• Un agente de productos con get_credit_cards cuando este existe, además de préstamos y cuentas de ahorro, que se encarga del catálogo de productos. Cuando falta una herramienta, solo este agente informa sobre la deficiencia y los demás continúan sin afectación.

El código refleja esa estructura:

from deepagents import create_deep_agent
# Each domain agent is self-contained
branch_agent = create_deep_agent(
    tools=[get_atm_centers, get_bank_locations],
    system_prompt="You are the Branch & ATM specialist for XYZ Bank..."
)
investments_agent = create_deep_agent(
    tools=[get_portfolio, get_officers, get_retirement_plans],
    system_prompt="You are the Investments specialist for XYZ Bank..."
)
products_agent = create_deep_agent(
    tools=[get_credit_cards],  # sparse now, grows over time
    system_prompt="You are the Products specialist for XYZ Bank..."
)
# Gateway knows nothing about tools — only about agents
gateway = create_deep_agent(
    tools=[
        branch_agent.as_tool(name="branch_atm_agent"),
        investments_agent.as_tool(name="investments_agent"),
        products_agent.as_tool(name="products_agent"),
    ],
    system_prompt="""You are the XYZ Bank assistant gateway.
    Parse the user's intent, delegate to the right domain agent(s),
    and synthesize a unified response. Never answer directly — always route."""
)

Por qué esto escala

A medida que el banco añade funcionalidades, la pasarela y los demás agentes de dominio permanecen sin cambios. Puede agregar una herramienta al agente del dominio correspondiente o crear uno nuevo, como el de Préstamos o Fraude, y registrarlo en la pasarela. Cualquier cambio se limita a un único dominio.

Imagínese un conjunto de herramientas. Un agente con 30 de ellas no tiene conciencia del dominio y podría llamar a get_retirement_plans al responder una pregunta sobre los horarios de los cajeros automáticos, simplemente porque ambas están dentro del alcance. Los agentes de dominio evitan esto al asignarle a cada uno una identidad clara a través de su mensaje de sistema y conjunto de herramientas. Un agente que sabe quién es puede razonar con mayor precisión en su área específica.

Una prueba útil: si discuten sobre si una herramienta pertenece al agente A o al agente B, la herramienta está haciendo demasiado y debería dividirse, o bien necesitan un tercer dominio. El límite debe resultar tan obvio como saber si una pregunta va dirigida al gerente de sucursal o al asesor financiero.

Preguntas abiertas

Quedan dos cuestiones por resolver: si los agentes avanzados dependen en gran medida de la elección del modelo subyacente, y si se puede crear una solución integral de extremo a extremo con ellos. La respuesta a la segunda es sí, y el siguiente paso lógico es desarrollar prácticamente este escenario bancario.