Liberamos como código abierto el AWS AI Agent Bus. La gente lo usa. Nosotros lo usamos. Recibimos mensajes de equipos que lo ejecutan y necesitan ayuda.
Este es un post honesto sobre todo ello, y lo que aprendimos.
La parte que funcionó
El servidor MCP es bueno. Respaldamos el trabajo y las capacidades.
El objetivo: darle a los asistentes de IA una interfaz interna estandarizada y utilizable hacia AWS. DynamoDB para almacenamiento persistente de clave-valor. S3 para artefactos. EventBridge para la coordinación de eventos. Un sistema de línea de tiempo para registrar qué hacen los agentes y cuándo. Dos opciones de transporte, stdio y HTTP, según cómo quieras conectarte.
MCP es la herramienta correcta para esta tarea. Hace lo que un protocolo de herramientas debería hacer: exponer una capacidad, aceptar una llamada, devolver un resultado. El contrato es limpio. Claude sabe cómo usarlo. Cuando un agente necesita escribir en DynamoDB o disparar un evento a EventBridge, el servidor MCP se encarga. Esa capa funciona.
Sin conocer más a fondo cómo funciona MCP, lo construiríamos de la misma manera de nuevo.
La parte que fue un desastre
La capa de orquestación es donde nos equivocamos. El contexto de MCP se desbordaba en las ejecuciones del modelo. Añadir cosas como colas de reintentos y patrones de gestión de concurrencia se convirtió en un trabajo en sí mismo. Cuando lo construimos, MCP era un éxito y mucha gente estaba aprendiendo sobre ello, incluidos nosotros (y Anthropic, al parecer).
Construimos un sistema multiagente sobre el servidor MCP. Un Conductor que fijaba el plan. Críticos que verificaban la seguridad y la aprobación. Especialistas con conocimiento de dominio en React, Django y Terraform. Un sistema de memoria que combinaba almacenamiento KV, historial de línea de tiempo y embeddings vectoriales. Se veía bien en el README.
En la práctica, era frágil.
Los roles eran ficción. Conductor, Crítico, Especialista: eran ingeniería de prompts disfrazada de arquitectura. Nada estructural separaba lo que el Crítico podía acceder de lo que el Especialista podía acceder. Teníamos a un agente diciéndole a otro qué hacer mediante lenguaje natural, y el “otro agente” era simplemente Claude con un system prompt diferente. La coordinación era pura intuición.
La memoria compartida creó un problema de coherencia. Dimos a los agentes acceso al mismo sistema de memoria para que tuvieran contexto. Cuando los agentes comparten memoria sin restricciones de alcance, actúan sobre el contexto de los demás de maneras que no pretendíamos. Un agente extraía historial de línea de tiempo de un paso anterior del flujo de trabajo y lo incorporaba en una decisión que no le correspondía tomar. Depurar eso era una pesadilla.
No había límite de confianza. El supuesto es que el agent bus es una herramienta interna, la seguridad era simplemente cuestión de usar lo que AWS proporcionaba. Cualquier agente del sistema podía escribir en el almacén KV, disparar eventos a EventBridge o actualizar la línea de tiempo. Las políticas de IAM hacían parte del trabajo, pero nada en la capa de aplicación imponía qué agente podía tomar qué acción en qué punto del flujo de trabajo. Estábamos a un prompt injection de tener un mal día.
El humano en el circuito fue una idea de último momento. Dijimos que el sistema tenía capacidades de humano en el circuito. Técnicamente cierto. Lo implementamos como un patrón de pausar y sondear: un agente escribía un registro de aprobación pendiente en DynamoDB, y algo eventualmente lo revisaba. Eso funciona en condiciones tranquilas. No es un plano de control. Un humano no podía ver el estado del flujo de trabajo. No podía intervenir a mitad de un paso. Podía aprobar o rechazar un artefacto completado. Eso no es lo mismo.
Lo que aprendimos
El Agent Bus nos obligó a ser específicos sobre lo que la coordinación multiagente realmente requiere. No funciones que suenan bien en un README. Propiedades estructurales que hacen que los agentes sean seguros de ejecutar juntos.
El contexto debe estar acotado. El orquestador necesita el panorama completo. Los agentes posteriores, no. Cada agente opera con un mandato: aquí está tu tarea, aquí está la información que necesitas, aquí no hay nada más. Cuando violábamos esto, obteníamos problemas de coherencia. Cuando lo imponíamos manualmente, las cosas funcionaban.
La autoridad debe tener un límite de tiempo. Un agente autorizado a actuar hace una hora no debería seguir actuando sobre esa instrucción. No teníamos un concepto de TTL sobre una capacidad. Agentes obsoletos tomando acciones sobre contexto obsoleto es un problema de producción real.
EventBridge es infraestructura, no un protocolo. Seguíamos recurriendo a él como columna vertebral de coordinación. Entrega tu evento. No te dirá quién estaba autorizado a enviarlo, si el agente receptor tiene el mandato de actuar sobre él, ni si la acción tiene un rastro de auditoría que viva fuera de la plataforma.
Los comprobantes pertenecen a los principales. Cuando un agente toma una acción, un paso se completa o un humano aprueba, ese registro debería vivir con la organización que inició el flujo de trabajo. Nosotros lo almacenábamos en nuestra tabla de DynamoDB. Teníamos observabilidad. No teníamos rendición de cuentas.
A dónde nos llevó esto
Los problemas seguían apuntando al mismo vacío: no había capa de gobernanza entre el servidor MCP y la lógica de aplicación. Cada equipo que construye sistemas multiagente llena ese vacío de forma distinta, en su código de aplicación, de manera inconsistente.
Ese vacío es lo que el Principal Agent Protocol está construido para llenar.
PAP pone la gobernanza a nivel de protocolo. El orquestador mantiene el contexto completo. Los agentes posteriores operan sobre mandatos acotados y vinculados criptográficamente con decaimiento basado en TTL. Los tokens de capacidad son de un solo uso. Los comprobantes se co-firman y los mantiene el principal. La confianza es estructural.
El servidor MCP del Agent Bus se ubica limpiamente por debajo de PAP. Hace bien lo que hace. PAP maneja lo que la capa de orquestación del Agent Bus no logró manejar, sin exigir que cada equipo resuelva los mismos problemas en su propio código de aplicación.
Lo que construimos ahora
Todo lo que construimos corre sobre PAP. Cada proyecto con clientes. Cada herramienta interna. El servidor MCP sigue manejando lo que maneja bien. PAP maneja todo lo que está por encima.
No estamos esperando a que el ecosistema nos alcance. Los problemas que el Agent Bus expuso son reales, y todo equipo que construye sistemas multiagente se topa con ellos. La mayoría los resuelve en el código de aplicación, de manera inconsistente, hasta que algo se rompe en producción.
No tienes por qué hacer eso. PAP es de código abierto. La especificación está publicada. La implementación en Rust está disponible. Empieza con la misma base que usamos nosotros.