Agent-to-agent: cuando los agentes de IA hablan entre sí

Este año hemos construido varios sistemas en los que no es un único LLM el que responde a una pregunta, sino varios agentes con tareas distintas que se pasan el trabajo entre sí. La experiencia es mixta: para ciertas tareas es el único camino viable, mientras que en otras un workflow sencillo y determinista resulta más barato, más rápido y más fiable. En este artículo resumimos lo que aprendimos.

Tool-use y MCP: el lenguaje común

La base de la colaboración entre agentes es que el modelo pueda invocar herramientas: llama a una función con parámetros estructurados y continúa razonando con el resultado que recibe. El Model Context Protocol (MCP) estandariza esto: las herramientas viven en un servidor aparte, con un esquema autodescriptivo, y cualquier agente, con cualquier proveedor de modelos, accede a ellas de la misma manera.

En nuestro caso esto significa, en la práctica, que nuestros sistemas internos (consulta al CRM, reserva en el calendario, inicio de llamadas, estado de facturación) están expuestos como servidores MCP, y los agentes solo acceden a cualquier cosa a través de ellos. Esto tiene dos ventajas: las herramientas se prueban y se gestionan sus permisos en un único lugar, y el prompt del agente no contiene nada sobre los detalles de la integración.

La lección más importante al diseñar herramientas: pocas herramientas bien delimitadas son mejores que muchas pequeñas. Una herramienta “busca al cliente por su correo electrónico” es más fiable que un ejecutor genérico de SQL.

Patrones de orquestación

Usamos dos patrones de forma habitual.

En la configuración planner/worker, un agente descompone la tarea en pasos y asigna cada paso a un worker con un contexto más acotado y que corre con un modelo más barato. El worker no ve la conversación completa, solo su propia tarea y las herramientas que necesita para ella. Esto reduce el coste y las posibilidades de error, pero la calidad del planner determina la del conjunto.

En el patrón de handoff, un agente cede en un momento dado la conversación a otro, junto con el contexto completo o filtrado. En atención al cliente por voz es el caso típico: un agente recepcionista genérico reconoce que se trata de una reserva de cita y la traspasa al agente de reservas, que tiene instrucciones y herramientas más acotadas pero más precisas. El handoff es invisible para quien llama, pero para el sistema es un cambio de estado claro.

En ambos patrones la comunicación es estructurada: los agentes no “conversan” en texto libre, sino que se pasan mensajes validados contra un esquema. El diálogo agente-agente en texto libre queda bien en las demos, pero en la práctica es largo, caro y difícil de depurar.

Guardrails y human-in-the-loop

Más agentes implican más posibilidades de error, y los errores se propagan. Por eso las líneas de defensa no están en el prompt, sino en el código:

• cada llamada a una herramienta pasa por una comprobación de permisos, según la identidad del agente y el tenant;
• las operaciones de escritura (reservar, enviar correos, cambiar estados) están en una lista de permitidos explícita; el resto de herramientas solo lee;
• la entrada y la salida se validan contra un esquema; si el agente devuelve un formato incorrecto, reintentamos una vez y después señalamos el error;
• límite de pasos y de coste por agente y por ejecución completa, para que un agente que da vueltas en círculo no pueda correr indefinidamente.

Hay decisiones que no permitimos automatizar en absoluto: los reembolsos, la modificación de condiciones contractuales o el cierre de una reclamación escalada. En estos casos el agente prepara la propuesta y una persona la aprueba, desde una sola línea, con un solo clic. El human-in-the-loop no es una debilidad del sistema, sino una parte diseñada de él: uno de los resultados bien definidos del trabajo del agente es “pregunta a una persona”.

Observabilidad: tracing entre agentes

Depurar una ejecución multiagente sin tracing es una tarea imposible. Cada ejecución es un único trace, dentro del cual cada paso de agente, cada llamada al modelo y cada llamada a herramienta es un span, con su entrada, su salida, el número de tokens y la duración. En los handoffs el identificador del trace se transmite, de modo que el recorrido completo se ve en un único lugar.

De ahí sale también el análisis de coste y de latencia. Con varios agentes el tiempo de respuesta se acumula: si un paso del planner dura 2 segundos y tres workers corren uno tras otro, quien llama espera de 8 a 10 segundos. En un sistema de voz eso es inaceptable, por lo que allí los workers corren en paralelo donde es posible y quien llama recibe mientras tanto una señal de relleno. Y el coste se multiplica con facilidad, porque cada agente reenvía su propio contexto una y otra vez; la caché de prompts y los workers de contexto acotado marcan aquí una gran diferencia.

Cuándo tiene sentido y cuándo no

Varios agentes están justificados cuando los pasos de la tarea no se conocen de antemano, las subtareas requieren conocimientos y conjuntos de herramientas distintos, y un paso erróneo se puede revertir o condicionar a una aprobación humana. Un ejemplo típico es un caso complejo de atención al cliente en el que la identificación, la gestión y el seguimiento tocan sistemas diferentes.

No están justificados cuando el orden de los pasos es conocido y constante. Un proceso del tipo “al terminar la llamada escribe un resumen, envíalo por correo y actualiza el CRM” es un workflow normal con un único paso que contiene un LLM (el resumen). En ese caso el enfoque con agentes solo añade incertidumbre, coste y latencia.

Nuestra regla es sencilla: primero describimos el proceso como un workflow determinista. Donde eso no funciona, porque la decisión depende realmente del contexto, entra un agente. Donde el contexto de un agente crece demasiado, lo dividimos en varios. A la inversa, partiendo de agentes, casi siempre obtenemos un sistema sobrecomplicado.