Contratos de inbox para agentes LLM

Cuando un agente LLM dispara correo, el bug molesto no suele estar en el texto final. Suele estar en la evidencia: una inbox compartida, un assert flojo o una corrida que pisa a otra. En varios equipos he visto la misma escena, mas o menos: el agente "parece" correcto, pero nadie puede probar qué acción produjo qué mensaje. Sin ese borde claro, la automatización se vuelve cara de operar.

Mi forma de pensarlo es bastante simple. El sistema no termina en el prompt ni en la tool call. Termina cuando puedes mirar una corrida concreta, abrir su evidencia y decidir en pocos minutos si el flujo está sano o no. Ahí es donde un contrato de inbox bien definido hace diferencia real para LLMs y Automatización.

El contrato correcto empieza en la inbox

Si la herramienta de correo solo recibe to, subject y body, el agente queda con demasiada libertad y el equipo con muy poca trazabilidad. Prefiero modelar una inbox de prueba como una pieza de arquitectura, no como un detalle de QA.

Ese contrato mínimo debería incluir:

• run_id
• scenario_key
• recipient_alias
• expected_template
• assertion_window
• evidence_retention

Eso evita una clase entera de fallos raros. Dos corridas pueden usar el mismo backend, incluso la misma feature flag, pero nunca deberían competir por la misma bandeja lógica. Si ya estás trabajando en versionar acciones de correo en agentes, este paso completa la frontera: acción cerrada por un lado, evidencia aislada por el otro.

También ordena el vocabulario del equipo. Mucha gente mezcla términos como inbox temporal, correo de usar y tirar o incluso cosas medio rotas que quedan en tickets, como tepm mail com. No es grave por sí mismo, pero muestra que el flujo aún depende más del contexto humano que de un contrato reproducible.

Qué campos hacen la evidencia reutilizable

Para mí, una prueba de correo útil necesita responder cuatro preguntas sin leer veinte logs:

1. ¿Qué acción pidió el agente?
2. ¿Qué inbox quedó reservada para esa corrida?
3. ¿Qué mensaje terminó llegando?
4. ¿Qué aserción de negocio se validó al final?

Un payload pequeño puede cubrirlo:

{
  "run_id": "eval_2026_07_21_001",
  "scenario_key": "signup_magic_link",
  "recipient_alias": "signup-eval-001",
  "expected_template": "magic_link_v3",
  "assertion_window": "120s",
  "evidence_retention": "24h"
}

Con algo así, el ejecutor deja de "interpretar" y pasa a validar. Además, puedes separar mejor qué vive en la capa del agente y qué vive en la capa de la tool. El agente decide el caso; la tool garantiza aislamiento, consulta y retención. Ese reparto suele bajar bastante el tiempo de debugging, y va en la misma línea que reportes de entrega como DORA, que asocian feedback claro y ciclos cortos con mejor desempeño operativo source.

Un flujo simple para equipos pequeños

No hace falta montar una plataforma gigante. Para un equipo chico, yo empezaría así:

1. La corrida crea un run_id y reserva una inbox lógica única.
2. El agente elige una acción cerrada y una ventana de espera explícita.
3. El ejecutor persiste request, metadata y resultado en el mismo sobre de evidencia.
4. La prueba consulta solo esa inbox y valida contenido, destinatario y efecto final.
5. La limpieza expira la evidencia sin tocar corridas activas.

Ese patrón también viene bien cuando necesitas aislar emails por branch en FastAPI. Branches, retries y escenarios manuales tienden a contaminarse entre sí si comparten naming o retention policy.

Cuando necesito un enlace contextual para explicar el tipo de proveedor que encaja aquí, suelo hablar de servicios tipo temp mail com. No por el marketing, sino porque la idea de fondo importa: inbox efímera, consulta determinista y eliminación predecible. Si el proveedor no te da eso, la herramienta puede verse comoda al inicio, pero luego castiga cada suite paralela.

Tradeoffs y checkpoints antes de publicarlo

Este diseño mete más estructura, sí. Pero casi siempre paga solo:

• Más ids y metadata, pero menos ambigüedad.
• Un setup un poco más estricto, pero corridas mucho mas auditables.
• Menos magia en demos, pero mejor operación diaria.

Mis checkpoints antes de darlo por bueno son estos:

• Cada corrida reserva una inbox única o un alias exclusivo.
• La tool rechaza lecturas sin run_id o scenario_key.
• La evidencia tiene TTL y dueño claro.
• La aserción final valida negocio, no solo "llegó un correo".
• El historial permite reconstruir fallos sin reejecutar todo.

Si uno de esos puntos falta, el sistema aún depende demasiado de memoria humana. Y eso no escala, especialmente cuando varios agentes o pipelines corren a la vez.

Preguntas frecuentes

¿Cuándo conviene una inbox por escenario y no por usuario?

Cuando estás probando concurrencia, retries o ramas paralelas. Por usuario suele ser demasiado amplio y genera cruces dificiles de explicar después.

¿Hace falta guardar el prompt completo?

No siempre. Normalmente basta con la acción elegida, los ids de contexto y el resultado normalizado de la tool. Guardar más ruido no necesariamente ayuda.

¿Esto aplica fuera de LLMs?

Sí. La diferencia es que con agentes el beneficio aparece antes, porque la frontera entre decisión y ejecución necesita ser aburrida, estable y muy legible.