Agentes LLM: reserva el inbox antes de usarlo

Cuando un agente LLM puede crear una cuenta, pedir un código y leer un email, el buzón deja de ser un detalle de infraestructura. Se convierte en parte del estado de la ejecución.

Esto importa porque dos agentes pueden empezar el mismo flujo casi al mismo tiempo. Si ambos consultan “el último mensaje recibido”, uno puede consumir la evidencia del otro. El resultado parece un fallo aleatorio de la automatización, aunque el problema real es que nunca hubo propiedad sobre el inbox.

Una búsqueda como temp mail so suele mezclar casos de uso muy distintos. Para un agente, la pregunta técnica es más concreta: ¿quién puede leer este buzón, durante qué intervalo y con qué prueba de que el mensaje pertenece a su ejecución?

Aunque los asuntos sean parecidos, el primer mensaje que aparece no es necesariamente el que corresponde al agente que está preguntando. Un reintento lo hace peor: puede leer un mensaje válido de una ejecución anterior y marcar el paso como completado.

La solución no es pedirle al modelo que “tenga más cuidado”. Los modelos LLM trabajan mejor cuando la herramienta expone restricciones verificables. La propiedad debe estar en el contrato y en el servidor, no en una instrucción blanda.

En este punto ayuda separar tres identificadores:

Con esos datos, un log de automatización puede explicar qué pasó sin reconstruir la historia desde texto libre.

Un lease es una reserva con dueño, fecha de expiración y una versión. En palabras simples: el agente obtiene permiso para usar una dirección, pero el permiso no es eterno ni transferible.

Un registro mínimo podría tener esta forma:

{ "leaseId": "lease_8f2", "runId": "run_42", "mailbox": "agent-42@example.test", "status": "active", "expiresAt": "2026-10-16T12:00:00Z", "fence": 7 } Enter fullscreen mode Exit fullscreen mode El fence es un número que aumenta cada vez que una reserva cambia de dueño. Si una ejecución antigua vuelve después de un timeout, su valor anterior ya no sirve para leer ni confirmar mensajes. Este detalle evita que una tarea lenta reviva y escriba sobre el estado actual.

La expiración debe ser corta, pero suficiente para el flujo. Un lease demasiado corto causa renovaciones continuas; uno demasiado largo deja buzones bloqueados. En la práctica, conviene decidir el tiempo desde el presupuesto de latencia del agente, y no usar un valor global por comodidad.

Para signup, también puedes combinar el lease con un alias único. Hay un buen ejemplo de un patrón de alias efímeros para signup que muestra cómo hacer visible esa separación en el backend.

La herramienta que usa el agente debería ofrecer operaciones pequeñas y con resultados explícitos:

reserveMailbox(runId, ttl) -> { leaseId, address, fence, expiresAt } waitForMessage(leaseId, fence, after, selector) -> { messageId, receivedAt, body } ackMessage(leaseId, fence, messageId) -> { acknowledged: true } releaseMailbox(leaseId, fence) -> { released: true } Enter fullscreen mode Exit fullscreen mode waitForMessage no debería aceptar solo una dirección. Debe validar el leaseId, el fence, el momento after y un selector que limite el mensaje esperado. Así, un email viejo no pasa por accidente como evidencia nueva.

Los errores tambien forman parte del contrato. lease_expired, fence_mismatch, message_not_found y provider_unavailable permiten que el agente decida entre renovar, esperar, repetir una acción segura o detenerse. Un error genérico produce reintentos ciegos y hace que la automatización sea mas cara.

Si el flujo incluye upgrades o notificaciones, merece la pena registrar la relación entre evento y email. Auditar emails de upgrade sin mezclar señales desarrolla una idea complementaria: la señal útil no es solo que “llegó algo”, sino que llegó el mensaje que prueba la transición correcta.

El agente debería avanzar por estados que puedan inspeccionarse:

planned -> reserved -> action_sent -> message_seen -> acknowledged -> released Enter fullscreen mode Exit fullscreen mode Cada transición debe comprobar que la ejecución sigue siendo dueña del lease. Si message_seen ocurre después de released, la herramienta debe rechazarlo aunque la dirección todavía exista.

También conviene guardar el motivo de salida. released_success, expired_timeout y released_error son bastante más útiles que un simple booleano. Cuando un operador ve un fallo en CI, puede distinguir una entrega lenta de una colisión real.

La palabra tem email puede aparecer en búsquedas o datos de prueba, pero no debería convertirse en una regla de matching demasiado amplia. Lo mismo vale para temp mailid: una coincidencia parcial puede consumir evidencia de otro escenario. Los selectores deben ser estrictos y preferiblemente combinar destinatario, asunto esperado y un identificador de ejecución.

No necesariamente. Reserva uno por flujo de negocio o por ejecución aislada. Crear una reserva para cada paso añade latencia y hace difícil seguir el historial. La frontera correcta es la unidad que necesita exclusividad.

No aumentes el timeout sin límite. Devuelve el estado observado, conserva el messageId si existe y decide si renovar el lease o terminar la ejecución. Un límite claro protege tanto al proveedor como al presupuesto de automatización.

Puede proponerlo, pero el sistema debe liberar también en una ruta finally o equivalente. Un agente puede detenerse por una respuesta inesperada; el servidor no debería depender de que el modelo recuerde limpiar recursos.

Ejecuta dos flujos en paralelo, retrasa deliberadamente una lectura y deja expirar el lease de uno. La prueba pasa solo si cada flujo consume su propio mensaje y el agente antiguo recibe fence_mismatch. Ese escenario detecta carreras que un test secuencial nunca ve.

El patrón es pequeño: reservar, validar propiedad, consumir evidencia y liberar. Pero convierte una integración frágil en un componente que los agentes pueden usar con límites claros. En la automatización con email, la confiabilidad empieza antes de leer el primer mensaje: empieza cuando una ejecución obtiene un dueño.