Tu agente de IA dijo “listo”. ¿Cómo saber si funcionó?

Tiempo estimado de lectura: 10 minutos. Fuentes consultadas el 26 de octubre de 2026.

El agente respondió “listo”, mostró un resumen organizado e incluso añadió una marca verde. Excelente. Ahora llega la pregunta que importa a quien mantiene un sistema funcionando: ¿qué quedó listo, exactamente?

Si la tarea consistía en publicar un anuncio, necesitamos encontrar el anuncio correcto en la cuenta correcta. Si era actualizar un registro, necesitamos comprobar los campos modificados. Si era procesar una solicitud, necesitamos conocer su estado final, incluido lo ocurrido cuando alguna etapa falló.

En mi experiencia con integraciones y con Oombe, mirar el resultado forma parte del trabajo. Al incorporar IA al flujo, sigo necesitándolo. La elocuencia de una respuesta no cambia la regla de negocio.

Por eso me gusta tratar las evals, las evaluaciones de sistemas de IA, como una forma de someter la confianza al análisis y la medición. El equipo debe poder explicar qué aprobó, con qué casos como fundamento y dentro de qué límites.

Empieza por lo que debería existir al final

Anthropic distingue el registro de la ejecución del resultado en el entorno: una conversación puede anunciar éxito mientras el estado final muestra otra cosa. La distinción resulta especialmente útil cuando los agentes usan herramientas y modifican sistemas.

Mi primera pregunta sería: ¿qué condición concreta debe cumplirse cuando termine la tarea?

Para una actualización de inventario ficticia, escribiría algo así: la cantidad del producto autorizado corresponde a la solicitud, la cuenta sigue siendo la correcta y ninguna otra cantidad ha cambiado. Para extraer datos, exigiría campos verificables e indicación explícita de la información que falta.

También definiría el comportamiento aceptable cuando falta información. Pedir un identificador ausente puede ser la conclusión correcta. Inventarlo para parecer productivo debe reprobar la evaluación.

La documentación de Claude sobre criterios de éxito recomienda criterios específicos, medibles y relevantes para la aplicación. Mi aplicación de ese principio sería sustituir “el agente debe ser bueno” por condiciones que dos personas puedan evaluar de manera similar.

Los casos de prueba deben parecerse a tu trabajo

Un benchmark público puede orientar una investigación. Para decidir sobre un producto, también prepararía un conjunto de situaciones del propio dominio.

Imagina un agente demostrativo que prepara actualizaciones de anuncios para un marketplace ficticio. Este sería un punto de partida, utilizando exclusivamente datos sintéticos:

Situación de prueba	Evidencia esperada
Solicitud válida y completa	Cambio correcto en el artículo autorizado
Identificador ausente	Petición de información o cierre identificado
Dos cuentas con productos similares	Conservación de la cuenta indicada
Evento recibido de nuevo	Ausencia de efectos duplicados
Respuesta perdida después de guardar	Consulta del estado antes de decidir repetir
Éxito parcial en un lote	Registro separado de elementos completos y pendientes
Fallo temporal del proveedor	Intentos limitados y finalización rastreable
Campo incompatible con una regla	Rechazo explicado sin modificar datos válidos

La tabla es una propuesta de diseño, sin resultados medidos. El criterio de aprobación también debe considerar el contrato específico de la API. Los proveedores no ofrecen necesariamente la misma consulta de estado ni el mismo mecanismo de idempotencia.

Incluiría variaciones de lenguaje, campos vacíos y combinaciones de condiciones. Una tarea no debería aprobarse solo porque el texto del usuario coincide con el ejemplo utilizado para crear el prompt.

Un reintento es una decisión sobre los efectos

Cuando falla una llamada, la reacción automática suele ser volver a intentarlo. Pero “no recibí la respuesta” y “la operación no ocurrió” describen estados diferentes.

La AWS Builders' Library describe identificadores de solicitud que permiten reconocer repeticiones y hacer previsibles los efectos de los reintentos. El comportamiento depende del contrato de la operación, incluido el tratamiento de parámetros y el periodo de retención.

En el laboratorio propuesto, simularía una escritura completada cuya respuesta se pierde. Después observaría si el agente consulta el estado disponible, conserva la identidad de la operación o simplemente crea otra.

También simularía un lote con resultados mixtos. La evaluación comprobaría qué elementos siguen pendientes y si una reanudación conserva los ya completados. “Procesarlo todo otra vez” puede resultar caro según el efecto externo.

Hay dos capas que evaluar: qué decidió el agente y qué garantizó la herramienta. Una herramienta con validaciones sólidas puede impedir un error propuesto por el agente. El informe debe registrar ambas cosas para que el equipo entienda de dónde vino la protección.

Los datos sintéticos permiten empezar con control

Prepararía un catálogo ficticio pequeño, cuentas inventadas, identificadores propios de la prueba y respuestas simuladas. Así sería posible provocar fallos sin involucrar operaciones de clientes.

Cada caso tendría entrada, estado inicial, resultado esperado, condiciones prohibidas y una breve explicación del motivo. Esa explicación facilita revisar una prueba cuando cambia la regla de negocio.

Separaría los ejemplos utilizados para mejorar el sistema de un conjunto reservado para la evaluación final. Si ajustamos el prompt mirando siempre las mismas preguntas, podemos terminar enseñando el examen sin mejorar la capacidad que nos interesa.

La documentación de LangSmith distingue las evaluaciones offline, sobre conjuntos preparados, de la observación de ejecuciones en producción. Usaría ambas perspectivas en momentos diferentes: primero controlar el experimento y después descubrir condiciones que el laboratorio no representó.

Los datos sintéticos también tienen límites. Reflejan las situaciones que somos capaces de imaginar. Un conjunto perfectamente ordenado puede dejar fuera el desorden que vuelve difícil una integración.

Una ejecución feliz dice poco sobre la consistencia

Si un agente resuelve una tarea una vez, sabemos que esa ejecución funcionó. Para entender si repite el resultado, necesitamos ejecutarlo de nuevo y conservar los fracasos en el cálculo.

τ-bench, presentado en 2024, evalúa interacciones con herramientas y reglas del dominio mediante la comparación de estados finales. El trabajo también propone una métrica de éxito consistente entre varios intentos. Sus resultados pertenecen a los modelos y escenarios estudiados entonces.

En mi conjunto, distinguiría dos preguntas: “¿acertó alguna vez?” y “¿con qué frecuencia entrega correctamente?”. Para una automatización que afecta a un cliente, la segunda suele ser decisiva.

Registraría las versiones del modelo, prompt, herramientas, skill y configuración, además de los límites de intentos. Restauraría el estado inicial entre ejecuciones independientes y mantendría separadas las simulaciones de continuidad.

Pocas repeticiones pueden revelar defectos útiles, pero no justifican una afirmación estadística ambiciosa. Un informe debe mostrar la cantidad de casos, la distribución de fallos y la incertidumbre junto al porcentaje principal.

Quien evalúa también necesita evaluación

Siempre que el resultado pueda comprobarse mediante una regla objetiva, empezaría por ella: cantidad de registros, campos, identificadores, estados y acciones realizadas.

Para aspectos como la claridad de una explicación, puede ayudar un modelo evaluador. El estudio sobre LLM-as-a-judge con MT-Bench y Chatbot Arena documenta limitaciones como los sesgos relacionados con la posición y la extensión de las respuestas. Por tanto, una nota producida por IA también necesita examen.

Escribiría una rúbrica breve, con ejemplos claros de aprobación y rechazo. Después compararía las decisiones del evaluador con decisiones humanas en una muestra e investigaría las discrepancias. Las respuestas largas no deberían recibir puntos adicionales solo por aparentar más cuidado.

También evitaría un promedio que oculte fallos críticos. Modificar la cuenta equivocada debe aparecer como un fallo propio, aunque el mensaje final sea impecable. Una explicación poco elegante puede recibir una clasificación de impacto menor.

Cuando dos revisores discrepan con frecuencia, el problema puede estar en el criterio. Conviene mejorar la definición antes de convertir esa discrepancia en otro decimal del panel.

Un laboratorio Laravel sin depender de cuentas reales

Para quienes trabajan con Laravel, organizaría un proyecto demostrativo con cuatro componentes: catálogo sintético, adaptador de marketplace ficticio, ejecutor de tareas y verificador del estado final. Es una propuesta de arquitectura de evaluación, no un tutorial de código ya ejecutado.

El cliente HTTP de Laravel ofrece recursos para simular respuestas y comprobar solicitudes en las pruebas. Permiten representar respuestas satisfactorias, errores y secuencias de retorno sin depender de un proveedor real.

La documentación de colas también presenta herramientas para comprobar el envío de jobs. Complementaría esa comprobación con la ejecución controlada de la lógica: colocar un job en una cola, por sí solo, no demuestra que se completó el efecto esperado.

El verificador se ejecutaría después de la tarea e inspeccionaría el entorno inicializado para ese caso. También examinaría el registro de llamadas para detectar una acción indebida que después hubiera sido compensada.

Una simulación no reproduce toda la infraestructura. Después hacen falta pruebas de integración compatibles con los recursos oficiales del proveedor y con el riesgo de la operación. La secuencia debe ampliar la evidencia gradualmente.

Mide cuánto cuesta una tarea aprobada

El coste por llamada ayuda, pero el producto también debe pagar los intentos fallidos, las consultas adicionales y las recuperaciones.

Mediría coste de ejecución por tarea aprobada = coste de todas las ejecuciones ÷ cantidad de tareas aprobadas. El conjunto y los criterios deben ser iguales para que la comparación tenga sentido.

Un ejemplo exclusivamente aritmético: en 100 tareas sintéticas, una configuración cuesta R$ 18 y aprueba 60; otra cuesta R$ 24 y aprueba 96. La primera llega a R$ 0,30 por aprobación; la segunda, a R$ 0,25. Estas cifras no son resultados de un experimento.

La cuenta todavía deja fuera la revisión humana, el mantenimiento y los perjuicios causados por errores. Mostraría esos elementos por separado, junto al tiempo de respuesta y la gravedad de los fallos. Un pequeño ahorro no decide por sí solo si una configuración sirve para la operación.

Convierte el resultado en una decisión de entrega

Antes de comparar versiones, definiría los impedimentos para el lanzamiento y las mejoras deseables. Así, una nota agregada alta no podría ocultar un problema que el equipo ya considera inaceptable.

Cada fallo relevante se convertiría en un caso de regresión, con su causa conocida y el comportamiento esperado. En producción, observaría señales de cambio y conservaría una forma de detener o limitar el flujo.

Este cuidado también conecta con la conversación sobre agentes, permisos y alertas operativas. El producto debe permitir investigar qué ocurrió sin depender exclusivamente de la versión presentada por el agente.

Para empezar, elegiría una sola tarea que hoy necesita comprobación manual y convertiría esa comprobación en criterios explícitos. El beneficio inicial ya es útil: el equipo comienza a discutir evidencias concretas. A partir de ahí, puede aumentar la autonomía sabiendo mejor qué está aprobando.

Fuentes

1. Anthropic — Demystifying evals for AI agents.
2. Claude — criterios de éxito y evaluaciones.
3. AWS — Making retries safe with idempotent APIs.
4. LangSmith — conceptos de evaluación.
5. τ-bench — evaluación de interacciones entre agentes, herramientas y usuarios.
6. Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
7. Laravel 13 — pruebas del cliente HTTP.
8. Laravel 13 — pruebas de colas.