PolicyBank: Evolving Policy Understanding for LLM Agents

1. El Problema: La Brecha entre Especificación y Requisito

El artículo aborda un desafío crítico en el despliegue de agentes de LLM en entornos productivos: la incapacidad de los agentes para comprender y adaptarse a políticas organizacionales imperfectas.

• Contexto: Los agentes operan bajo políticas especificadas en lenguaje natural (NL) por expertos humanos. Estas políticas definen límites de comportamiento (ej. reglas de compensación, restricciones de acceso).
• La Falla Fundamental: Las especificaciones en lenguaje natural son inherentemente ambiguas, incompletas o contienen contradicciones lógicas. Esto crea una brecha de política (Policy Gap) entre:
  • $\pi_{spec}$ (Política Especificada): Lo que dice el texto escrito (a menudo literal y rígido).
  • $\pi_{req}$ (Política Requerida): La intención real del negocio o la lógica subyacente correcta.
• Tipos de Fallos:
  • Fallo de Ejecución (Tipo I): El agente no sigue las reglas escritas debido a limitaciones de razonamiento (ej. no sabe usar una herramienta).
  • Fallo de Alineación (Tipo II): El agente sigue las reglas escritas perfectamente, pero el resultado es incorrecto porque la regla escrita es defectuosa.
• Limitación de Métodos Actuales: Los mecanismos de memoria existentes (como ReasoningBank o Synapse) tratan la política escrita como una "verdad fundamental" inmutable. Si un agente falla por una brecha de especificación, estos métodos refuerzan el comportamiento "cumplidor pero incorrecto" en lugar de cuestionar la premisa de la política.

2. Metodología: PolicyBank

Los autores proponen PolicyBank, un mecanismo de memoria diseñado para permitir que el agente evolucione su comprensión de la política de forma autónoma mediante interacción y retroalimentación correctiva.

• Arquitectura del Sistema:

  1. Inicialización: La memoria ($M_0$) se carga con la documentación de políticas, el esquema de la base de datos y las definiciones de herramientas.
  2. Ejecución (Online): El agente interactúa con el usuario. A diferencia de métodos estáticos, el agente utiliza una herramienta llamada retrieve_policy() para buscar dinámicamente las reglas relevantes según el contexto cambiante de la conversación.
  3. Revisión (Offline): Tras cada tarea, un Agente de Política (un LLM dedicado) analiza la trayectoria de la tarea y la retroalimentación del desarrollador (señal de éxito/fracaso y explicación en NL).
  4. Actualización de Memoria: El Agente de Política decide si:
     • Añadir: Una nueva entrada para un caso no cubierto.
     • Revisar: Corregir una entrada existente si la interpretación anterior era incorrecta o incompleta.
     • Omitir: Si no hay nueva información.

• Esquema de Memoria Estructurada:
  En lugar de almacenar texto plano, PolicyBank guarda insights a nivel de capacidad de herramienta. Cada entrada es una tupla que incluye:

  • TRIGGER: Cuándo aplica la capacidad.
  • PRECONDITIONS: Pasos de verificación necesarios.
  • ELIGIBILITY: Condiciones lógicas para permitir la acción (usando lógica booleana clara).
  • ACTION: Procedimiento a seguir.
  • KEY INSIGHT: El "delta" aprendido que aclara la ambigüedad entre $\pi_{spec}$ y $\pi_{req}$.

• Evaluación y Benchmarking:
  Los autores extendieron el benchmark $\tau$-Bench (dominios de aerolíneas y retail) para crear un entorno de prueba riguroso:

  • Identificaron tareas donde la política escrita fallaba frente a la verdad fundamental.
  • Crearon tareas hermanas (sister tasks): Variaciones de una tarea padre (simplificada, diferente instancia, variante compleja) para probar si el agente generalizó la corrección de la política y no solo memorizó una solución específica.

3. Contribuciones Clave

1. Formalización del Problema: Definen y formalizan el concepto de "Comprensión de Política Evolutiva", distinguiendo claramente entre fallos de capacidad (ejecución) y fallos de especificación (alineación). Identifican tres clases estructurales de brechas: Ambigüedad de Alcance, Excepciones No Especificadas y Contradicciones Lógicas.
2. Método PolicyBank: Introducen un mecanismo de memoria que mantiene insights granulares y específicos de herramientas, refinados iterativamente mediante un bucle de retroalimentación dedicado, sin necesidad de reescribir manualmente las reglas.
3. Nuevo Testbed: Proporcionan una extensión rigurosa de $\tau$-Bench con brechas de política controladas y tareas hermanas, permitiendo aislar y medir específicamente la capacidad de los agentes para corregir malentendidos de especificación.

4. Resultados Experimentales

Los experimentos se realizaron con modelos de vanguardia (Gemini-3.0-Pro y Claude-4.5-Opus) en los dominios de aerolíneas y retail.

• Fracaso de los Baselines: Los mecanismos de memoria actuales (Synapse, AWM, ReasoningBank) y los agentes sin memoria obtuvieron un rendimiento cercano a cero en las tareas hermanas (escenarios de brecha de política). Esto confirma que, sin un mecanismo de actualización de política, los agentes no pueden superar las especificaciones defectuosas.
• Éxito de PolicyBank:
  • PolicyBank logró cerrar hasta el 82% de la brecha hacia un oráculo humano.
  • En el dominio de aerolíneas con Gemini-3-Pro, la tasa de éxito en tareas hermanas subió de ~0.01 (sin memoria) a 0.74 (PolicyBank).
  • En el dominio de retail, PolicyBank alcanzó una tasa de éxito de 0.83 en tareas hermanas, superando significativamente a los baselines.
• Consistencia: PolicyBank mejoró no solo la tasa de éxito promedio, sino también la consistencia (métrica $pass^k$), reduciendo la variabilidad en el comportamiento del agente, lo cual es crucial para aplicaciones en producción.
• Análisis de Retroalimentación: Se demostró que la retroalimentación binaria (éxito/fracaso) es insuficiente para corregir brechas de política; se requiere una explicación en lenguaje natural para que el Agente de Política identifique qué cláusula específica es incorrecta.

5. Significado e Impacto

Este trabajo representa un cambio de paradigma en la gestión de agentes autónomos:

• De la Verificación a la Evolución: Mientras que la investigación anterior se centraba en verificar o guardar (guardrails) que el agente cumpla reglas estáticas, PolicyBank permite que el agente aprenda y refine esas reglas basándose en la experiencia.
• Resolución de Ambigüedad: Ofrece una solución práctica al problema clásico de la ambigüedad en los requisitos de software, automatizando la detección de divergencias entre la documentación escrita y la lógica de negocio real.
• Escalabilidad: Al automatizar la corrección de interpretaciones de políticas, se reduce la carga de los expertos humanos, quienes no necesitan editar manualmente miles de reglas cada vez que se descubre un caso borde; el agente puede aprender y generalizar la corrección.
• Complementariedad: El sistema no reemplaza las capas de verificación de seguridad, sino que las complementa: PolicyBank refina la interpretación del agente, mientras que las capas de verificación siguen aplicando restricciones duras sobre esa interpretación refinada.

En resumen, PolicyBank demuestra que los agentes de LLM pueden superar las limitaciones de las especificaciones en lenguaje natural imperfectas mediante un ciclo de retroalimentación estructurado, logrando una alineación mucho más robusta con los requisitos reales del negocio.