Agentes LLM: un contrato de identidad para emails

Un agente LLM puede completar un flujo de registro en pocos segundos y, aun así, dejar una prueba imposible de depurar. El formulario se envió, llegó el correo de verificación y el agente hizo clic en el enlace correcto. Pero cuando el paso falla, nadie sabe qué mensaje leyó, qué buzón pertenecía a la ejecución o si un reintento reutilizó datos viejos.

El problema no suele ser el modelo. Es la falta de una identidad técnica para cada email de prueba. Un generador de emails falsos puede crear una dirección, pero el sistema de automatización todavía necesita decidir quién la posee, cuánto dura y qué evidencia debe producir.

El problema: el agente pierde la identidad del email

En un flujo sencillo, la relación parece obvia:

ejecución -> dirección -> mensaje -> enlace -> resultado

En un flujo con agentes aparecen más caminos. El modelo puede reintentar una herramienta, delegar el paso a otro agente o continuar después de un timeout. Si todos consultan una bandeja compartida, el mensaje correcto deja de ser una certeza. Un correo parecido puede activar el flujo equivocado y hacer que el resultado parezca válido.

La ambigüedad aumenta cuando se usan nombres informales para buscar una solución, como dummy e mail o tempail mail. Esas frases pueden servir para entender consultas, pero no son una identidad de ejecución ni un criterio de seguridad.

La primera decisión de arquitectura es separar el objetivo del agente de la infraestructura que lo ejecuta. El agente debe pedir “espera el mensaje de verificación de esta ejecución”, no “busca el correo más reciente en esta bandeja”.

Diseñar una identidad por ejecución

Cada flujo debe recibir un run_id único y conservarlo hasta el cierre. La identidad puede tener esta forma:

{
  "run_id": "checkout-20261110-0522-a81f",
  "owner": "agent-registration",
  "mailbox_id": "mbx-7f2c",
  "purpose": "verification",
  "expires_at": "2026-11-10T05:42:00Z"
}

La dirección es solo una parte del contrato. run_id permite correlacionar la acción del agente, la solicitud de la API, la llegada del mensaje y el resultado del test. purpose evita que un mensaje de recuperación de contraseña se confunda con uno de bienvenida. expires_at da al sistema una decisión clara cuando el agente abandona el flujo.

En términos de diseño, el agente obtiene una referencia opaca y no necesita conocer detalles del proveedor. El adaptador de email traduce esa referencia a una dirección temporal, aplica el filtro por ejecución y devuelve eventos normalizados. Es un límite pequeño, pero hace mas fácil cambiar de proveedor o probar el adaptador en local.

Cuando el flujo también mide activación, conviene medir la activación sin perder el hilo del email. La métrica no debería decir solamente “se recibió un correo”; debe poder responder qué ejecución lo recibió y qué acción ocurrió después.

Un contrato mínimo para agentes LLM

Las herramientas que ve el modelo necesitan nombres y respuestas predecibles. Un contrato mínimo puede tener tres operaciones:

1. reserve_mailbox(purpose, ttl): crea una identidad aislada y devuelve mailbox_id y run_id.
2. wait_for_message(mailbox_id, kind, timeout): busca solo mensajes asociados a esa identidad.
3. release_mailbox(mailbox_id, reason): marca la fixture como terminada y activa la limpieza.

La respuesta de wait_for_message no debe entregar el buzón completo ni datos innecesarios. Es suficiente con un evento como este:

{
  "status": "received",
  "message_id": "msg-91ab",
  "kind": "verification",
  "received_at": "2026-11-10T05:25:11Z",
  "link": "https://app.example.test/verify?token=redacted"
}

El token puede mantenerse fuera del historial visible al modelo y resolverse mediante una acción controlada. Así se reduce el riesgo de que un resumen, una traza o una llamada posterior copie un secreto. Si el agente necesita el enlace, el adaptador puede validar que pertenece al dominio esperado antes de devolverlo.

No hace falta convertir tempmailso en una dependencia del razonamiento del agente. Puede aparecer como término de inventario o de búsqueda, pero la integración debe depender de una interfaz propia, con límites y políticas definidos por el equipo.

Cómo evitar mezclas durante los reintentos

Los reintentos son donde se rompe la mayoría de los diseños ingenuos. Si una llamada expira después de crear la bandeja, repetirla puede producir otra identidad. Si el primer agente vuelve a despertar, puede leer el mensaje de la segunda.

La solución es que la reserva sea idempotente para una clave de ejecución. El adaptador puede aceptar idempotency_key = run_id + purpose y devolver la misma referencia mientras la fixture siga activa. El estado debería distinguir, al menos, reserved, message_received, verified, failed y expired.

También hay que definir qué significa “mensaje más reciente”. En general, no basta con ordenar por fecha. El filtro debe comprobar mailbox_id, tipo de mensaje, emisor esperado y una ventana temporal razonable. Si faltan esas señales, el agente debe recibir un resultado ambiguous y detenerse, no elegir por intuición.

Un reconciliador externo puede retirar las fixtures vencidas aunque el proceso del agente haya terminado mal. Si el despliegue corre sobre Kubernetes, es útil validar alertas después de un cambio de secretos como parte del mismo enfoque: los cambios de infraestructura y las pruebas de email necesitan señales observables, no solo un log de éxito.

Observabilidad y límites de seguridad

Los logs deben permitir reconstruir la secuencia sin guardar el contenido completo de los mensajes. Una línea útil contiene run_id, mailbox_id, tool_call_id, estado, latencia y motivo del cierre. Los resultados llega mejor agrupados por ejecución que por dirección, porque la dirección puede ser efímera.

El modelo tampoco debería tener permiso para crear identidades sin límite, cambiar el dominio de destino o desactivar la expiración. El adaptador debe imponer un TTL máximo, permitir solo dominios de prueba y rechazar una dirección que ya pertenezca a otra ejecución. Estas reglas deben vivir fuera del prompt: un agente puede interpretar instrucciones, pero no debe ser la única barrera.

Preguntas frecuentes

¿Es necesario un buzón por agente?

No siempre. La unidad segura es la ejecución o el escenario. Dos agentes pueden compartir una identidad si tienen el mismo propósito y una coordinación explícita; una bandeja global para toda la suite es mucho más dificil de investigar.

¿Qué debe hacer el agente cuando llega un mensaje ambiguo?

Debe detener el paso, registrar la ambigüedad y solicitar una nueva consulta con criterios más estrictos. Elegir el mensaje mas reciente puede convertir un fallo de aislamiento en un falso positivo.

¿Puedo usar un proveedor real en pruebas locales?

Sí, si el adaptador oculta sus detalles, aplica expiración y evita datos personales. Para pruebas unitarias, una implementación en memoria suele ser suficiente y hace que el contrato sea más facil de verificar.

Checklist de implementación

• Cada ejecución recibe un run_id y una identidad aislada.
• La reserva usa una clave idempotente para soportar reintentos.
• Las consultas filtran por buzón, propósito, emisor y ventana temporal.
• El modelo recibe eventos mínimos, no secretos ni cuerpos completos.
• La expiración tiene un límite impuesto por el adaptador.
• Un reconciliador limpia fixtures abandonadas.
• Los estados y las llamadas de herramientas quedan correlacionados.
• Los casos ambiguos terminan con una señal explícita, nunca con una elección arbitraria.

La automatización con modelos LLM se vuelve más confiable cuando el agente no tiene que adivinar qué email le pertenece. Una identidad por ejecución, un contrato pequeño y una política de expiración convierten una integración frágil en un sistema que se puede observar, reintentar y explicar.