Agentes LLM con objetivos opuestos: del colapso al control

78,1 % frente a 46,1 %. Esa es la diferencia en tasa de contacto con asesor que reporta un trabajo publicado el 13 de agosto en arXiv cuando se coloca una capa de gobierno entre dos agentes LLM con objetivos enfrentados. El experimento corre sobre 60.000 simulaciones en un entorno de servicios financieros simulado: un agente de sitio empuja al visitante hacia el contacto con un asesor, mientras el visitante mantiene una resistencia psicológicamente realista.

Lo interesante no es el número, sino el diagnóstico que lo precede. Según los autores, cuando dos agentes con objetivos estructuralmente opuestos conversan durante varios turnos sin una función de objetivo compartida, lo que aparece no es competencia sino colapso: el visitante capitula, el agente del sitio deja de variar su enfoque y la conversación termina sin que ninguno de los dos haya conseguido lo que buscaba. Es un fallo de arquitectura, no de prompt.

Qué propone el Experience Orchestrator

El paper, Dynamic Governance of Multi-LLM Agent Systems for Collaborative Conversational Outcomes, sostiene que esa función de objetivo ausente puede sustituirse por una capa de gobierno de corte control teórico. El sistema, llamado Experience Orchestrator (EO), gobierna la trayectoria conjunta de la conversación con tres mecanismos:

1. Un Contextual Bandit que selecciona qué contenido servir en cada turno, con los brazos calibrados a partir de analítica web real y no de valores inventados.
2. Un controlador PID que impone consistencia de comportamiento mediante restricciones dinámicas de esquema, es decir, ajustando sobre la marcha lo que el agente puede o no puede decir.
3. Un rastreador de creencias POMDP que mantiene un modelo probabilístico de la intención del visitante en lugar de asumirla fija.

Sobre 60.000 simulaciones, la combinación alcanza 78,1 % de contacto con asesor en visitantes de alta intención frente al 46,1 % de un control LLM ingenuo. El resumen público se corta justo cuando empieza a desglosar cuánto aporta cada mecanismo por separado, así que la atribución interna queda pendiente de leer el texto completo.

Por qué importa fuera del laboratorio

Casi toda la literatura y casi todo el tooling multiagente que se usa a diario asume cooperación: un orquestador reparte tareas entre subagentes que quieren lo mismo. Ese supuesto se rompe en cuanto hay negociación, atención al cliente con fricción real, moderación o evaluación adversarial. Ahí no hay función de objetivo compartida y el sistema se degrada de una forma que los benchmarks de tarea única no capturan.

La segunda idea que merece atención es dónde vive el control. EO no es un prompt más largo ni un modelo afinado: es una capa externa que observa la trayectoria y actúa sobre ella. Eso la hace, al menos en teoría, portable entre modelos y auditable por separado, algo que un prompt de sistema de cuatro mil palabras nunca es.

Para quién es útil

Para quien esté montando agentes conversacionales con objetivo de negocio y ya haya visto la conversación morir a los cinco turnos. También para quien diseña evaluaciones adversariales entre agentes y necesita que el evaluador no se rinda. Y, de forma menos directa, para cualquiera que orqueste subagentes en Claude Code: la lección aplicable es que la política de parada y de cambio de estrategia debería ser explícita y medible, no una instrucción en lenguaje natural que el modelo interpreta como puede.

Lo que conviene mirar con lupa

Todo ocurre en simulación. El visitante resistente es otro LLM, y un LLM al que se le pide resistencia no se comporta como una persona que desconfía de un banco. Las 60.000 corridas dan potencia estadística, pero sobre un mundo cerrado. El dominio elegido, servicios financieros, tiene además incentivos muy marcados: empujar a alguien hacia el contacto con un asesor es exactamente el tipo de objetivo donde una capa de control optimizando conversión merece escrutinio ético, y el resumen no entra en ello.

En ElephantPink llevamos meses montando orquestaciones de subagentes y la pieza que más frágil nos resulta no es el modelo, sino el pegamento entre agentes: quién decide cuándo parar, cuándo cambiar de enfoque y con qué evidencia. Tratar ese pegamento como un problema de control en vez de como un prompt más largo nos parece la dirección correcta, aunque la validación siga siendo sintética.