ALTK-Evolve: Cómo la memoria aprendida lidera la tabla de τ²-bench en tareas de servicio al cliente sin un modelo de frontera

ALTK-Evolve aprende y aplica un playbook usando GPT-4.1, superando las entradas de retail en τ²-bench, un benchmark de agentes de servicio al cliente, sin actualizar los pesos del modelo.

La memoria aprendida lleva un agente ReAct básico con GPT-4.1 a la cima

Usando GPT-4.1, un modelo más antiguo y sin razonamiento, un agente básico de servicio al cliente alcanza 67.5% Pass^4 en τ²-bench retail , lo que significa que resuelve la tarea en los cuatro intentos independientes para el 67.5% de las tareas. Obtiene una puntuación superior a todas las entradas de retail en nuestra instantánea de la tabla del 12 de octubre de 2026. Se ejecuta en el scaffold ReAct estándar del benchmark, con pautas aprendidas añadidas a su system prompt.

ALTK-Evolve construye ese playbook usando GPT-4.1. Analiza los intentos del agente en las tareas de entrenamiento y usa el modelo para destilar éxitos y fracasos en reglas de comportamiento breves: cómo autenticar a un cliente, confirmar una transacción o gestionar una devolución. Esas pautas se añaden luego al prompt del agente para conversaciones posteriores. El mismo modelo impulsa tanto la extracción de pautas como el agente; no se necesitan actualizaciones de pesos ni anotación humana.

Nuestro trabajo anterior demostró este enfoque en agentes de programación. Aquí lo probamos en servicio al cliente, donde el éxito requiere seguir políticas del dominio, entender la solicitud de un cliente y ejecutar las acciones correctas con las herramientas.

τ²-bench pone a prueba el servicio al cliente sujeto a políticas

τ²-bench (de Sierra) mide qué tan bien maneja un agente conversaciones de servicio al cliente bajo restricciones reales. Cada tarea empareja al agente con un cliente simulado por un LLM que tiene un objetivo en mente, un conjunto de herramientas del dominio (consultar un pedido, emitir un reembolso, reprogramar un vuelo) y un documento de políticas escrito que el agente debe seguir. El agente tiene que extraer los detalles correctos, mantenerse dentro de la política y tomar las acciones correctas —a menudo irreversibles—; una tarea solo cuenta como resuelta cuando el estado final de la base de datos coincide con el resultado esperado, una recompensa binaria estricta. Usamos sus dos dominios de servicio al cliente, retail y airline.

Ejecutamos la propia implementación de τ²-bench de un agente ReAct básico con un bucle de dos fases THINK → ACT , usando gpt-4.1 como el modelo del agente y gpt-5.5 como el modelo simulador de cliente; 4 intentos por tarea. El único cambio que hacemos es un bloque de directrices aprendidas añadido al system prompt — todo lo demás (policy, tools, scaffold) es el τ²-bench estándar. Concretamente, las directrices aprendidas se añaden después de la política del dominio como una simple lista en markdown:

You are a customer service agent that helps users according to the policy below.
Always follow the policy strictly. Use the provided tools when needed.

<policy>
# Retail agent policy

As a retail agent, you can help users:
- cancel or modify pending orders
- return or exchange delivered orders
- modify their default user address
…
</policy>

## Guidelines learned from past task attempts (follow these carefully):
- Authenticate the user before taking any order-related action. If email is unavailable, verify identity via full name and zip code using the find_user_id_by_name_zip API.
- Always confirm all intended changes (modify, cancel, return, exchange) with a clear, structured summary, and require explicit user approval before executing any database-updating action.
- When processing a return or exchange, communicate the refund with an itemized breakdown and clarify refund timing — don't wait for the user to ask.
- Take one action per step: never combine a tool call with a user-facing message in the same turn, and wait for the tool's result before replying.
- Before looking a user up, parse and clean their name — e.g. split a combined handle like `daiki_johnson_9523` into first/last name — and after a couple of failed lookups, state the exact format you need.
…

Extraemos las directrices de las trayectorias del agente en τ²-bench train tasks usando gpt-4.1, el mismo modelo que impulsa al agente, y luego las aplicamos sin cambios en el conjunto test de reserva (held-out).

Las directrices mejoran la capacidad y la fiabilidad

En una publicación anterior, hablamos de cómo diferentes modelos / tareas requieren diferentes dosis de orientación. En línea con esa idea, también evaluamos diferentes cantidades de directrices proporcionadas al modelo.

Cada directriz lleva un contador de support — el número de tareas de entrenamiento distintas de las que se extrajo, de modo que un support más alto significa una regla que se generalizó en más tareas en lugar de algo puntual. Comparamos tres configuraciones: baseline (sin directrices), sup3 (mantener solo las directrices con support ≥ 3 — un núcleo pequeño de alta confianza) y lossless (mantener todas las directrices retenidas tras la consolidación, es decir, support ≥ 1).

Tabla 1. Configuraciones de directrices y número de directrices retenidas por dominio.

Las métricas que rastreamos. Cada tarea se intenta 4 veces, y leemos esos intentos de dos maneras:

• Precisión Media — la tasa de éxito promedio en los 4 intentos. Este es el eje de capacidad : ¿con qué frecuencia acierta el agente?
• Pass^4 — el porcentaje de tareas que pasaron en los 4 intentos. Esto mide a lo largo del eje de fiabilidad y es la métrica que reporta la tabla de clasificación de τ²-bench. Importa aquí porque un agente de soporte que resuelve un reembolso 3 veces de 4 sigue fallando ante un cuarto de los clientes reales — Pass^4 pregunta si puedes confiar en el agente cada vez, no solo en promedio.

Figura 1. Precisión Media y Pass^4 en tareas reservadas de retail y aerolíneas para agentes que usan gpt-4.1 en cuatro intentos por tarea.

Modelo del agente: gpt-4.1 (simulador de usuario: gpt-5.5).

Tabla 2. Rendimiento de agentes en datos no vistos usando gpt-4.1 a lo largo de cuatro pruebas por tarea. Los paréntesis muestran los cambios en puntos porcentuales respecto a la línea base.

La precisión media aumenta en ambos dominios: retail +4.4 pts (78.1 → 82.5) y airline +7.5 pts (57.5 → 65.0). La fiabilidad mejora aún más: la estricta Pass^4 sube +10 pts en retail (57.5 → 67.5) y +10 pts en airline (35.0 → 45.0). Y las mejoras provienen de decisiones mejor informadas, no de conversaciones más largas — analizamos directamente la longitud de la conversación en Mejor rendimiento cuesta más tokens, no más turnos más abajo.

La mejor cantidad de orientación depende del dominio

Los dos dominios difieren sobre cuánta orientación rinde beneficios. En retail, más es mejor en todas las métricas — el núcleo pequeño sup3 apenas supera la línea base en precisión, y necesitas el conjunto lossless completo para el verdadero salto. En airline el panorama se invierte en el extremo de la fiabilidad: lossless lidera en precisión (65% vs 60%), pero el núcleo compacto sup3 (14 directrices) es el más fiable , llevando Pass^4 a 45% frente al 40% de lossless. En eco del hallazgo anterior de que la entrega es un dial, no una constante, , el número de soporte es una perilla que vale la pena ajustar por dominio, no un valor que deba codificarse de forma fija.

Mejor rendimiento cuesta más tokens, no más turnos

Las directrices no son gratis, pero el costo cae donde esperarías — en los tokens de entrada del prompt, no en una conversación más larga y divagante:

Figura 2. Costo total del LLM por conversación por dominio y configuración de directrices en la división base completa.

Tabla 3. Costo total del LLM por conversación (agente y simulador de usuario) en la división base completa a lo largo de cuatro ensayos. Menor es mejor.

¿Llega el agente ahí hablando más tiempo? Para responder a eso con claridad comparamos en igualdad de condiciones: las tareas resueltas tanto en la línea base como en la variante con directrices — escenario y semilla idénticos, un conjunto verdaderamente de "misma tarea, bien hecha" — y contamos los turnos del asistente en cada lado.

Tabla 4. Turnos del asistente por conversación para ejecuciones emparejadas resueltas bajo ambas configuraciones en la partición de prueba, agrupando cuatro intentos.

El agente no está hablando más tiempo — en el conjunto compartido, las directrices hacen las conversaciones ligeramente más cortas: lossless recorta ~0.3–0.4 turnos en ambos dominios (retail 10.59 → 10.16, aerolínea 9.15 → 8.82), y ninguna variante los alarga. Eso importa más allá del costo: cada turno es un recorrido secuencial de ida y vuelta del LLM, así que menos turnos significa menor latencia de extremo a extremo — un tiempo hasta la finalización más rápido para el cliente, no solo uno más barato. El único precio real está del lado de la entrada — el system prompt más grande que viaja en cada llamada al LLM: el prompt de 292 directrices de retail empuja el costo de ~$0.084 a ~$0.139 por conversación, mientras que el playbook más pequeño de la aerolínea es más barato. Y en producción, incluso eso es en gran medida recuperable con prompt caching, ya que el bloque de directrices es idéntico en cada llamada.

Así que el intercambio es favorable: por un costo de entrada ligeramente mayor (gran parte del cual en la práctica queda eliminado por la caché) el agente llega mayor precisión, mayor fiabilidad, y menor tiempo hasta la finalización a la vez — no el habitual intercambio de calidad por latencia, sino las tres cosas mejorando juntas en la dirección correcta.

Las directrices aprendidas también mejoran a los agentes que usan modelos de frontera

Hasta ahora, hemos usado un modelo más antiguo, sin razonamiento — gpt-4.1. Una objeción razonable es que las directrices aprendidas podrían aportar menos a un agente que use un modelo de frontera : tal vez solo tapan las carencias de un modelo más débil. Así que lo probamos directamente — volvimos a ejecutar airline usando gpt-5.5 tanto para el agente como para la extracción de directrices, sobre el mismo scaffold ReAct de τ²-bench, con directrices extraídas de nuevo de las ejecuciones del propio agente. Un detalle cambia con el modelo: ninguna de las directrices extraídas en esta configuración alcanzó un soporte ≥ 3 (llegan como máximo a soporte 2), de modo que el núcleo de alto soporte aquí es sup2 en lugar de sup3.

Tabla 5. Rendimiento de airline retenido para el gpt-5.5 agente en cuatro ensayos por tarea.

Las directrices aprendidas también mejoran esta configuración. En las mismas tareas de prueba retenidas, añadirlas al prompt eleva la precisión +10 pts (72.5 → 82.5) y la estricta Pass^4 en +15 pts (55.0 → 70.0) — una mayor ganancia de fiabilidad de la que observamos con gpt-4.1 en estas mismas tareas (+10 pts), y desde una base mucho más alta. Aprender directrices alrededor de el modelo puede mejorar a un agente incluso cuando parte de una base más fuerte. Y donde la fiabilidad del modelo base variaba entre ejecuciones repetidas, la configuración sin pérdida reprodujo exactamente — la ganancia que aporta es fiable, no un golpe de suerte.

ALTK-Evolve encabeza la comparación de clasificación

Las entregas se puntúan en la división base completa (train ∪ test), como requiere τ²-bench, y se reportan en Pass^4. Como eso cubre el conjunto completo de tareas en lugar de la división de prueba reservada, estas cifras difieren de los números de tareas de prueba reportados anteriormente. Aquí es donde se muestra la consecuencia práctica — la memoria a nivel de prompt lleva a los agentes que usan cada modelo base hacia, o más allá de, las empresas fronterizas actuales:

• Retail: #1. En la división base, el agente con directrices aprendidas alcanza Pass^4 = 67.5%, por delante de todos los modelos fronterizos y por delante de RAFT-30B-A3B (61.4%), un modelo ajustado con datos sintéticos de τ²-bench retail. Usando gpt-4.1 intacto y un manual adjunto al prompt, supera a ese sistema ajustado por +6.1 puntos.
• Airline: #1 usando gpt-5.5, #8 usando gpt-4.1 Frente al tablero publicado, el núcleo compacto sup3 core da al agente que usa gpt-4.1 Pass^4 = 44% — 8.º, superando a GPT-5.2 (sin razonamiento) y casi igualando a Claude Sonnet 4.5. Si se cambia a la base más potente, el mismo enfoque lidera el campo de forma absoluta: el agente que usa gpt-5.5 alcanza 82.0%, superando a todos los modelos frontera (66–72%).

Figura 3. Comparación de Pass^4 entre ejecuciones de ALTK-Evolve y la instantánea de la tabla de clasificación de τ²-bench del 12 de octubre de 2026.

El mismo mensaje en ambos dominios: directrices de aprendizaje en torno a el modelo funciona con diferentes modelos base — llevando a un agente con un modelo anterior, sin razonamiento, a la compañía frontera en retail, y llevando a un agente con un modelo frontera a la cima en airline.

Los agentes pueden mejorar sin actualizaciones de pesos

Afinar un modelo en un benchmark es costoso, frágil y no se transfiere al siguiente dominio. Aquí, ALTK-Evolve mejora un agente de acciones sobre un modelo de acciones en ambos dominios — e iguala o supera a un sistema afinado en retail — usando solo directrices a nivel de prompt extraídas de las propias ejecuciones del agente, automáticamente, sin anotación humana y sin ninguna fuga del conjunto de prueba.

Enlaces:

• Publicaciones anteriores
  1. ¿Pensando en ACE? Podemos hacerlo con menos tokens
  2. ¿Cuánta memoria necesita realmente tu agente?
  3. Tu agente completó la tarea con éxito. ¿Lo hará de nuevo?
• Biblioteca ALTK-Evolve — https://github.com/AgentToolkit/altk-evolve
• τ²-bench — https://github.com/sierra-research/tau2-bench
• Envío al leaderboard de retail — τ²-bench PR #542
• Envío al leaderboard de aerolíneas - τ²-bench PR #551