Agentes, uso de herramientas y orquestación

De responder a actuar

Los sistemas de las secciones anteriores producen texto. Muchos sistemas útiles también deben actuar: consultar un pedido, buscar en una base de conocimiento, emitir un reembolso, reservar una mesa, ejecutar una batería de pruebas. La llamada a herramientas (tool calling, también conocida como llamada a funciones o function calling) es el mecanismo. La aplicación describe las herramientas disponibles, cada una con un nombre, una descripción y un JSON Schema para sus parámetros. En lugar de responder en prosa, el modelo puede devolver una solicitud estructurada para llamar a una o varias de ellas con argumentos concretos. Es la aplicación, no el modelo, la que decide si ejecuta la llamada, la ejecuta y devuelve el resultado al modelo, que entonces continúa. El modelo nunca toca por sí mismo una base de datos ni una API; cada efecto en el mundo pasa por código que escribiste tú.

Un agente es un sistema en el que el modelo elige sus acciones de forma repetida: llama a una herramienta, lee el resultado, decide qué hacer a continuación y sigue hasta alcanzar el objetivo o hasta que un límite lo detiene. La autonomía es un espectro. En un extremo, el código llama una vez al modelo para rellenar un formulario; en el otro, un modelo planifica y ejecuta una tarea larga con decenas de llamadas a herramientas y poca supervisión. Desde el punto de vista arquitectónico, lo importante es que cada paso hacia la autonomía traslada decisiones desde un código determinista y revisable a un componente probabilístico, lo que aumenta la flexibilidad y reduce la previsibilidad, la capacidad de prueba y el control. Ese compromiso debe asumirse de forma deliberada, y tan tarde y en tan poca medida como exija el problema.

{
  "name": "get_order_status",
  "description": "Look up the current status of one order placed by the signed-in customer. Use when the customer asks where an order is. Returns status, estimated arrival and courier position. Changes nothing.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "pattern": "^ORD-[0-9]{6}$",
        "description": "Order number, for example ORD-104233"
      }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

El bucle del agente: razonar, actuar, observar

El bucle que hay detrás de casi todos los agentes lo describieron Shunyu Yao y sus colegas en ReAct: Synergizing Reasoning and Acting in Language Models (2022). ReAct intercala razonamiento (el modelo escribe lo que intenta hacer), acciones (llama a una herramienta) y observaciones (el resultado de la herramienta se añade a su contexto), de modo que cada paso se basa en lo que encontró el anterior. Antes de ReAct, los modelos o bien razonaban sin acceso a los datos, y alucinaban, o bien actuaban sin razonar, y se desviaban. Las interfaces actuales de llamada a herramientas y los modelos de razonamiento incorporan este bucle, pero su estructura sigue siendo aquella en torno a la cual hay que diseñar.

En código, el bucle es corto. Construye el contexto (instrucciones, objetivo, historial, definiciones de herramientas, resultados hasta el momento); llama al modelo; si devuelve una respuesta final, detente; si devuelve llamadas a herramientas, valida cada una frente a su esquema y las reglas de negocio, comprueba que el usuario tiene derecho a ella, ejecútala con un timeout, añade el resultado (o un mensaje de error claro) al contexto, comprueba los límites y vuelve a empezar. El diagrama siguiente muestra dónde rodea el código determinista al modelo. Todo lo que está fuera del cuadro del modelo es software normal que puede probarse, revisarse y hacerse cumplir; de ahí vienen la fiabilidad y la seguridad de un agente.

Flujos de trabajo frente a agentes

En Building effective agents (diciembre de 2024), Erik Schluntz y Barry Zhang, de Anthropic, establecieron una distinción que desde entonces se ha convertido en vocabulario común. Los flujos de trabajo (workflows) orquestan modelos y herramientas mediante rutas de código predefinidas; los agentes dejan que el modelo dirija su propio proceso y su uso de herramientas. Describieron un pequeño conjunto de patrones de flujo de trabajo, todos construidos a partir de un LLM aumentado (un modelo con recuperación, herramientas y memoria), y aconsejaron empezar con el diseño más sencillo que funcione, a menudo una única llamada con un buen prompt y recuperación, y añadir comportamiento agéntico solo cuando mejore los resultados de forma demostrable.

El consejo coincide con la posición general de este curso sobre la simplicidad. Un flujo de trabajo tiene una forma conocida, así que su costo, su latencia y sus modos de fallo pueden predecirse y sus pasos pueden probarse uno a uno. Un agente puede abordar tareas abiertas cuyos pasos no pueden conocerse de antemano, como investigar un bug desconocido o documentarse sobre una pregunta en muchas fuentes, a cambio de un costo variable, pruebas más difíciles y más formas de que algo salga mal. Muchos sistemas descritos como agentes estarían mejor como flujos de trabajo, y muchos buenos agentes contienen flujos de trabajo.

Diseñar herramientas para modelos

Las herramientas son una interfaz cuyo usuario es un modelo, y merecen el cuidado que se da a cualquier API. Schluntz y Zhang lo llaman la interfaz agente-computadora. Da a cada herramienta un único propósito claro y un nombre y una descripción que digan cuándo usarla, cuándo no y qué devuelve; los modelos eligen las herramientas sobre todo por sus descripciones. Usa pocos parámetros y con tipo, enumeraciones en lugar de texto libre, y rechaza los campos desconocidos. Haz que los errores sean difíciles de cometer, por ejemplo exigiendo identificadores absolutos en lugar de posiciones en una lista. Devuelve resultados concisos y relevantes, porque cada token del resultado de una herramienta se paga y ocupa la ventana de contexto; pagina y resume los resultados grandes. Devuelve errores sobre los que el modelo pueda actuar (pedido no encontrado; pide al cliente que compruebe el número) en lugar de trazas de pila.

Separa la lectura de la escritura. Las herramientas de lectura normalmente pueden ejecutarse libremente; las de escritura cambian el mundo y necesitan validación, autorización, idempotencia y, a veces, aprobación. Mantén pequeño el número de herramientas disponibles en cada momento, porque los conjuntos grandes de herramientas confunden a los modelos y amplían la superficie de ataque; enruta a un subconjunto o carga las definiciones de herramientas bajo demanda. Pide salida estructurada siempre que el resultado lo vaya a consumir código: muchas API pueden restringir la generación a un JSON Schema, lo que elimina los fallos de análisis sintáctico, pero no los valores erróneos, así que sigue siendo necesario validar el contenido.

El Model Context Protocol

De otro modo, cualquier asistente que quisiera llegar a cualquier fuente de datos o herramienta necesitaría una integración a medida para cada par: N aplicaciones por M sistemas. El Model Context Protocol (MCP), presentado por Anthropic como estándar abierto en noviembre de 2024, sustituye eso por un único protocolo, igual que hizo el Language Server Protocol con los editores de código. Una aplicación host (un asistente de chat, un IDE, un agente) ejecuta un cliente MCP por cada conexión a un servidor MCP. Los servidores exponen herramientas (funciones que el modelo puede llamar), recursos (datos que la aplicación puede leer e incorporar al contexto) y prompts (plantillas reutilizables). Los mensajes usan JSON-RPC 2.0, sobre la entrada y la salida estándar en los servidores locales o sobre HTTP en los remotos, y los servidores remotos usan una autorización basada en OAuth.

La adopción fue rápida. En diciembre de 2025, Anthropic informó de más de 10 000 servidores MCP públicos activos y de su compatibilidad con productos como ChatGPT, Cursor, Gemini, Microsoft Copilot y Visual Studio Code. El 9 de diciembre de 2025, Anthropic donó MCP a la recién creada Agentic AI Foundation, un fondo dirigido (directed fund) de la Linux Foundation cofundado por Anthropic, Block y OpenAI, de modo que el protocolo se gobierna ahora en un espacio neutral respecto a los proveedores. La especificación se versiona por fecha. La revisión 2026-07-28 hizo que el protocolo central fuera sin estado, para que los servidores remotos puedan ejecutarse detrás de balanceadores de carga normales sin sesiones persistentes; añadió soporte para extensiones opcionales y sacó del núcleo las tareas de larga duración para llevarlas a una extensión oficial; endureció la autorización; y declaró obsoletas funciones más antiguas (roots, sampling y logging) con un periodo de transición de al menos un año. Para la comunicación entre agentes independientes, y no entre una aplicación y sus herramientas, Google presentó el protocolo Agent2Agent (A2A) en abril de 2025; se cedió a la Linux Foundation en junio de 2025 y, en agosto de 2026, sus patrocinadores anunciaron que también pasaría a la Agentic AI Foundation.

Desde el punto de vista arquitectónico, un servidor MCP es una dependencia que puede leer tus datos y actuar en tu nombre, así que trátalo como tal. Aprueba y fija las versiones de los servidores que pueden usarse, como parte de la seguridad de la cadena de suministro; prefiere los servidores que operas tú o un proveedor de confianza; da a las credenciales de cada servidor el mínimo privilegio que necesitan sus herramientas; recuerda que las descripciones y los resultados de las herramientas entran en el contexto del modelo y pueden llevar instrucciones inyectadas; y encamina el tráfico MCP remoto a través de los mismos controles de gateway, logging y políticas que el resto del tráfico de modelos. El protocolo estandariza la fontanería; no decide qué debería poder hacer un agente.

Memoria y estado

Los modelos no tienen estado, así que la memoria de un agente es lo que el sistema que lo rodea almacena y vuelve a poner en el contexto. La memoria a corto plazo es la conversación y los resultados de las llamadas a herramientas hasta el momento. Crece con cada paso, lo que aumenta el costo y la latencia y acaba superando la ventana, así que los agentes de larga duración la gestionan: descartan o acortan los resultados antiguos de herramientas, resumen los turnos anteriores (compactación) y mantienen un plan en curso o un archivo de notas que el modelo actualiza. La memoria a largo plazo es la información que se conserva entre sesiones, como las preferencias alimentarias de un cliente o los datos que un asistente aprendió sobre un proyecto, almacenada en una base de datos y recuperada cuando es relevante, lo que la convierte en un pequeño sistema RAG con las mismas cuestiones de relevancia, actualidad y control de acceso.

El estado de ejecución es lo que más importa para la fiabilidad. Si un agente está a mitad de una tarea de veinte pasos cuando su proceso se reinicia, debe reanudarla, no empezar de nuevo y repetir efectos secundarios. Persiste el estado después de cada paso (el contexto, el plan, qué llamadas a herramientas se completaron y sus resultados) como un punto de control (checkpoint), o ejecuta el agente en un motor de ejecución duradera que lo haga por ti, igual que se ejecutan los procesos de negocio de larga duración y las sagas. La memoria también son datos personales: decide qué se recuerda, durante cuánto tiempo, si los usuarios pueden verlo y borrarlo, y mantén la memoria de un cliente fuera del contexto de otro (consulta privacidad desde el diseño).

Sistemas multiagente

Un sistema multiagente reparte el trabajo entre varios agentes dirigidos por modelos, normalmente un agente principal que planifica y delega en subagentes, cada uno con sus propias instrucciones, herramientas y ventana de contexto, y cuyos resultados combina el principal. Las ventajas son el paralelismo, la especialización y, sobre todo, la separación del contexto: cada subagente puede explorar una gran cantidad de material y devolver solo un breve resumen. Anthropic informó en junio de 2025 de que su sistema de investigación multiagente superaba claramente a un único agente en su evaluación interna de investigación, pero también de que esos sistemas usaban unas 15 veces más tokens que los chats normales, y de que se adaptan mejor a tareas amplias y paralelizables que a tareas muy acopladas, como la mayor parte de la programación.

Los profesionales no se ponen de acuerdo sobre hasta dónde llegar. Ese mismo mes, Walden Yan, de Cognition, sostuvo en Don't Build Multi-Agents que los subagentes que trabajan con un contexto parcial hacen suposiciones contradictorias, y recomendó como opción por defecto un agente de un solo hilo con una gestión cuidadosa del contexto. Ambas posiciones coinciden en la causa de fondo: la coordinación entre agentes es una comunicación con pérdidas entre componentes que no comparten estado. Ese es el problema central de los sistemas distribuidos, y se aplica el mismo consejo. No distribuyas sin un motivo; mantén las interfaces entre agentes explícitas y estrechas; prefiere subtareas independientes; traza cada salto; y espera que el costo, la latencia y los modos de fallo se multipliquen con el número de agentes.

Ingeniería de fiabilidad para agentes

Los agentes fallan de formas nuevas: entran en bucle, llamando a la misma herramienta con los mismos argumentos; divagan, persiguiendo una cuestión secundaria hasta que se agota el presupuesto; se rinden antes de tiempo o afirman un éxito que no consiguieron; y realizan acciones que sus diseñadores no previeron. Los remedios son los patrones del Capítulo 9 y del Capítulo 6, aplicados en cada paso en lugar de una vez por solicitud, más una regla firme: los efectos secundarios con consecuencias necesitan algo más que la palabra del modelo. La sección 12.6 trata en profundidad el lado de la seguridad, la agencia excesiva; la lista de comprobación siguiente cubre la fiabilidad.