Agentes LLM: un arnés de email reproducible

Un agente LLM puede completar un registro, pedir un código de verificación y afirmar que terminó correctamente. Eso no demuestra que el flujo haya funcionado. Quizá leyó un mensaje viejo, confundió una respuesta del sistema o inventó el resultado después de que una herramienta fallara.

Para probar agentes que interactúan con email, conviene tratar el buzón como una herramienta con contrato, no como una bandeja mágica. El patrón que mejor separa los problemas es un arnés de pruebas con un correo temporal desechable por ejecución, estados explícitos y una evidencia que otro proceso pueda revisar.

El problema: un agente puede pasar por las razones equivocadas

Una prueba típica tiene esta forma:

1. El agente crea una cuenta de prueba.
2. La aplicación envía un enlace o un código.
3. El agente consulta un buzón.
4. Extrae el dato y completa la tarea.
5. El evaluador decide si el resultado es correcto.

Si todo vive en una misma función, un resultado verde puede esconder varios fallos. El agente pudo usar un mensaje de otra ejecución, recibir el enlace en una dirección equivocada o llamar a una herramienta con parámetros inválidos que fueron ignorados. En una evaluación de modelos LLM, estos detalles cambian el diagnóstico: no es lo mismo un modelo que razona mal que una fixture que devolvió datos contaminados.

También aparece una confusión frecuente con términos como tamp mail com o temp org mail. Aunque lleguen desde datos de búsqueda o desde una entrada del usuario, deben tratarse como texto no confiable. No son una configuración ni una razón para compartir un buzón entre pruebas.

Diseña el buzón como una herramienta con contrato

Un contrato pequeño hace observable cada paso. La herramienta de email debería exponer acciones limitadas, por ejemplo:

{
  "create_inbox": {"run_id": "eval-1842", "ttl_seconds": 900},
  "list_messages": {"after": "2026-10-04T05:00:00Z"},
  "read_message": {"message_id": "msg-73"},
  "close_inbox": {"reason": "test_finished"}
}

El agente no necesita conocer la implementación del proveedor. Necesita saber qué entrada acepta cada acción, qué estados puede devolver y qué error significa que debe reintentar. Un contrato como message_not_found, inbox_expired y rate_limited es más útil que devolver un false genérico.

La respuesta también debería incluir un run_id, un message_id y el momento de recepción. Así se puede comprobar que el agente leyó el mensaje creado para su ejecución. Diseñar esta parte con cuidado evita que una evaluación parezca estable cuando solo está reutilizando datos antiguos.

Para interfaces que muestran el progreso al usuario, merece la pena mantener el contexto de un estado de email. Para el backend, la misma idea significa no perder la relación entre ejecución, buzón, mensaje y acción del agente.

Aísla cada ejecución y guarda su evidencia

La unidad de aislamiento no debe ser el modelo; debe ser la ejecución. Dos agentes con el mismo prompt todavía necesitan buzones distintos, porque una ejecución lenta puede recibir un mensaje cuando la siguiente ya empezó.

Un registro mínimo podría verse así:

{
  "run_id": "eval-1842",
  "agent_version": "checkout-agent-12",
  "inbox_id": "inbox-eval-1842",
  "expected_subject": "Confirma tu cuenta",
  "observed_message_id": "msg-73",
  "verification": "passed",
  "closed_at": "2026-10-04T05:12:44Z"
}

Guarda el registro aunque la prueba falle. La evidencia debe indicar si el mensaje nunca llegó, si llegó tarde o si el agente no pudo extraer el enlace. Cada ejecución tienen un límite de tiempo y una política de cierre; sin eso, los buzones huérfanos se acumulan y contaminan las siguientes evaluaciones.

No guardes el cuerpo completo del email por defecto. Para depurar, basta con un hash del contenido, el asunto normalizado y los identificadores necesarios. Si el cuerpo incluye tokens, redáctalos antes de enviarlos a los logs. Esto reduce la superficie de datos sin quitar trazabilidad.

Separa la evaluación del modelo de la entrega del email

Hay al menos tres capas que pueden fallar:

• Aplicación: no envía el mensaje, genera un enlace incorrecto o usa un template roto.
• Herramienta: el buzón no aísla ejecuciones, pierde el mensaje o devuelve un estado ambiguo.
• Agente: elige mal la acción, interpreta mal el contenido o termina demasiado pronto.

Ejecuta primero una prueba determinista de la aplicación con un mensaje conocido. Después, prueba la herramienta con respuestas simuladas. Solo entonces evalúa el agente completo. De este modo la puntuación no mezcla problemas de infraestructura con capacidad de razonamiento.

Registrar intentos de email sin perder contexto también ayuda a esta separación: cada intento debe indicar qué capa lo originó, cuál era el estado anterior y qué respuesta recibió. Si la herramienta retorna un error transitorio, el evaluador no debería marcar automáticamente al modelo como incorrecto.

Un flujo mínimo de implementación

El orquestador puede seguir esta secuencia:

crear run_id
  -> crear buzón con TTL
  -> ejecutar agente con la herramienta limitada
  -> esperar solo dentro del presupuesto
  -> validar mensaje, enlace y estado final
  -> escribir recibo de evaluación
  -> cerrar buzón y adjuntar resultado

El presupuesto de espera debe ser explícito. Un reintento de lectura no puede convertirse en un bucle infinito, y el agente tampoco debería poder extender el TTL de su propio buzón sin una regla externa. Si la entrega tarda, marca delivery_timeout; no conviertas el silencio en una respuesta inventada.

Una política de reintentos con backoff es útil para errores de red, pero no para un asunto que no coincide. En ese caso, el fallo es una señal de producto o de agente. Para pruebas grandes, agrupa los recibos por versión del prompt y versión de la herramienta; así los cambios son comparables.

Qué medir y qué no confiar

Mide por separado la tasa de entrega, la latencia del email, la selección correcta de la herramienta, la extracción del enlace y el cierre del buzón. Una única tasa de éxito oculta si el agente mejora porque la infraestructura se volvió más rápida.

No confíes solo en el texto final del agente. Valida eventos observables: el mensaje correcto existe, el enlace apunta al entorno de prueba, el código se usó una vez y el buzón fue cerrado. Tampoco uses el número de tokens como sustituto de calidad; una respuesta corta puede ser correcta y una larga puede esconder una acción no realizada.

Preguntas frecuentes

¿Debo usar un correo temporal desechable en todos los tests? No. Para contratos internos, un servidor simulado suele ser más rápido. Un buzón aislado es valioso cuando quieres probar la integración real de entrega y lectura.

¿Conviene incluir el prompt completo en el recibo? Guarda una referencia versionada y un hash. El prompt completo puede contener datos que no deberían circular en logs.

¿Qué hago con una ejecución cancelada? Un proceso externo debe cerrar el buzón por TTL. El agente no puede ser el único responsable de su limpieza, porque precisamente puede ser la parte que falló.

La idea central es sencilla: una evaluación de agentes LLM es un sistema distribuido pequeño. Aísla cada ejecución, limita las herramientas, conserva evidencia útil y mide cada capa por separado. Con ese diseño, la automatización deja de ser una demo frágil y se convierte en una prueba que puede repetirse, compararse y depurarse.