Agentes A2A: que otros sistemas le encarguen trabajo a tu agente

Hasta ahora hemos hablado de agentes que trabajan con una persona delante: alguien abre Codex o Claude Code y le pide algo. Pero hay otro caso cada vez más habitual: que el encargo venga de otro sistema. Un ticket que entra, un proceso nocturno, otro agente que necesita que el tuyo revise un despliegue.

Para eso existe A2A (agent-to-agent), un protocolo abierto para que un agente le mande una tarea a otro y siga su estado.

Qué es A2A, en dos piezas

• La Agent Card, un documento público en /.well-known/agent-card.json que dice quién es el agente, qué sabe hacer y cómo hay que autenticarse para hablarle.
• message/send, la llamada JSON-RPC con la que se le manda un mensaje. La respuesta es una tarea con su estado: completada, en curso o esperando algo.

El mismo agente, en otro sitio

En Ploybot, un agente A2A no es otro tipo de agente. Es el mismo que ya tienes en el catálogo, con su identidad, sus capabilities, su política y su historial. Lo que cambia es dónde razona: en lugar de hacerlo en el portátil de una persona, lo hace en un runtime dentro de tu cuenta cloud.

La receta del agente dice qué prompt usa, con qué modelo, qué tools MCP tiene y cuánto puede gastar. ploybot deploy la lleva a tu cuenta: AWS Lambda, un servicio de ECS Fargate o Azure Functions. Las credenciales de la nube y la clave del modelo se piden en ese momento y se quedan en tu cuenta (Secrets Manager o los ajustes de la Function App), no en el catálogo de Ploybot.

Quién puede encargarle trabajo

La Agent Card es pública, porque es descubrimiento. Pero message/send exige un Bearer. El despliegue genera ese token, lo guarda en tu cuenta y te lo enseña una vez. Sin él, el runtime contesta 401 y no gasta nada. Y si no hay token configurado, el runtime directamente no arranca: dejarlo abierto tiene que ser una decisión explícita, no un olvido.

El gasto del modelo no es una tool

Hay un detalle de diseño que importa. Si el propio modelo tuviera que pedir su presupuesto por MCP, o no llegaría a pedirlo o se lo contaría a sí mismo. Por eso el runtime reserva el gasto antes de cada llamada al modelo, contra el control plane. Si la reserva no se concede, no hay llamada.

Lo sensible sigue esperando a una persona

Las tools del agente A2A son las mismas de siempre, por MCP, con la misma política. Cuando algo necesita aprobación, la tarea A2A pasa a auth-required. A quien decide le llega el aviso como con cualquier otra operación, y cuando aprueba, quien hizo el encargo reintenta el mismo mensaje y la tarea sigue.

Si la receta cita un endpoint de IA verificado, Prompt Shield corre dentro del propio runtime: revisa cada prompt, ofusca los datos personales en modo estricto y sella en la evidencia que lo hizo.

Pruébalo desde el navegador

La consola tiene un chat A2A en /console/a2a/. Le das la URL del agente o de su Agent Card y conversas con él: ves los estados de la tarea, las respuestas y el JSON de cada una. Si el agente es tuyo y tienes acceso, la consola obtiene un permiso corto a partir de tu sesión y no tienes que manejar el Bearer. También sirve para probar agentes A2A de fuera de Ploybot.

¿Y entre tus propios agentes?

Cuando el que encarga es otro agente tuyo, Ploybot añade una regla más: tiene que existir una política explícita que diga que el agente X puede invocar al Y. Si X le delega una capability, Y recibe un permiso nuevo que lo dice, y todo lo que haga con él vuelve a pasar por política, aprobación y gateway. Y no se hace pasar por X: sigue siendo Y, y así queda escrito.

Empieza

Crea la cuenta, da de alta un agente y prueba el chat A2A de la consola. Si quieres llevarlo a tu cuenta de AWS o Azure, escríbenos y lo preparamos contigo.