Resumen Técnico: LedgerAgent: Estado Estructurado para Agentes de Llamada a Herramientas con Adherencia a Políticas

Declaración del Problema

En los dominios de atención al cliente, los agentes de lenguaje deben mantener estados de tarea a través de múltiples turnos mientras interactúan con usuarios, recuperan registros y ejecutan herramientas. Estos agentes deben adherirse a políticas de dominio estrictas (por ejemplo, elegibilidad de reembolsos, ventanas de cancelación) que dependen del estado actual de la interacción.

Los agentes de llamada a herramientas estándar dependen de un diseño basado únicamente en el prompt, donde las observaciones, los retornos de las herramientas y las instrucciones de política se entrelazan en una transcripción de conversación creciente. Este diseño crea dos modos principales de falla:

1. Anclaje de Estado Implícito: Los agentes deben reconstruir hechos relevantes a partir de la transcripción bruta cada vez que deciden una acción. Esto conduce a decisiones basadas en información obsoleta, faltante o incorrectamente reconstruida, incluso si los registros correctos fueron recuperados previamente.
2. Violaciones de los Límites de la Política: Los agentes pueden generar llamadas a herramientas sintácticamente válidas que violan las políticas de dominio porque la verificación de la política no está desacoplada del estado actual. Por ejemplo, un agente podría intentar cancelar una reservación fuera de la ventana permitida porque no logró cruzar la fecha actual con la fecha de la reservación almacenada en el historial.

Las soluciones existentes suelen enfocarse en mejorar el modelo en sí (mediante ajuste fino o aprendizaje por refuerzo) o añadir andamiaje en el tiempo de inferencia (planificación/reflexión). Sin embargo, estos enfoques preservan mayoritariamente la naturaleza implícita de la representación del estado dentro del prompt, dejando al agente con la tarea de recuperar el estado de una transcripción no estructurada.

Metodología: LedgerAgent

Los autores introducen LedgerAgent, un método de tiempo de inferencia que desacopla la gestión del estado del historial bruto del prompt. Introduce dos componentes deterministas que operan sin modificar los pesos del modelo ni requerir llamadas adicionales al LLM para la construcción del estado:

1. Libro Mayor Anclado a Esquemas (Schema-Anchored Ledger)

El agente mantiene un diccionario tipado separado (el libro mayor o ledger) que almacena los estados de la tarea observados.

• Mecanismo: Cuando un retorno de herramienta de lectura tiene éxito, el valor de retorno se analiza y se proyecta en el libro mayor basándose en un mapa de rutas de herramientas predefinido y específico del dominio (por ejemplo, orders.1234, reservations.UX789).
• Propiedades: El libro mayor es una representación compacta y tipada de los hechos observados, identificadores y condiciones. No es un resumen ni memoria a largo plazo, sino una vista estructurada del estado del sistema externo observado por el agente.
• Regla de Actualización: El libro mayor se actualiza únicamente a partir de los retornos exitosos de las herramientas de lectura. Los retornos de herramientas de escritura no actualizan el libro mayor; el agente debe emitir una llamada de lectura subsecuente para observar el nuevo estado, asegurando que el libro mayor permanezca anclado en el sistema externo.
• Integración: Antes de cada generación del modelo, el libro mayor completo se renderiza de forma determinista y se inyecta en el prompt. Esto permite al modelo buscar el estado actual mediante rutas estables en lugar de buscar en el historial de la transcripción.

2. Puerta de Política (Policy Gate)

Una puerta de política opera inmediatamente antes de que se ejecute cualquier llamada a una herramienta que cambie el entorno (por ejemplo, reembolsos, cancelaciones, actualizaciones).

• Función: La puerta evalúa la llamada a la herramienta propuesta contra un conjunto de predicados ejecutables ($\Pi$) definidos sobre los campos del libro mayor actual.
• Resultados:
  • ALLOW (Permitir): La llamada es consistente con el libro mayor y la política; procede sin cambios.
  • REVISE (Revisar): La llamada viola una política (por ejemplo, falta de evidencia). La llamada es eliminada y el modelo recibe retroalimentación identificando el predicado violado.
  • BLOCK (Bloquear): La llamada está explícitamente prohibida (por ejemplo, intentar una acción que viola la política). La acción es rechazada y se evita que el agente cambie el entorno.
• Implementación: Las políticas se codifican como predicados de código sobre los campos del libro mayor (por ejemplo, verificar si la fecha de un vuelo está dentro de las 24 horas respecto al tiempo actual), en lugar de depender del razonamiento en lenguaje natural dentro del prompt.

Bucle del Agente

El método envuelve el bucle estándar del agente. Absorbe los retornos de las herramientas en el libro mayor, renderiza el libro mayor en el prompt, genera una respuesta y filtra las llamadas que cambian el entorno a través de la puerta de política. Crucialmente, esto añade cero llamadas adicionales al LLM al proceso de inferencia; la sobrecarga se limita a la formación de cadenas de texto determinista y la evaluación de predicados.

Contribuciones Clave

1. Identificación del Anclaje de Estado como un Modo de Falla: El artículo identifica que los agentes a menudo fallan no porque no puedan recuperar registros, sino porque actúan sobre un estado obsoleto o incorrectamente reconstruido cuando ese estado permanece implícito en el prompt.
2. Marco de Trabajo LedgerAgent: Un método de tiempo de inferencia novedoso que separa la representación del estado (mediante un libro mayor tipado) de la ejecución de acciones (mediante una puerta de política), asegurando que las políticas dependientes del estado se verifiquen contra la evidencia observada antes de que ocurran cambios en el entorno.
3. Validación Empírica: Demostración de que LedgerAgent mejora las métricas orientadas a la consistencia ($pass^k$) a través de diversos dominios de atención al cliente y modelos de base sin alterar los pesos del modelo.

Resultados Experimentales

Los autores evaluaron LedgerAgent a través de cuatro dominios (Aerolíneas, Retail, Telecomunicaciones, Telemedicina) utilizando una mezcla de modelos de pesos abiertos y cerrados (incluyendo GPT-4.1, GPT-5.2, Kimi K2.5, GLM-5, MiniMax M2.5 y Qwen3).

• Ganancias de Rendimiento: LedgerAgent mejoró consistentemente los puntajes promedio de $pass^1$ y $pass^4$ sobre las líneas base estándar de llamada a funciones.
  • En modelos de base no-GPT (por ejemplo, Kimi-K2.5), el $pass^1$ promedio mejoró 3.4 puntos y el $pass^4$ 5.6 puntos.
  • En modelos de base GPT, las mejoras fueron aún más pronunciadas, con ganancias promedio de $pass^1$ de 12.2 (GPT-4.1) y 15.5 (GPT-5.2) puntos.
• Consistencia: Las mayores ganancias se observaron en $pass^4$ (consistencia a través de cuatro ensayos independientes), lo que indica que LedgerAgent reduce significativamente la varianza en el comportamiento del agente.
• Tareas de Cambio de Entorno: El método mostró una fortaleza particular en tareas que requieren acciones de escritura (por ejemplo, cancelaciones, reembolsos), donde prevenir las violaciones de política es crítico. En el dominio de Telecomunicaciones (entorno de control dual), LedgerAgent aumentó sustancialmente la confiabilidad a nivel de acción.
• Eficiencia: A diferencia de los métodos de ingeniería de contexto como IRMA (que utilizan agentes auxiliares e incurren en una sobrecarga de tokens >50%), LedgerAgent logró un mayor rendimiento con 0.0% de sobrecarga de tokens en relación con la línea base, ya que no añade llamadas adicionales al LLM.

Análisis de Errores

El análisis de las trayectorias fallidas reveló que los errores restantes en LedgerAgent son principalmente:

• Acciones Requeridas Omitidas (70.3%): El agente completa las búsquedas iniciales pero falla al ejecutar los pasos necesarios subsiguientes (por ejemplo, transferir a soporte humano prematuramente en lugar de intentar un cumplimiento parcial válido).
• Argumentos de Acción Incorrectos (20.4%): Errores en la extracción o el formato de argumentos, particularmente en dominios con esquemas complejos como Telemedicina.
• Especificidad del Dominio: Los fallos varían según el dominio (por ejemplo, los fallos de Telecomunicaciones son casi exclusivamente acciones omitidas; Telemedicina tiene mayores tasas de error de argumentos), lo que sugiere que, si bien el libro mayor resuelve el anclaje del estado, la planificación específica del dominio y la conciencia del esquema siguen siendo desafíos.

Significado y Reivindicaciones

El artículo sostiene que LedgerAgent aborda una brecha arquitectónica fundamental en los agentes de llamada a herramientas: la dependencia de un estado implícito dentro de un prompt creciente. Al hacer explícito el estado observado y verificar las acciones contra un libro mayor estructurado antes de la ejecución, el método:

• Desplaza el límite de falla de la corrección post-hoc (corregir errores después de que ocurren) a la prevención (bloquear violaciones de política antes de que ocurran).
• Proporciona un mecanismo a nivel de sistema para la adherencia a las políticas que complementa las capacidades de razonamiento del modelo sin requerir reentrenamiento o una orquestación compleja de multi-agentes.
• Demuestra que la representación del estado es tan crítica como la capacidad del modelo para un uso de herramientas confiable en entornos dinámicos y con restricciones de política.

Los autores concluyen que, si bien LedgerAgent no reemplaza la necesidad de planificación o de una construcción robusta de argumentos, elimina eficazmente una fuente importante de falta de fiabilidad: actuar sobre un estado obsoleto o sin fundamento. El enfoque es más efectivo en dominios de uso de herramientas estructurados donde el estado puede mapearse a un esquema y las políticas pueden codificarse como predicados ejecutables.