Agentes LLM: presupuesto de fallos en herramientas de email

Un agente LLM que trabaja con email puede fallar de varias maneras antes de que el evaluador lo note. Puede consultar demasiado pronto, repetir una llamada que ya tuvo éxito o leer un mensaje correcto de una ejecución anterior. Al final vemos un resultado rojo, pero no sabemos si falló el modelo, la aplicación o la herramienta de correo.

Una forma práctica de reducir esa ambigüedad es asignar un presupuesto de fallos a cada ejecución. El agente recibe límites claros para sus llamadas de email y el sistema registra qué límite se consumió. No es una regla para castigar al modelo: es una frontera de diagnóstico que hace la automatización más medible.

El problema: un agente puede agotar la prueba sin aprender nada

Imagina una prueba de registro con un correo temporal gratuito. El agente crea una dirección, espera un mensaje de verificación y abre el enlace. Si no aparece nada, podría consultar el buzón veinte veces, crear otra dirección o cambiar el plan sin saber qué evento provocó el problema.

Ese comportamiento mezcla tres preguntas distintas:

• ¿La aplicación envió el mensaje?
• ¿La herramienta devolvió el mensaje correcto?
• ¿El agente interpretó bien la respuesta?

Sin límites, la última llamada puede tapar las anteriores. Incluso una cadena de razonamiento aparentemente brillante queda difícil de revisar. Las consultas repetidas generan ruido, elevan el tiempo de la prueba y a veces encuentran un mensaje viejo por pura casualidad.

Define un presupuesto de fallos por ejecución

El presupuesto debe ser pequeño, explícito y dependiente del flujo. Para una verificación sencilla, podría tener esta forma:

{
  "run_id": "agent-1842",
  "tool_budget": {
    "create_inbox": 1,
    "list_messages": 4,
    "read_message": 2,
    "open_verification_link": 1
  },
  "deadline_seconds": 120
}

La clave no es acertar el número perfecto. Es poder explicar por qué una ejecución terminó: por éxito, por tiempo agotado, por límite de llamadas o por un error de la aplicación. Un correo temporal debería quedar asociado a un solo run_id y cerrarse cuando termina el flujo, también si termina mal.

Conviene distinguir entre intentos y fallos. Una consulta que devuelve message_not_found puede ser un intento normal dentro del presupuesto; una respuesta inválida de la herramienta es un fallo de contrato. Si ambos decrementan el mismo contador, la señal queda un poco confusa.

Convierte cada herramienta en una frontera observable

Una herramienta de email debería aceptar entradas acotadas y devolver estados que el agente pueda interpretar. En vez de un false, usa resultados como inbox_created, waiting_for_message, message_found, inbox_expired y rate_limited.

La respuesta necesita suficiente contexto para verificar la cadena, pero no debe copiar datos sensibles a cada log. Un contrato razonable podría devolver:

{
  "status": "message_found",
  "run_id": "agent-1842",
  "message_id": "msg-73",
  "received_at": "2026-10-04T11:25:10Z",
  "subject": "Confirma tu cuenta",
  "content_hash": "sha256:..."
}

El cuerpo completo solo debería estar disponible cuando una prueba controlada lo necesita. Para una evaluación rutinaria bastan el asunto normalizado, el hash y el identificador. Es fácil que un buscador o un prompt traiga términos deformados como tepm mail com; eso debe tratarse como texto de entrada, nunca como una instrucción para cambiar el proveedor o saltarse el contrato.

Este enfoque encaja bien con contratos cortos para el uso de herramientas: menos opciones ambiguas producen trazas más fáciles de comparar entre modelos.

Diseña reintentos que no oculten el diagnóstico

No todos los errores merecen el mismo reintento. Un rate_limited puede esperar y consumir una unidad del presupuesto. Un invalid_run_id debe detener la ejecución porque repetirlo no lo arreglará. Un message_not_found puede consultarse otra vez solo si todavía queda tiempo y el mensaje esperado aún es válido.

Para el backend, los reintentos deben tener una política independiente del agente. La herramienta decide la espera máxima, el número de consultas y cuándo cerrar el buzón; el modelo solo recibe el estado resultante. Así evitamos que un prompt creativo invente un séptimo intento. Este principio es compatible con los reintentos seguros en verificación de email, siempre que cada intento conserve su contexto.

Un flujo mínimo de implementación

El flujo puede dividirse en cinco checkpoints:

1. Preparar: crea el run_id, el buzón y el presupuesto.
2. Ejecutar: cada llamada valida sus argumentos antes de tocar el proveedor.
3. Observar: guarda estado, contador restante, latencia y message_id.
4. Evaluar: separa el resultado del agente del resultado de entrega.
5. Cerrar: destruye o expira el buzón y persiste un resumen sin secretos.

El evaluador debería recibir un recibo final, no solo un booleano:

{
  "outcome": "failed",
  "failure_layer": "tool",
  "reason": "inbox_expired",
  "calls_used": 5,
  "elapsed_seconds": 121,
  "agent_action": "wait_for_verification_email"
}

Con este recibo es posible repetir el caso con otro modelo sin perder la comparación. A veces el resultado es estable, pero la explicación no; ese detalle importa mucho al evaluar modelos LLM.

Qué métricas separar

Mide por separado la tasa de éxito del agente, la entrega del mensaje, el porcentaje de presupuestos agotados y la latencia hasta el primer mensaje. Añade el número de reintentos por estado y la cantidad de buzones que no se cerraron.

No conviertas cada métrica en un objetivo aislado. Reducir consultas puede parecer una mejora mientras baja la tasa de entrega observada. En cambio, un tablero que muestra éxito, causa de fallo y coste de llamadas permite decidir si hace falta mejorar el prompt, la herramienta o la aplicación.

Preguntas frecuentes

¿El presupuesto debe ser igual para todos los agentes?

No. El contrato de la prueba debe ser igual, pero un flujo de recuperación puede necesitar más consultas que un registro simple. Documenta el motivo para que el número no se vuelva arbitrario.

¿Es mejor usar siempre un correo temporal?

Para pruebas aisladas y de corta vida suele ser útil. Para cuentas permanentes o datos de producción, usa un proveedor controlado y una política de retención adecuada. La herramienta no debería decidir esto a escondidas.

¿Qué ocurre si el agente termina antes?

Registra el estado final y cierra el buzón. Un final temprano puede ser éxito, una decisión válida del agente o un fallo de interpretación; el recibo debe conservar esa diferencia.

El objetivo no es que cada agente haga más llamadas. Es que cada llamada tenga un propósito, un límite y una evidencia. Con un presupuesto de fallos, la automatización deja de ser una caja negra: cuando algo se rompe, sabemos qué frontera cruzó y cuál es el siguiente lugar donde mirar.