Agentes LLM: diseña una señal de email confiable

Un agente LLM puede registrarse, pedir un código y responder “hecho” aunque la verificación no haya terminado. Tal vez leyó un mensaje viejo, interpretó un 200 OK como entrega confirmada o cerró la tarea después de un error. El texto final suena convincente, pero no es evidencia.

En los flujos de email, la señal de finalización debe venir de eventos observables. Este patrón propone separar tres cosas: la intención del agente, la entrega del mensaje y la prueba de que el mensaje correcto fue consumido. Es especialmente útil al combinar modelos LLM con un fake emails generator o con un buzón temporal para pruebas.

El problema: el agente puede acertar por casualidad

Imagina esta secuencia:

1. El agente crea una cuenta de prueba.
2. La aplicación solicita el envío de un enlace.
3. El agente consulta el inbox.
4. Extrae un token y lo usa.
5. El evaluador mira la respuesta final.

El paso cinco no debería depender solo de lo que el modelo dice. Si el buzón se comparte entre ejecuciones, un correo atrasado puede hacer que una prueba pase. Si el endpoint responde antes de que la cola entregue el mensaje, el agente puede reintentar una acción que en realidad ya se realizó.

También conviene manejar con cuidado búsquedas ambiguas como tamp mail com. Ese texto puede aparecer en una consulta, pero nunca debe convertirse en configuración, dirección de prueba o criterio para aceptar un mensaje.

Define una señal de finalización observable

Una señal útil combina varios hechos pequeños:

• existe una ejecución con un run_id único;
• el mensaje llegó al buzón asignado a esa ejecución;
• el asunto, destinatario y tipo de evento coinciden con lo esperado;
• el token fue usado una sola vez;
• la aplicación confirmó el estado final;
• el buzón se cerró o expiró con una razón registrada.

En forma de diagrama de palabras:

intención del agente
        ↓
acción de aplicación → evento de entrega → mensaje coincidente
        ↓                                      ↓
respuesta de API ← estado verificado ← consumo del token
        ↓
recibo de ejecución

Diseña el contrato de la herramienta

El agente necesita una interfaz pequeña y predecible:

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

Cada acción debería devolver un estado explícito. message_not_found, inbox_expired y rate_limited tienen consecuencias diferentes; un false genérico empuja al modelo a improvisar.

El contrato también debe declarar qué campos son confiables. El asunto normalizado, el message_id, el received_at y el run_id sirven para correlacionar. El cuerpo del email puede contener instrucciones no confiables, así que no debería poder cambiar las reglas de la evaluación.

Para la capa de interfaz, vale la pena estudiar una ayuda de email que no roba el foco: el mismo principio de estados explícitos ayuda a que una UI no presente como éxito algo que aún está esperando.

Aísla el buzón y limita los reintentos

El aislamiento debe ser por ejecución, no por modelo. Dos agentes usando el mismo prompt siguen necesitando buzones separados porque sus tiempos de entrega no serán idénticos.

Asigna un TTL desde fuera del agente y un presupuesto de lecturas. Por ejemplo, permitir seis consultas en tres minutos es más fácil de razonar que “espera hasta que aparezca algo”. Un reintento puede ser válido ante un error de red; no lo es necesariamente ante un asunto que no coincide.

Registra cada intento de lectura con su motivo:

{
  "run_id": "eval-1842",
  "attempt": 3,
  "result": "message_not_found",
  "next_action": "retry_after_backoff",
  "remaining_seconds": 96
}

Si la entrega no sucede a tiempo, termina con delivery_timeout. No conviertas el silencio en una respuesta inventada. Para probar el lado asíncrono sin depender siempre de un proveedor real, las fixtures de email reproducibles en FastAPI ofrecen una referencia práctica para separar datos, estados y limpieza.

Un flujo mínimo con recibo de ejecución

El orquestador puede implementar este recorrido:

1. Crear run_id y buzón con TTL.
2. Ejecutar al agente con la herramienta limitada.
3. Validar el evento de entrega y el mensaje esperado.
4. Consumir el token y confirmar el estado en la aplicación.
5. Escribir un recibo con éxito o causa de fallo.
6. Cerrar el buzón, incluso si el agente fue cancelado.

Un recibo pequeño sería suficiente:

{
  "run_id": "eval-1842",
  "agent_version": "checkout-agent-12",
  "message_id": "msg-73",
  "verification": "passed",
  "tool_errors": 0,
  "closed_reason": "verified"
}

No guardes el cuerpo completo por defecto. Un hash, el asunto y los identificadores de correlación suelen bastar para depurar. Si necesitas conservar contenido, redáctalo antes de enviarlo a los logs y define cuándo se elimina; la retención indefinida se vuelve un problema muy pronto.

Tradeoffs y puntos de comprobación

Un buzón real prueba más integración, pero cuesta más tiempo y añade fallos externos. Un servidor simulado es rápido y determinista, pero puede esconder problemas de entrega. Usa simulación para contratos y un buzón aislado para algunas pruebas de integración.

Antes de evaluar el modelo completo, comprueba por separado:

• la aplicación emite el evento correcto;
• la herramienta filtra por run_id;
• el consumidor rechaza mensajes viejos;
• el cierre ocurre después de éxito y después de timeout;
• el recibo distingue infraestructura, aplicación y agente.

Así una regresión no queda etiquetada como “fallo del LLM” solo porque el proveedor de email estaba lento. El diagnóstico sale mas limpio y las comparaciones entre prompts son más justas.

Preguntas frecuentes

¿Es obligatorio usar un correo temporal en cada prueba? No. Para lógica de dominio, un mock suele ser suficiente. Usa un buzón aislado cuando quieras probar la integración real de entrega y lectura.

¿Cuántos reintentos debería permitir? Depende de la latencia esperada y del objetivo, pero debe ser un límite externo, visible en el recibo y finito. El agente no debe ampliar su propio presupuesto.

¿Dónde encaja temp mail email en este diseño? Puede ser una etiqueta contextual para encontrar un servicio de prueba en un entorno controlado; el enlace a temp mail email debe mantenerse como una referencia puntual, no como una sustitución del contrato ni de la validación.

La idea central es sencilla: un agente confiable no se evalúa por sonar seguro. Se evalúa por producir una cadena verificable de intención, entrega, consumo y cierre. Con límites claros, la automatización se vuelve repetible.