¿Terminó de verdad el agente? Cómo verificar el resultado sin fiarse de su respuesta final

La acción no es el resultado

Un agente puede responder «listo» sin que el objetivo se haya cumplido. También puede emitir una llamada a una herramienta, recibir una respuesta que indique que la solicitud fue aceptada y, aun así, dejar el trabajo pendiente o incompleto. Son afirmaciones diferentes y requieren evidencias diferentes.

Conviene separar tres estados. Primero, el agente intentó una acción: por ejemplo, envió una instrucción para cambiar un registro. Segundo, el sistema que recibió la solicitud la aceptó o respondió a ella. Tercero, el estado final que pidió la persona existe y satisface las condiciones acordadas. Solo el tercer estado demuestra, por sí mismo, que el objetivo se alcanzó.

Esta distinción es importante porque una respuesta de éxito puede referirse únicamente a una parte del proceso. «Solicitud recibida» no necesariamente significa «cambio guardado»; «prueba ejecutada» no significa que todos los requisitos del cambio estén satisfechos; y «reserva solicitada» no equivale a una reserva confirmada. La respuesta del agente puede resumir lo ocurrido, pero no debería convertirse en la única prueba de lo que ocurrió.

La evaluación de agentes se ocupa de comprobar si sistemas que realizan acciones pueden completar un trabajo de forma fiable. En este artículo, el foco es más acotado: decidir qué evidencia permite aceptar una tarea concreta como terminada. Las recomendaciones y ejemplos que siguen son un método práctico, no una afirmación de que exista una señal universal válida para todos los agentes o herramientas.

Paso 1: convertir la solicitud en un estado final observable

Antes de ejecutar una tarea, reformula la solicitud como una descripción de cómo debe quedar el mundo al terminar. «Actualiza el registro» es ambiguo: no indica qué campo cambia, cuál es el valor esperado ni si hay otros datos que deban permanecer intactos. «Haz el cambio de código» tampoco precisa qué comportamiento se espera ni qué condiciones deben seguir cumpliéndose.

Una formulación útil identifica el objeto afectado, el estado deseado, las condiciones que deben conservarse y cualquier límite relevante. No hace falta convertir cada petición en una especificación extensa. Sí hace falta resolver las ambigüedades que cambiarían la decisión de declarar la tarea completa.

El resultado observable debe poder expresarse sin depender de la intención del agente. En vez de «el agente gestionó la reserva», especifica qué tendría que existir para afirmar que está confirmada. En vez de «el agente arregló el código», define qué comportamiento esperado debe funcionar y qué comprobaciones son pertinentes para el cambio.

También delimita lo que queda fuera. Si se pidió actualizar un campo, no asumas que el agente debía modificar otros campos, avisar a terceros o revisar todo el historial. Esta frontera ayuda a evitar dos errores opuestos: aceptar una tarea parcial como completa y ampliar el encargo sin autorización.

Paso 2: acordar criterios de aceptación antes de actuar

Los criterios de aceptación concretan qué tendría que observarse para considerar cumplida la solicitud. Es mejor definirlos antes de ejecutar la acción: después resulta más fácil confundir una salida conveniente con una prueba adecuada o rebajar el estándar para justificar un resultado parcial.

Un criterio útil es específico y comprobable. «El registro está bien» deja demasiado margen de interpretación. «El campo de estado muestra el valor acordado para el registro identificado» señala un estado y un objeto. Si también importa que se conserven otros campos, debe expresarse como un criterio adicional.

No todo requisito se puede comprobar con una sola señal. Un cambio puede requerir que el valor exista y que otro atributo no se haya alterado. Una reserva puede requerir tanto una confirmación como los detalles correctos. Una prueba de código puede cubrir un comportamiento importante sin demostrar por sí sola que cada requisito del encargo está implementado. La lista debe reflejar las condiciones reales de la petición, no solo las más fáciles de medir.

Para solicitudes abiertas, primero puede hacer falta pedir una aclaración. Si hay varias interpretaciones razonables y la diferencia afecta al resultado aceptable, el agente no debería escoger silenciosamente una y tratarla después como si fuera la única. El criterio acordado también determina cuándo una tarea está completa solo en parte y qué información hay que comunicar.

Paso 3: elegir evidencia que corresponda a la afirmación

La evidencia debe responder a la pregunta concreta: ¿qué permite afirmar que el estado final deseado existe? Una salida de herramienta puede ser adecuada para saber que una petición llegó a cierto componente, pero no necesariamente para demostrar que el resultado quedó persistido o que satisface todos los requisitos. No atribuyas a una señal más significado del que realmente tiene.

Cuando sea posible, comprueba el estado mediante una lectura pertinente del sistema afectado o mediante una comprobación que evalúe directamente el resultado. Para algunos trabajos, la evidencia puede ser una prueba automatizada; para otros, una confirmación visible en la fuente que administra el estado. «Independiente» no significa siempre «de otro proveedor»: significa que no se toma como única prueba la afirmación del mismo agente que dice haber completado la tarea.

La independencia también tiene grados. Volver a preguntar al agente si terminó puede repetir su afirmación, no verificarla. Consultar una vista del registro puede aportar observación del estado, pero habría que saber qué representa esa vista y si corresponde al objeto correcto. Una fuente separada puede ofrecer más contraste, siempre que mida realmente el resultado pedido.

La evidencia ha de estar vinculada al criterio y al objeto adecuados. Una prueba de código satisfactoria no acredita automáticamente requisitos que no cubre. Una respuesta de confirmación de reserva solo resulta útil si se refiere a la reserva solicitada y sus datos coinciden con lo acordado. Si no puedes establecer ese vínculo, expresa la incertidumbre en lugar de completar los huecos con suposiciones.

Paso 4: separar ejecución y verificación

El componente que realiza una acción y el que comprueba su resultado cumplen funciones diferentes. En un flujo sencillo, un mismo agente puede invocar una herramienta y después consultar el sistema afectado. Aun así, la segunda operación debe aportar una observación del estado, no limitarse a repetir que la primera tuvo éxito.

En sistemas con mayor impacto, puede ser preferible que la verificación siga una ruta distinta de la ejecución, o que la revise una persona. La separación reduce el riesgo de que una sola respuesta se trate como acción y como prueba a la vez. No es una regla absoluta: el nivel de separación apropiado depende del riesgo, de la ambigüedad de la tarea y de la calidad de las señales disponibles.

La automatización puede bastar cuando los criterios son claros, la comprobación cubre el resultado relevante y los posibles errores tienen consecuencias acotadas. La revisión humana cobra más importancia cuando las instrucciones admiten varias interpretaciones, hay consecuencias significativas, la evidencia no es concluyente o hace falta juicio contextual que una prueba automática no representa.

Pedir revisión humana no convierte automáticamente una conclusión en correcta. La persona necesita ver qué se solicitó, qué criterios se acordaron y qué evidencia se observó. Una aprobación sin esos elementos puede convertirse en otro «sí» sin respaldo. La revisión debe resolver una duda concreta, no ser una formalidad desconectada del resultado.

Tres ejemplos trabajados

Los ejemplos siguientes ilustran el método con criterios hipotéticos. No describen una herramienta o producto concreto, y las señales disponibles cambian según el sistema. En cada caso, la clave es no elevar una respuesta de aceptación a prueba de finalización sin comprobar qué significa esa respuesta.

En una actualización de registro, la petición puede ser cambiar un campo concreto. La acción emitida demuestra un intento; una respuesta de aceptación puede indicar que el sistema recibió la petición. Para declarar el trabajo completo, hace falta observar el registro correcto y comprobar el valor acordado. Si también se pidió conservar otros datos, deben incluirse en la verificación. Si el sistema solo muestra que el cambio está pendiente, el resultado todavía no satisface un criterio que exige que el valor ya figure en el registro.

En un cambio de código, la tarea no queda definida por el hecho de que se haya producido un parche o una respuesta de éxito. Antes de ejecutarla, aclara qué comportamiento se espera y qué condiciones son parte del encargo. Después, usa comprobaciones relevantes para ese comportamiento y revisa los criterios que las pruebas no cubren. Que una prueba termine sin errores aporta evidencia sobre lo que esa prueba ejecutó; no demuestra automáticamente todos los requisitos funcionales o de calidad de una solicitud.

En una reserva, distinguir entre solicitar y confirmar resulta decisivo. El agente puede enviar una petición y recibir una respuesta que no aclare si la reserva quedó confirmada. La evidencia debe permitir identificar la reserva pertinente y contrastar los detalles que se acordaron. Si solo hay una solicitud pendiente o no se pueden confirmar los datos necesarios, el mensaje final debe indicarlo, no presentar la reserva como hecha.

Resultados parciales, contradictorios o no verificables

Si solo se cumple una parte de los criterios, describe esa parte como parcial. No conviertas «la acción se aceptó» en «la tarea está terminada» para ofrecer un cierre más convincente. También evita el extremo contrario: si hay evidencia válida de algunos requisitos, indícalos en vez de presentar todo el trabajo como desconocido.

Si dos señales se contradicen, detén la conclusión hasta aclarar qué mide cada una y a qué estado corresponde. Una respuesta positiva puede referirse a la recepción de la solicitud mientras otra observación muestra que el estado final todavía no cambió. Esa diferencia no es necesariamente una contradicción real: puede ser una diferencia de etapa. Pero, mientras no se resuelva, no respalda una afirmación de éxito completa.

Si no hay una forma adecuada de observar el resultado, la conclusión correcta es que no se pudo verificar, no que el agente fracasó necesariamente ni que tuvo éxito. Comunica la acción que se intentó, la respuesta observada y el criterio pendiente. La falta de evidencia sobre el estado final no demuestra por sí sola cuál es ese estado.

Mantén la descripción del resultado proporcionada a la evidencia. «Solicitud enviada» es distinto de «solicitud aceptada»; «cambio observado en el campo» es distinto de «todos los requisitos comprobados»; y «pruebas seleccionadas completadas» es distinto de «no queda ningún problema». Un mensaje preciso ayuda a la persona que recibe el resultado a decidir si debe esperar, revisar o aceptar la tarea.

Lista de comprobación para diseñar un flujo

La evaluación de agentes puede considerar si un sistema que ejecuta acciones completa un trabajo de forma fiable, y las pruebas pueden ayudar a interpretar ejecuciones concretas. Pero una puntuación, un estado de ejecución o una respuesta de la herramienta no reemplazan la definición del resultado que importa en una tarea particular. El equipo debe traducir la solicitud en criterios que puedan observarse y relacionar cada conclusión con la evidencia que la respalda.

Antes de aceptar o comunicar una tarea como terminada, recorre esta lista. Si no puedes responder una pregunta, eso no implica siempre que la tarea haya fallado; sí indica que conviene limitar la afirmación, obtener la evidencia que falta o pedir una revisión acorde con el impacto.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.