Entre ocho y diez segundos de silencio: lo que aprendimos de los agentes de IA que hablan entre sí

Si el paso de un agente planificador dura 2 segundos y después corren tres workers uno tras otro, quien está al teléfono escucha entre 8 y 10 segundos de silencio. Este año hemos construido varios sistemas en los que una pregunta la responden varios agentes con tareas distintas, que se pasan el trabajo entre sí. El balance es desigual. Para ciertas tareas es el único camino viable; en otras, un workflow sencillo y determinista resulta más barato, más rápido y más fiable. Esto es lo que aprendimos.

Tool-use y MCP: un idioma común

Los agentes pueden colaborar porque los modelos saben invocar herramientas: llaman a una función con parámetros estructurados y siguen razonando con el resultado. El Model Context Protocol (MCP) lo estandariza. 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 forma.

En nuestros sistemas, los servicios 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 tocan algo a través de ellos. Eso tiene dos ventajas: las herramientas se prueban y se gestionan sus permisos en un único sitio, y el prompt del agente no contiene ningún detalle de la integración.

La principal lección al diseñar herramientas es que unas pocas bien delimitadas funcionan mejor 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.

Planificadores, ejecutores y traspasos

Usamos dos patrones de forma habitual.

En el esquema planner/worker, un agente descompone la tarea en pasos y entrega cada uno a un worker que corre con un modelo más barato y un contexto más acotado. El worker no ve la conversación completa, solo su tarea y las herramientas que necesita. Así bajan el coste y el margen de error, aunque el conjunto depende por entero de la calidad del planner.

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

En ambos patrones la comunicación es estructurada. Los agentes se pasan mensajes validados contra un esquema y no “conversan” en texto libre. El diálogo libre entre agentes luce en las demos; en la práctica es largo, caro y difícil de depurar.

Los límites, en el código

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

• 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.

Algunas decisiones nunca se toman de forma automática: los reembolsos, la modificación de condiciones contractuales o el cierre de una reclamación escalada. En esos casos el agente prepara la propuesta y una persona la aprueba, desde una sola línea, con un clic. El human-in-the-loop es una parte diseñada del sistema. Uno de los resultados bien definidos del trabajo de un agente es “pregunta a una persona”.

Una ejecución, un trace

Depurar una ejecución multiagente sin tracing es imposible. Cada ejecución es un único trace, y dentro de él 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. El identificador del trace se transmite en los handoffs, de modo que el recorrido completo se ve en un solo lugar.

De ahí sale también el análisis de coste y latencia. Con varios agentes, los tiempos de respuesta se suman: un paso de planner de 2 segundos seguido de tres workers en serie supone una espera de 8 a 10 segundos. En un sistema de voz eso es inaceptable, así que allí los workers corren en paralelo siempre que se puede y quien llama recibe mientras tanto una señal de relleno. El coste también 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.

Primero, el workflow

Varios agentes están justificados cuando los pasos de la tarea no se conocen de antemano, las subtareas exigen conocimientos y herramientas distintos y un paso erróneo puede revertirse o someterse a 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 afectan a sistemas diferentes.

No lo están cuando el orden de los pasos es conocido y fijo. “Al terminar la llamada, escribe un resumen, envíalo por correo y actualiza el CRM” es un workflow corriente con un LLM en un único paso, el resumen. Ahí 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 basta, porque la decisión depende de verdad del contexto, entra un agente. Cuando el contexto de un agente crece demasiado, lo dividimos en varios. Al revés, empezando por los agentes, casi siempre sale un sistema sobrecomplicado.