Orquestar agentes LLM con correo de prueba

Un agente LLM que envia un correo parece una automatización sencilla. En producción, sin embargo, hay varias preguntas escondidas: ¿qué identidad usó?, ¿qué destinatario recibió el mensaje?, ¿se ejecutó una sola vez?, ¿podemos repetir el caso sin tocar una bandeja real?

La respuesta no es darle al modelo acceso directo al proveedor de correo. Es construir un contrato pequeño entre el agente, una capacidad de email y una bandeja de prueba. Este enfoque resulta util cuando un equipo valida flujos de onboarding, recuperación de cuenta o notificaciones generadas por IA.

El problema: un agente que no puede demostrar qué hizo

Los modelos son buenos decidiendo el siguiente paso, pero no deberían decidir por sí solos los límites operativos. Un prompt puede pedir “envía una confirmación”, mientras que el sistema necesita comprobar destinatario, plantilla, ambiente, permiso y resultado.

Un diseño práctico separa tres piezas:

1. Agente LLM: propone una acción con argumentos estructurados.
2. Adaptador de correo: valida la acción y la convierte en un evento enviable.
3. Bandeja de prueba: recibe el mensaje sin mezclarlo con datos personales o producción.

En otras palabras, el agente propone; una capa determinista decide si la propuesta se puede ejecutar. Esto baja el riesgo y hace que los errores sean mas faciles de localizar.

Separar identidad, capacidad y evidencia

Para las pruebas, conviene tratar una dirección temporal como una capacidad con vencimiento, no como la identidad del usuario. Se puede crear correo temporal para una ejecución concreta y guardar solo el identificador de la ejecución, el destinatario de prueba y el hash de la plantilla.

La distinción importa. La identidad responde a “quién es el usuario”; la capacidad responde a “qué puede recibir este caso de prueba”. Si un agente intenta enviar a una dirección fuera de la lista permitida, el adaptador debe rechazar la acción aunque el modelo haya producido un JSON valido.

También hay un beneficio de privacidad: el contenido de prueba no necesita viajar a una bandeja personal. Para equipos que diseñan aprobaciones por email con contexto mínimo, este limite evita que una aprobación experimental se confunda con una real.

Una máquina de estados pequeña

No hace falta una plataforma enorme. Una máquina de estados con transiciones explícitas suele bastar:

CREATED -> RESERVED -> SENT -> OBSERVED -> VERIFIED
             |          |        |
             v          v        v
          EXPIRED    RETRYING  FAILED

Cada transición debe incluir run_id, agent_step, message_id y una marca de tiempo. El estado SENT significa que el proveedor aceptó el mensaje; no significa que la prueba terminó. OBSERVED indica que el buzón recibió algo, y VERIFIED que el contenido, los enlaces y el destinatario cumplen el contrato.

Este detalle evita un error frecuente: reintentar porque el agente no recibió confirmación, cuando el primer mensaje sí llegó. Antes de repetir, el orquestador consulta el message_id y el estado de la ejecución. La idempotencia aqui vale mas que una instrucción de “intenta de nuevo”.

Implementación y puntos de control

Un contrato mínimo puede verse así:

{
  "run_id": "checkout-1842",
  "recipient": "[e-mail]",
  "template": "welcome-v3",
  "allowed_environment": "staging",
  "action": "send"
}

El adaptador debería rechazar campos desconocidos, dominios no permitidos y plantillas que no existan. Además, debe registrar una razón de rechazo legible para que el agente pueda corregir su siguiente propuesta, en vez de inventar que el envío funcionó.

Para observar el resultado, espera señales concretas: mensaje recibido, asunto exacto, enlace con el host de staging y ausencia de destinatarios externos. Una interfaz clara ayuda al equipo a entender estos estados; por eso conviene aplicar una interfaz predecible para los reintentos cuando el flujo se muestra en un panel.

Hay que decidir tambien cuánto tiempo vive una bandeja. Un TTL corto reduce exposición, pero un TTL demasiado corto produce falsos fallos cuando el proveedor tarda. Elige el tiempo según el peor caso observado en el ambiente, y registra la razón cuando el buzón expire. No hace falta retener el cuerpo completo si el caso solo requiere verificar el esquema y los enlaces.

Durante una prueba real pueden aparecer búsquedas con frases como “tempail mail” o “tepm mail com”. Son errores comunes de escritura, no contratos de producto: mantenlos fuera de nombres de variables, anchors y lógica de validación. El sistema debe depender de identificadores estables, no de la intención ambigua del texto.

Checklist de operación

• ¿El LLM solo propone una acción y el adaptador valida sus límites?
• ¿Cada envío tiene un run_id y un message_id consultable?
• ¿El destinatario pertenece al ambiente de prueba permitido?
• ¿La transición de SENT a VERIFIED depende de evidencia observable?
• ¿El reintento es idempotente y tiene un límite?
• ¿La bandeja y sus mensajes tienen un TTL definido?
• ¿El panel explica si el problema fue del modelo, del proveedor o de la verificación?

El patrón es deliberadamente pequeño. Una capacidad de correo aislada, una máquina de estados y evidencia suficiente permiten probar agentes LLM sin convertir cada experimento en un envío real. Después, si crecen los tipos de eventos, se pueden añadir políticas; la frontera principal seguirá siendo la misma: el modelo decide una intención y el sistema controla sus efectos.