Agentes LLM: una cola de evidencia para email

Description and use

Implementing an evidence queue separates the LLM's decision from the actual email action, providing idempotency, traceability, and safe retry handling.

Problem

Los agentes LLM que envían correos pueden dejar incertidumbre sobre si la acción se completó, ya que fallos en la herramienta, el proveedor o la red pueden ocurrir después de la decisión del modelo.

Outcome

La implementación de una cola de evidencia permite distinguir entre acciones pendientes y completadas, evita duplicados por reintentos y mejora la trazabilidad y la observabilidad del flujo de correo.

Workflow

• 1. El agente recibe la instrucción y decide la acción.
• 2. Se genera una intención y una acción normalizada con un idempotency_key estable.
• 3. Se envía la acción al adaptador de email y se registra en la tabla email_steps con estado "pending".
• 4. El worker procesa la fila, incrementa attempts y llama al adaptador.
• 5. Al recibir la respuesta, se actualiza el estado a "accepted", "rejected" o "unknown" y se guarda provider_message_id.
• 6. Si el estado es "accepted", no se reintenta; si es "retryable" se programa otro intento con backoff; si es "unknown" se marca para revisión manual.

Evidence

Un agente LLM que puede leer una bandeja y enviar un correo parece un flujo sencillo: recibe una instrucción, llama una herramienta y responde.

Source

Si solo guardamos el texto final del agente, no podemos distinguir una acción pendiente de una acción ya aplicada.

Source

La solución que estoy usando como referencia es una cola de evidencia: cada paso produce una intención, una acción y un recibo verificable.

Source

El worker reclama una fila, incrementa attempts y llama al adaptador. Solo marca accepted cuando recibe un resultado que pueda guardar.

Source

Los estados pending, retryable, accepted, rejected y unknown son más útiles que un booleano: muestran el camino que aún necesita resolución.

Source