Prueba de un mecanismo de control que vuelve a intentar la acción final incorrecta de un agente.

La función Claude Outcomes de Anthropic reúne en un solo paquete un ciclo que muchos equipos implementan por su cuenta: un agente trabaja para redactar una respuesta, un segundo componente la evalúa según una rúbrica, y si falla, el agente tiene otra oportunidad. La idea subyacente es lo suficientemente sencilla como para probarla sin el producto gestionado, por lo que se reconstruyó una versión simplificada en un entorno controlado con salida del agente, un evaluador basado en rúbrica y exactamente una oportunidad de repetir.

La pregunta

La prueba plantea una sola cuestión: cuando un agente debe tomar una decisión estructurada, ¿un ciclo de repetición controlado por una rúbrica reduce la cantidad de acciones finales incorrectas?

Las acciones finales son cruciales aquí porque muchos fallos reales de los agentes no tienen nada que ver con la calidad del texto escrito. Una respuesta puede leerse bien, el JSON puede parsearse, pero la acción elegida aún puede ser la incorrecta. Esto se convierte en un error operativo dentro del flujo de trabajo de soporte. Por ejemplo, si un agente devuelve DENY cuando lo correcto habría sido NO_ACTION, la justificación aparentemente cautelosa no lo salva.

La configuración

El experimento constó de treinta casos sintéticos de soporte y un modelo, gpt-5.4-mini. Un ejemplo así no puede considerarse un punto de referencia válido. El valor real radica en cómo se presentaron los fallos: cuáles fueron reparados por el sistema, cuáles se pasaron por alto y dónde surge el costo de los patrones observados.

Cada caso incluye un breve escenario del cliente, una política y una lista cerrada de acciones finales permitidas:

APPROVE
DENY
ASK_CLARIFYING_QUESTION
ESCALATE
NO_ACTION

Cometieron competencia dos bucles. En la versión básica, el caso llega directamente al agente y se registra cualquier acción que regrese. En la versión con control, un juez según criterios específicos revisa la primera respuesta, y un fallo envía al agente de vuelta para intentarlo una vez más, esta vez teniendo en cuenta los criterios que no cumplió.

El diagrama a continuación es una referencia compacta para los flujos de trabajo de agentes controlados por resultados. Muestra las etapas de control que evalúan una acción propuesta contra un contrato de políticas antes de que se acepte cualquier decisión final.

El contrato se mantuvo estricto a propósito, con un conjunto cerrado de acciones, restricciones explícitas en las políticas y un único intento de repetición cuando falla la verificación según criterios específicos.

Baseline:
case -> agent -> final action

Gated:
case -> agent -> rubric judge
if failed -> retry once
retry answer -> final action

Los casos eran sintéticos, pero se basaban en restricciones comunes del estilo de producción:

Se utilizó un proveedor real de LLM y no un simulador determinista, porque lo interesante es cómo se comporta realmente un modelo una vez que su primera respuesta es evaluada y revisada.

Un juez que no posee la clave de respuestas

Un juez que ya conozca la respuesta anularía el propósito del ejercicio. Cada caso incluye un expected_action, pero ese valor solo se utiliza para métricas offline después de la ejecución, y el juez nunca lo recibe. Lo que ve el juez es la acción elegida por el agente, y verifica dicha acción contra las restricciones de la política objetiva.

Imagínese una solicitud de reembolso que cuenta con un chargeback pendiente en el flujo de trabajo de pagos. NO_ACTION podría ser la solución adecuada, ya que los departamentos de pagos son responsables de resolverla y el soporte técnico no debería tomar una decisión al respecto. Un juez poco riguroso simplemente comprobaría si el modelo eligió NO_ACTION; eso equivaldría a una verificación con clave de respuestas. Esto es adecuado para la puntuación fuera de línea, pero no constituye una barrera basada en criterios específicos.

Una verdadera barrera plantea una pregunta diferente: dado DENY, ¿el agente asignó erróneamente al soporte técnico la responsabilidad de tomar la decisión, cuando otro flujo de trabajo se encarga del caso?

En tiempo de ejecución, generalmente no se desea contar con una clave de respuestas oculta. Lo que se necesita es verificar si la acción propuesta viola un contrato claro. En este caso, el contrato era sencillo: elegir una acción final y no seleccionar ninguna que entre en conflicto con las restricciones establecidas por la política del caso.

Qué sucedió

Al procesar los 30 casos una sola vez, el agente de línea base cometió 6 errores en las acciones finales. Una vez se añadió el juez y una segunda oportunidad, solo 2 errores persistieron.

La mejora es real, pero las cifras por sí solas engañan. El bucle no le otorgó al agente ninguna habilidad nueva de carácter general; solo funcionó en aquellos casos en los que el juez podía identificar un conflicto específico entre la acción elegida y el contrato de políticas, como lo demuestran los ejemplos de fallo.

Lo que arregló la solución

El bucle corrigió 4 de los 6 fallos iniciales. La mayoría de las correcciones se dieron en casos donde el agente de línea base era demasiado rápido para denegar. La política no permitía la aprobación inmediata, pero tampoco exigía una denegación. La mejor opción era solicitar aclaraciones o esperar a otro flujo de trabajo.

Se recibió una solicitud para cambiar la dirección de correo electrónico de una cuenta. Provenía de un dispositivo nuevo, no se había completado el MFA y quien solicitaba lo sabía, además de conocer el código postal de facturación. La política exigía que se completara el MFA o se realizara alguna otra verificación de propiedad aprobada antes de que el soporte pudiera proceder. La respuesta por defecto fue DENY, aunque se esperaba ASK_CLARIFYING_QUESTION. Era prematuro rechazar la solicitud cuando aún existía una vía mediante una verificación aprobada, por lo que hacer la pregunta era el paso adecuado. El juez rechazó el rechazo por ser demasiado temprano, y al intentarlo de nuevo el modelo cambió a ASK_CLARIFYING_QUESTION.

Otro caso reparado se refería a un dispositivo de reemplazo. Un cliente pidió al soporte que enviara otro, pero ya se había creado un RMA esa mañana y estaba a la espera de un escaneo en el almacén. El valor base seleccionó DENY y la acción esperada era NO_ACTION. La denegación describió erróneamente la situación, ya que el cliente sí cumplía con los requisitos. El proceso de reemplazo ya estaba en marcha y el soporte no debería haber abierto un RMA duplicado. El intento de repetición lo corrigió a NO_ACTION.

Ambos ejemplos demuestran el valor práctico de este patrón. La regla no hizo que el modelo fuera más inteligente en general; simplemente obligó a corregir una discrepancia específica entre la acción seleccionada y el contrato de políticas.

Lo que no pudo solucionar

Los dos fallos restantes dicen más que la puntuación total. Ambos fueron casos de flujos de trabajo existentes en los que la acción esperada era NO_ACTION, y la respuesta final siguió siendo DENY incluso después del intento de repetición.

En el primero, una solicitud de reembolso tenía un chargeback pendiente en el flujo de trabajo de pagos. La política impedía que el soporte emitiera reembolsos mientras hubiera un chargeback activo, ya que los pagos eran responsables de su resolución. En el segundo, un comprador quería que se autorizara el envío de forma manual mientras estaba en curso una revisión por fraude, y la política prohibía al soporte autorizar envíos en ese estado. En ambos casos, el sistema detectó el problema y devolvió criterios de fallo, pero el intento de repetición mantuvo la acción incorrecta de todos modos.

Eso cambia la forma en que se debe evaluar el patrón para su uso en producción. Una regla de control puede detectar que una acción viola una norma, pero detectarlo no equivale a corregirlo. Supongamos que el modelo no puede distinguir entre “rechazar la solicitud” y “no intervenir porque otro flujo de trabajo lo decide”. Entonces incluso una respuesta marcada como problemática puede volver sin cambios. El hecho de que algo suene seguro no hace que una acción sea correcta, y DENY se percibe como una medida conservadora, aunque sigue siendo incorrecto cuando el agente carece de autoridad sobre el caso.

Dónde confiar en ello

El éxito aquí se basó en un resultado verificable. El agente eligió entre un conjunto cerrado, los límites de la política estaban claramente definidos y el evaluador podía comparar la acción elegida con una regla concreta. Las reintentos condicionados por el resultado generan más confianza en situaciones como estas:

Se requiere mayor precaución cuando el resultado es subjetivo:

No debería tratarse como una capa general de fiabilidad. Resérvelo para aquellos casos en los que una acción incorrecta cuesta lo suficiente como para justificar una llamada adicional al modelo y donde el resultado deseado puede quedar definido en un contrato.

Cambios en producción que vale la pena realizar

Hay un ajuste que es más importante que los demás: interpretar las solicitudes repetidas que no se resuelven como retroalimentación sobre el diseño. Cuando el agente sigue confundiendo DENY y NO_ACTION, hay que precisar más las definiciones de las acciones, añadir ejemplos o reestructurar el contrato del flujo de trabajo. Otro intento rara vez soluciona una falta de comprensión.

También mantenga separados los mecanismos de control en tiempo de ejecución de la evaluación fuera de línea. En tiempo de ejecución, el juez aplica las restricciones, mientras que la evaluación fuera de línea mide las acciones finales en relación con las expectativas definidas. Combinarlos distorsiona el sistema. También es útil registrar cada intento de repetición, incluyendo la primera acción, los criterios fallidos, la acción revisada y el veredicto final, ya que la combinación de correcciones y acciones sin corrección suele revelar más información que la precisión general.

Conclusión

Los mecanismos de control basados en resultados son efectivos cuando “terminado” puede definirse como un contrato. En este caso, el contrato era sencillo: elegir una acción final que no viole las restricciones de la política. Bajo esa condición, el bucle de control redujo las acciones finales incorrectas de 6 de 30 a 2 de 30.

Esos fallos restantes son donde debe centrarse la atención en la producción. El sistema detectó el problema y al intentarlo de nuevo se produjo aún la acción incorrecta. Por lo tanto, la pregunta pendiente no es solo si un sistema puede evaluar los resultados, sino si todo el ciclo puede transformar esa evaluación en la decisión adecuada. Esa es la evidencia que se debe solicitar antes de que cualquier ciclo controlado por resultados afecte un flujo de trabajo en tiempo real.

Leer más

La documentación de la API de Anthropic sobre cómo definir resultados y su entrada en el manual sobre agentes que verifican su propio trabajo abordan la funcionalidad gestionada que refleja este experimento.