Sistemas multi-agente

Cuando separar la tarea resuelve un problema concreto que el agente único no puede resolver, porque cada agente añadido es un salto más que hay que asegurar, trazar y pagar. En Nortia la duda aparece cuando soporte quiere que su agente tramite devoluciones completas: hacerlo todo en él supondría tener la tool de abonos disponible en cualquier conversación, llenar su contexto de consultas intermedias y redesplegar la consola cada vez que finanzas cambie su política. En la lección se ve con qué criterio decidir si una tarea merece un subagente o basta con ampliar las tools del agente existente.

Sí: para quien lo invoca, un agente publicado como servidor MCP es una tool más, con nombre, descripción y esquema, aunque detrás haya otro modelo que decide y usa sus propias tools. La dificultad está en el contrato, en decidir qué viaja como argumento, qué en _meta y qué en el token, y en que la identidad de la persona llegue al último servidor sin reenviar tokens, algo que la especificación prohíbe. En la lección se diseña ese contrato para un agente que tramita devoluciones en Nortia y se lleva la identidad, el inquilino y la traza a lo largo de los dos saltos.

Los que aparecen cuando la salida de un agente se convierte en la entrada de otro: bucles en los que los agentes se reactivan entre sí, un coste que crece con cada salto, trazas que se cortan por el camino y agentes que terminan actuando con más permisos de los que tenía la persona que hizo la petición. La especificación aporta piezas útiles, como reservar en _meta las claves de W3C Trace Context para propagar la traza, pero ninguna de ellas evita estos fallos por sí sola. En la lección se aprende a reconocer cada uno en el sistema de Nortia y a ponerle freno.