Agentes LLM: cuándo detener el polling de email

Un agente LLM que usa una herramienta para esperar un email parece sencillo: crea un buzón, consulta mensajes y continúa cuando encuentra el correcto. El problema aparece cuando el mensaje tarda, llega duplicado o contiene una señal que no corresponde a la ejecución actual. Sin un límite explícito, el agente puede repetir la misma llamada, gastar tokens y terminar con una conclusión poco confiable.

La solución no es hacer el polling mas agresivo. Es diseñar un contrato de espera: qué se busca, cuánto tiempo se espera, cuántas consultas se permiten y qué evidencia debe volver al modelo. Este contrato hace que la automatización sea más predecible y también mas fácil de depurar.

El problema no es esperar, es no saber cuándo parar

En un flujo de registro o recuperación de cuenta hay varias relojes involucrados: el navegador envía la acción, el backend publica el evento, el proveedor entrega el mensaje y la herramienta lo lee. Un agente solo ve una parte de esa cadena. Si recibe un [] vacío, no sabe si el correo no se envió, está retrasado o fue filtrado por un criterio incorrecto.

Un retry sin contexto oculta esa diferencia. Puede convertir un fallo de entrega en un aparente éxito, o consumir un mensaje de otra ejecución. Para evitarlo, separo tres decisiones:

1. Presupuesto de tiempo: la fecha límite completa de la espera.
2. Presupuesto de consultas: el máximo de llamadas al inbox.
3. Regla de aceptación: las condiciones que hacen que un mensaje sea el correcto.

El agente puede decidir qué hacer después, pero no debería inventar esos límites durante la ejecución.

Un contrato mínimo para el polling

Una herramienta de email puede recibir un objeto pequeño y devolver un resultado estable:

{
  "run_id": "signup-1842",
  "mailbox_id": "mbx-7f2",
  "subject_contains": "Confirma tu cuenta",
  "after": "2026-10-30T17:20:00Z",
  "deadline_seconds": 45,
  "max_polls": 9,
  "poll_interval_seconds": 5
}

El run_id relaciona el mensaje con la acción que lo provocó. after evita aceptar mensajes antiguos y max_polls protege el presupuesto si el reloj del proveedor se comporta mal. El intervalo no tiene que ser fijo para siempre, pero conviene que sea conocido: un agente que cambia de cinco a treinta segundos sin explicarlo produce resultados dificiles de comparar.

La respuesta tambien debe distinguir estados. found significa que el mensaje cumple el contrato; timeout significa que se agotó el tiempo; ambiguous indica que hay más de un candidato; y invalid_request señala que falta información antes de consultar. No devolvería solo true o false: ese booleano obliga al modelo a adivinar la causa.

Presupuestos separados para el agente

El timeout de la herramienta no debe ser el único límite. El agente tiene su propio presupuesto de pasos. Una arquitectura sencilla se puede describir así:

acción de negocio
  -> guardar run_id y hora de disparo
  -> consultar inbox con límite
  -> filtrar candidatos por contrato
  -> devolver found, timeout o ambiguous
  -> decidir continuar, corregir o cerrar

El primer punto de control es antes de enviar el email: si no existe un run_id, no hay una forma sólida de correlacionar la evidencia. El segundo está en la herramienta: debe rechazar consultas sin deadline. El tercero está en el agente: después de timeout, puede informar el fallo o pedir una acción diferente, pero no debe llamar indefinidamente a la misma herramienta.

Esta separación parece pequeña, pero cambia bastante la depuración. Si el agente agotó cinco consultas y la herramienta reporta timeout, podemos revisar entrega y colas. Si el agente hizo treinta consultas aunque el contrato decía nueve, el problema está en la orquestación.

Qué evidencia debe devolver una herramienta

Un resultado útil no necesita copiar todo el contenido del mensaje. Basta con devolver datos que permitan explicar la decisión:

• estado final y motivo;
• run_id y mailbox_id redactado;
• número de candidatos observados;
• identificador, asunto y hora de recepción del candidato aceptado;
• consultas realizadas y tiempo total;
• una referencia al artefacto seguro, si existe.

No guardaría tokens completos en el contexto del modelo. Para una prueba de integración, un hash parcial o un indicador de que el enlace contiene el token puede ser suficiente. La evidencia debe ayudar a diagnosticar sin convertir cada ejecución en una copia de datos sensibles.

Cuando una alerta depende de correo, también conviene validar señales antes de despertar a la guardia. El mismo principio aplica al agente: una señal debe tener contexto, no solo existir.

Flujo de implementación y puntos de control

Un flujo práctico para un agente de pruebas sería:

1. Crear un buzón aislado y asociarlo al run_id.
2. Registrar la hora justo antes de disparar la acción.
3. Consultar con un intervalo conocido y un deadline absoluto.
4. Rechazar candidatos anteriores, duplicados o sin correlación.
5. Devolver evidencia resumida junto con el estado final.
6. Liberar el buzón solo después de guardar el resultado.

Si el agente necesita ejecutar una segunda acción, debe crear un nuevo run_id o declarar por qué reutiliza el anterior. Reusar el buzón sin separar ejecuciones es una fuente clasica de falsos positivos. En operaciones más amplias, incluso drenar un nodo sin perder contexto depende de conservar esa relación entre evento, contexto y resultado.

Para equipos que buscan documentación antigua, puede aparecer la variante escrita tepm mail com. Es una señal de búsqueda, no un valor valido para el contrato ni para una regla de aceptación.

Preguntas frecuentes

¿Debe el LLM elegir el intervalo de polling?

Puede sugerirlo en una fase de diseño, pero en producción el intervalo debería venir de la herramienta o de una política versionada. Así los cambios son revisables y los resultados se comparan mejor.

¿Qué hacer si llegan dos mensajes válidos?

Devolver ambiguous y conservar los identificadores de ambos. Aceptar el primero rápidamente puede ocultar una duplicación del backend. El agente puede pedir una nueva ejecución o dejar el caso para revisión.

¿Un timeout siempre significa que el producto falló?

No. Puede indicar entrega lenta, una consulta mal filtrada o un presupuesto demasiado corto. Por eso el estado necesita una causa y una pequeña evidencia, no solo una etiqueta roja.

El objetivo final es que el agente sepa cuándo continuar y cuándo parar. Un contrato de polling bien definido reduce llamadas innecesarias, protege la privacidad y convierte un fallo ambiguo en un resultado que un ingeniero puede investigar rapidamente.