Reconsiderar antes de escribir: de 60.7% a 73.8% de éxito en los casos con conflicto

Los agentes de ventas por WhatsApp ya no solo conversan. Crean pedidos, aplican promociones, cambian direcciones, cancelan, generan links de pago. Cada una de esas acciones es una escritura en un sistema real, y muchas no se deshacen con un "perdón, me equivoqué". La pregunta de ingeniería ya no es solo si el modelo entiende al cliente, sino cuándo debe detenerse a revisar antes de actuar.

Qué propone el artículo

Qian Chen, Chengyuan Liu y Xin Yu, de Penn State, publicaron en arXiv el artículo When Should Service Agents Reconsider?. Su punto de partida: las empresas necesitan que el servicio rutinario sea rápido y sin fricción, pero también evitar errores en las peticiones donde se cruzan instrucciones del cliente, políticas, registros y escrituras en el backend. La arquitectura tiene tres piezas:

• Un router por sesión. Es un prompt con el mismo modelo, sin herramientas y en una configuración barata, que devuelve una sola etiqueta: SIMPLE o COMPLEX. El criterio no es la longitud de la conversación, sino el acoplamiento operativo: varias acciones, varias entidades, peticiones condicionales o de respaldo, restricciones que chocan, o escrituras que deben ir en orden.
• Un latch. Cuando una sesión se marca como compleja, el router deja de consultarse y el resto de la conversación corre en el flujo con más control. Es una decisión de un solo sentido.
• Reconsideración disparada por escritura. Antes de cualquier escritura en el backend, un verificador —el mismo modelo con más razonamiento— revisa el nombre de la herramienta y sus argumentos. Puede mantener la acción, corregirla, preguntarle al cliente o bloquearla. El verificador solo actúa en la frontera de la acción, no en cada turno del diálogo.

Los resultados, con sus matices

La evaluación usa los dominios verificados por humanos de τ²-bench: 114 tareas de retail y 50 de aerolínea. Cada tarea corre cuatro veces y se aprueba si al menos tres corridas tienen éxito. Además, los autores construyen un «focus set» con las tareas donde el baseline mostró conflicto operativo, antes de evaluar el método:

• Retail, casos con conflicto (61 tareas): mejora en las tres configuraciones probadas. En la principal, de 37/61 (60.7%) a 45/61 (73.8%).
• Aerolínea, casos con conflicto (20 tareas): de 9/20 (45.0%) a 13/20 (65.0%) en la configuración principal, y de 11/20 (55.0%) a 13/20 (65.0%) en la otra.
• Retail, conjunto completo (114 tareas): mixto. Dos configuraciones mejoran (58.8% a 64.9% y 78.1% a 81.6%), pero una baja de 84.2% a 78.1%.
• El router es selectivo. En la configuración principal de retail, 21 tareas entraron al camino escalado y todas pertenecían al focus set: no estaba escalando simplemente las conversaciones largas.
• El conflicto suele aparecer tarde. Según los autores, en retail la mayoría de las escaladas fueron de conflicto emergente: la petición parecía rutinaria y el problema apareció al consultar registros, políticas o disponibilidad, o cuando el cliente cambió de opinión antes de una escritura.
• El control tiene costo. En los casos de retail con ganancia estable, las llamadas a herramientas subieron de 4.63 a 9.50 y la duración de 36.3 a 74.1 segundos.

Los propios autores marcan los límites: es un benchmark con metas, políticas y estados finales definidos, no un servicio en vivo; no hay un modelo de costos completo que pese latencia, fricción y el costo de una escritura errónea; y tanto el router como el verificador son prompts, no comparados contra routers entrenados ni verificadores de políticas formales. Es un preprint, no un resultado de producción.

Cómo lo aplicamos en los agentes de SmartLeads

Coincidimos con la tesis central del artículo: la confiabilidad de un agente con acciones reales es un problema de asignación, no solo de modelo. Así lo traducimos a un agente que vende por WhatsApp:

• Inventario de escrituras. El primer paso no es el prompt: es listar qué herramientas cambian estado (crear pedido, aplicar promoción, cancelar, generar cobro) y separarlas de las de solo lectura (menú, cobertura, estado de un pedido). Solo las primeras pasan por la compuerta.
• Las reglas duras van en código. Precio, cobertura, horario y mínimos de compra se validan con código determinista antes de la escritura. El verificador con LLM complementa esa validación; no la reemplaza. Un modelo no debería ser lo único entre el cliente y un cobro mal calculado.
• Señales de conflicto explícitas. Pedidos con varias direcciones, "si no hay X, mándame Y", cambios después de una cotización o combos armados a mano son nuestros equivalentes del acoplamiento operativo. Ahí sí vale la pena pagar más razonamiento.
• Latch, igual que en el artículo. Si el cliente ya cambió el pedido dos veces, la conversación no vuelve al camino rápido. Ese es justo el caso de conflicto emergente que el artículo documenta.
• Medir por clase de conversación. Un promedio global esconde el resultado más importante del artículo: el método gana donde hay conflicto y puede perder en el resto. Medimos errores de escritura, latencia y conversión por separado para conversaciones rutinarias y complejas.

La conclusión

Hacer que un agente "piense más" en todas las conversaciones duplica tiempo y llamadas sin garantizar menos errores. Lo que muestra este trabajo es más útil: identificar las sesiones con conflicto, aislarlas y poner la revisión justo antes de la acción que no se puede deshacer. Si tu agente crea pedidos o cobra, la pregunta de diseño es concreta: ¿qué escrituras tiene, cuáles son irreversibles y qué las revisa antes de ejecutarse?