Agentes LLM: presupuesto de latencia para email

Un agente LLM puede llamar una herramienta de correo para crear una bandeja, esperar un mensaje de verificacion y extraer un codigo. La demo suele funcionar en pocos minutos. El problema aparece en produccion: el proveedor tarda, el modelo decide volver a preguntar y el flujo termina consumiendo tiempo y dinero sin una señal clara de fallo.

La solucion no es poner un timeout enorme. Es darle al agente un presupuesto de latencia y hacer que cada herramienta lo respete. En este contexto, un temporary email generator no es solo un servicio auxiliar: es una dependencia con tiempo de vida, limites y evidencia que el modelo debe poder entender.

El problema: un agente que espera sin presupuesto

Imagina este recorrido:

1. El agente crea una direccion temporal.
2. La aplicacion envia un correo de confirmacion.
3. El agente consulta la bandeja cada cierto tiempo.
4. Lee el mensaje y continua con la siguiente accion.

Si cada paso usa su propio timeout, el flujo completo puede exceder el limite de la tarea sin que nadie sepa donde se fue el tiempo. El agente ve un error generico y prueba otra vez. El segundo intento quizas crea otra bandeja, deja el primer correo huerfano y hace el diagnostico mas dificil.

Esto tambien ocurre en procesos internos que parecen muy pequeños, como validar un handoff en una guardia. Conviene separar la evidencia del correo de la accion principal, igual que cuando se quiere probar correos de handoff en una guardia SRE. La pregunta no es solamente si llego el mensaje, sino cuanto tiempo y cuantas consultas fueron necesarias.

Dibuja el recorrido antes de elegir el timeout

Antes de escribir prompts, hago un diagrama en palabras:

presupuesto total
  ├─ crear bandeja:       2 s
  ├─ disparar accion:     5 s
  ├─ observar mensajes:  35 s
  ├─ leer y validar:      3 s
  └─ margen de red:        5 s

Los numeros son un punto de partida, no una promesa del proveedor. Lo importante es que sumen el presupuesto de la tarea. Si la herramienta de polling recibe solo el tiempo restante, no puede quedarse esperando otros 60 segundos por accidente.

Una forma sencilla es transportar un deadline en cada llamada:

{
  "task_id": "signup-1842",
  "deadline_at": "2026-10-16T02:23:10Z",
  "attempt": 1,
  "mailbox_id": "mbx-7f2a"
}

El orquestador calcula el tiempo disponible. La herramienta lo limita a su propio maximo y devuelve una razon si no puede completar la accion. Asi el LLM recibe una señal util en lugar de una espera silenciosa.

Un contrato pequeño para la herramienta de email

Para un agente, las funciones de correo deben exponer estados simples. Un contrato minimo puede tener estas operaciones:

• create_mailbox(deadline): crea o reserva una bandeja y devuelve su identificador.
• wait_for_message(mailbox_id, after, deadline): observa solo mensajes posteriores al evento que disparo el correo.
• read_message(message_id, deadline): devuelve asunto, remitente y contenido necesario, no toda la bandeja.
• release_mailbox(mailbox_id): libera el recurso aunque la tarea falle.

Cada respuesta deberia incluir status, elapsed_ms, attempt y next_action. Por ejemplo, status: "not_found" es diferente de status: "provider_error". El primero puede justificar una consulta corta adicional; el segundo pide cambiar de ruta o terminar con diagnostico.

No hay que esconder todos los detalles al modelo. Un resumen como este es suficiente:

{
  "status": "not_found",
  "elapsed_ms": 18000,
  "observed_messages": 0,
  "remaining_ms": 12000,
  "next_action": "poll_once_or_stop"
}

Con ese contrato, el agente no necesita inventar una politica de espera. La arquitectura ya expresa la restriccion.

Polling, reintentos y evidencia

El polling fijo cada segundo parece inocente, pero puede saturar una API y hace dificil comparar ejecuciones. Prefiero una secuencia con backoff corto, por ejemplo 1, 2, 4, 6 y 8 segundos, siempre recortada por el deadline. Si el correo llega despues, se registra como tardio en vez de convertirlo en una espera infinita.

Tambien guardaria un recibo por cada consulta:

• identificador de la bandeja y de la tarea;
• instante del evento que origino el correo;
• filtros usados para encontrar el mensaje;
• cantidad de mensajes observados;
• razon de cada reintento;
• tiempo restante al terminar.

En flujos de onboarding, esta disciplina combina bien con una estrategia para probar emails sin ensuciar las metricas. Si el mismo agente prueba muchos escenarios, el recibo evita mezclar una bandeja vieja con la ejecucion actual.

Para ambientes de QA, una direccion temporal puede ser util para generar un correo desechable (generate throwaway email) y aislar una prueba. No la trataria como identidad real ni guardaria su contenido mas tiempo del necesario. En logs de equipos distintos aparecen busquedas como tamp mail com o temp org mail; son pistas de la intencion de prueba, no nombres de una API que el agente deba adivinar.

Q&A: decisiones practicas

¿El LLM debe elegir el timeout?

Puede elegir entre presupuestos predefinidos, pero no deberia inventar milisegundos sin limites. El servidor debe aplicar el maximo y devolver el tiempo restante.

¿Conviene reintentar cuando no llega el correo?

Solo si queda tiempo y el recibo muestra que la consulta fue valida. Crear una segunda bandeja automaticamente suele perder la relacion entre la accion original y el mensaje esperado.

¿Que pasa si el proveedor responde lento?

Devuelve provider_timeout y conserva la evidencia. El agente puede explicar que la dependencia excedio el presupuesto, en vez de afirmar que el usuario no recibio nada.

¿Como empiezo en un proyecto existente?

Primero instrumenta elapsed_ms, remaining_ms y mailbox_id. Luego añade el deadline y separa not_found de los errores del proveedor. Son cambios pequeños, pero hacen visible el coste real antes de rediseñar toda la automatizacion.

Un agente LLM confiable no es el que espera mas. Es el que sabe cuanto puede esperar, que evidencia debe conservar y cuando parar. Ese contrato convierte una herramienta de email en una pieza predecible del sistema, no en una caja negra con reintentos.