Agentes que conversan sin perder identidad, coste ni responsabilidad

De invocar a conversar

La forma mínima de delegación es una llamada: un agente envía una tarea a otro y recibe una respuesta. Es suficiente para consultas acotadas, pero pierde propiedades importantes cuando el trabajo necesita varios turnos:

• el receptor no sabe si el mensaje es una solicitud, una consulta o una notificación;
• una aclaración se convierte en error o se dirige a la persona equivocada;
• una nueva llamada puede olvidar el contexto compartido;
• no existe un compromiso identificable sobre quién aceptó el trabajo;
• la entrega asíncrona y los reintentos pueden duplicar efectos;
• el coste y la responsabilidad se separan de la tarea raíz.

Una capa de comunicación convierte el intercambio en una entidad explícita. No sustituye al runtime: le proporciona un protocolo común para descubrir, consultar, delegar, responder y continuar.

El mensaje tiene intención, no solo contenido

La teoría de los actos de habla distingue el contenido de un enunciado de la acción comunicativa que realiza. FIPA-ACL trasladó esta idea a sistemas multiagente mediante performativas con semántica definida.

Un subconjunto práctico puede incluir:

Performativa	Significado operativo
request	Solicitud de realizar una tarea.
query	Petición de información o aclaración.
inform	Entrega de un hecho, estado o resultado.
agree	Aceptación de un encargo.
refuse	Rechazo acompañado de una razón.
failure	Notificación de que el encargo no pudo completarse.
cancel	Solicitud de detener un compromiso existente.

La performativa no demuestra que el contenido sea verdadero. Aporta un marco para interpretarlo y para decidir qué transición de estado corresponde. Un refuse razonado, por ejemplo, es información útil; no debería degradarse a una excepción opaca.

El sobre como frontera de confianza

El cuerpo del mensaje contiene lenguaje generado y debe tratarse como dato no confiable. La identidad, la conversación y la genealogía pertenecen al sobre construido por el motor.

El sobre debe conservar al menos:

• emisor y destinatario verificados;
• persona o tarea raíz en cuyo nombre se actúa;
• performativa;
• identificadores de mensaje y conversación;
• relación con el mensaje anterior;
• versión fijada del agente;
• cadena de delegación y correlación de coste;
• referencias a artefactos, no suplantaciones textuales de identidad.

Extracto. Un agente no es quien afirma ser en el cuerpo del mensaje. Es quien el runtime ha autenticado y escrito en el sobre.

Esta regla impide que un agente se presente como otro o declare una aprobación en nombre de la persona. La prosa puede proponer; la autoridad debe proceder del canal y de la policy.

Conversación como contexto común

Una conversación conserva el contexto acumulado entre participantes. Si un agente vuelve a consultar al mismo interlocutor, utiliza la misma sesión y la versión del agente fijada al abrirla. Una publicación nueva del interlocutor no cambia retroactivamente la semántica del diálogo en curso.

La fijación de versión es importante porque el contexto común presupone un comportamiento relativamente estable. Las conversaciones nuevas pueden tomar una versión posterior; las existentes conservan la suya hasta un cierre o una migración explícita.

Cuando el receptor necesita una aclaración, no ha fallado necesariamente. Puede emitir una query, suspender su ejecución y reanudarla cuando el interlocutor responda. El mismo patrón sirve para humano-agente y agente-agente, siempre que se conserve quién puede responder a cada clase de pregunta.

El buzón como fuente de activación

En un modelo inspirado en actores, cada agente recibe mensajes en un buzón y procesa de forma serializada los que pertenecen a la misma conversación. La llegada de un mensaje puede activar al destinatario sin mantener vivo al emisor.

La entrega asíncrona necesita garantías explícitas:

• al menos una vez: un mensaje persistido puede reintentarse tras un fallo;
• idempotencia: el mismo identificador no produce dos ejecuciones lógicas;
• orden local: los mensajes de una conversación mantienen su secuencia;
• caducidad: un encargo vencido no se ejecuta silenciosamente;
• dead letter: los mensajes agotados siguen siendo observables.

Estas garantías no equivalen a «exactamente una vez» sobre el mundo exterior. Si la herramienta tiene efectos, el destinatario necesita claves de idempotencia, comprobación de estado o una operación compensatoria.

Fan-out y respuestas que reactivan

Una delegación asíncrona puede aceptar el encargo de inmediato y entregar el resultado después mediante otro mensaje. Varias delegaciones producen un fan-out: el agente raíz continúa o suspende su turno y las respuestas lo reactivan a medida que llegan.

El mismo canal sirve para tareas largas, notificaciones y eventos futuros. La ventaja no está en utilizar siempre asincronía: una consulta breve sigue siendo más sencilla de forma síncrona. El protocolo permite escoger sin perder la correlación.

Ciclos: distinguir topología de repetición

Prohibir que un agente reaparezca en una cadena evita algunos bucles, pero también impide topologías legítimas. El problema real no es que A aparezca dos veces; es que la misma tarea vuelva a A como trabajo nuevo sin aportar estado.

ALLAN utiliza dos ideas para separar ambos casos:

1. Genealogía estructurada. Cada salto conserva ruta, conversación y huella de tarea. La ruta permite detectar una reentrada, como los encabezados Via de SIP ayudan a detectar bucles de encaminamiento.
2. Plegado de reentrada. Si un descendiente necesita criterio de un agente que ya participa más arriba, la reentrada se convierte en una consulta de solo lectura sobre su contexto, no en otra ejecución capaz de delegar.

El diseño busca mantener acíclicas las aristas activas del grafo de trabajo, mientras la información puede circular lateralmente. La profundidad sigue siendo un fusible defensivo; los presupuestos y compromisos son los límites de recursos y trabajo duplicado.

Compromisos y duplicados semánticos

Cuando un agente acepta una tarea, el sistema registra un compromiso asociado a la tarea raíz. Si recibe después una solicitud equivalente, puede devolver el estado y la conversación existente en lugar de iniciar trabajo duplicado.

La equivalencia semántica nunca es perfecta. Una huella textual es transparente pero produce falsos negativos; una similitud aprendida puede producir falsos positivos. Por eso el registro de compromisos debe ser observable y su decisión revisable.

Política: decidir y aplicar por separado

La comunicación atraviesa puntos de aplicación de políticas: descubrimiento, delegación, activación, acceso a artefactos y uso de herramientas. Conviene separar:

• el punto que decide si una acción está permitida y qué obligaciones impone;
• el punto que aplica esa decisión antes de ejecutar.

Esta separación, habitual en modelos de control de acceso, permite evolucionar la política sin reescribir cada mecanismo de comunicación. La capacidad declarada por un agente nunca debe ampliar los permisos concedidos por la organización.

Aclaración no es aprobación

Una aclaración responde a «¿qué quieres decir?» o «¿qué dato falta?». Debe volver al interlocutor que formuló el encargo, sea humano o agente.

Una aprobación responde a «¿está autorizada esta acción?». Debe llegar a la persona o autoridad responsable de la tarea raíz. Un agente intermedio puede transmitir contexto, pero no convertirse en aprobador por proximidad conversacional.

Colapsar ambos flujos en un estado genérico de espera humana destruye esta distinción. El runtime necesita conservar tipo de solicitud, destinatario legítimo y estado reanudable.

Estado y límites

El núcleo de conversaciones, buzón, genealogía, compromisos, política y HITL anidado cuenta con implementación en la revisión examinada, aunque el documento de diseño original aún se presentaba como propuesta. Permanecen en evolución la política empresarial detallada, determinadas métricas agregadas y la automatización de algunos caminos de reanudación.

FIPA aporta un vocabulario formal, no una solución completa para agentes LLM. La capa de ALLAN es una adaptación pragmática que debe evaluar entrega, duplicados, seguridad semántica, coste y comportamiento adversarial.

Referencias

Fuentes editoriales de ALLAN

• Platform Server/docs/agent-communication-design.md.
• Platform Server/docs/agent-communication-implementation-plan.md, utilizado únicamente para reconciliar el estado de implementación.

Fuentes externas

• FIPA, ACL Message Structure Specification y Communicative Act Library Specification.
• Searle, J. R., A classification of illocutionary acts, Language in Society, 1976.
• A2A Project, Agent2Agent Protocol Specification 1.0.0.
• Wu, Q. et al., AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation, preprint de 2023; versión revisada por pares en COLM 2024.
• IETF, SIP: Session Initiation Protocol, RFC 3261, 2002.
• NIST, Guide to Attribute Based Access Control, SP 800-162, actualización de 2019.