LLMs: runbooks de email que no se rompen

Cuando un agente LLM dispara un correo dentro de un workflow, la parte vistosa es el texto. La parte que de verdad decide si el sistema aguanta producción es el runbook. Si el equipo no sabe qué evento abrió el flujo, qué snapshot usó el agente y qué evidencia debe quedar al final, cada retry empieza a sentirse como una apuesta. He visto pipelines así: parecen elegantes en demo, pero en la tercera incidencia ya nadie entiende qué pasó primero y qué fue un efecto secundario.

Mi regla es bastante aburrida, y por eso funciona. El correo no se diseña como salida creativa; se diseña como una operación con bordes claros. El modelo redacta dentro de esos bordes, no los inventa. Esa diferencia baja mucho el ruido cuando toca revisar automatización, LLMs y approval flows al mismo tiempo.

El problema real no es redactar, es operar

Muchos equipos empiezan por el prompt y dejan para después la parte operativa. A corto plazo se siente rapido, pero luego aparecen tres fallos muy típicos:

• el retry recompone el mensaje con datos nuevos aunque el evento era el mismo
• la aprobación humana llega sobre una versión distinta del correo
• el log dice "email enviado" pero no deja claro qué decisión tomó el agente

Para mi, eso indica que falta un runbook y sobra improvisación. Un runbook util define entradas, checkpoints y salidas observables. Si no puedes dibujarlo en palabras en un minuto, el flujo aún esta demasiado suelto.

Esa idea no vive solo en IA. En SRE también funciona así: primero delimitas el evento, luego la evidencia y al final la acción. Por eso me gustó este enfoque de probar correos de handoff con trazabilidad, porque deja claro que el correo bueno no es solo el que llega, sino el que se puede explicar después.

Un runbook pequeño da mejores limites

El runbook mínimo que suelo pedir para correos generados por agentes incluye cinco piezas:

1. run_id para aislar la ejecución.
2. event_type para decir qué disparó el correo.
3. state_snapshot para congelar datos sensibles al retry.
4. delivery_policy para definir ventanas, destinatarios y fallback.
5. evidence_bundle para guardar request, render final y resultado.

En palabras, el diagrama sería algo así: el orquestador recibe un evento, congela un snapshot, llama al agente con un objetivo muy corto, el renderizador aplica reglas fijas y solo entonces el ejecutor manda el correo. Si un paso falla, el mismo bundle debe explicar en qué capa pasó. No hace falta una plataforma enorme; hace falta que cada capa tenga una responsabilidad un poco mas aburrida.

Un ejemplo pequeño:

{
  "run_id": "job_7842",
  "event_type": "approval_request",
  "state_snapshot": {
    "ticket_id": "OPS-221",
    "risk": "medium",
    "locale": "es"
  },
  "delivery_policy": {
    "timeout": "120s",
    "channel": "email"
  }
}

Ese JSON no intenta describir toda la empresa. Solo deja el flujo lo bastante cerrado para que un retry no improvise demasiado. En sistemas con agentes, ese detalle importa un monton, porque el problema no suele ser que el modelo escriba raro; el problema es que el sistema le deja cambiar cosas que debían estar fijas.

El diagrama en palabras para un flujo confiable

Si tuviera que explicarlo en una revisión de arquitectura, lo contaría así:

1. El productor del evento decide si el correo merece automatización.
2. El orquestador crea run_id y snapshot inmutable.
3. El agente redacta solo con el contexto aprobado.
4. Un validador comprueba asunto, CTA, destinatario y reglas de negocio.
5. El ejecutor entrega y guarda evidencia consultable.

La parte clave es separar decisión de ejecución. Cuando el agente también decide a quién mandar, cuánto esperar y qué hacer si no llega confirmación, el flujo se vuelve muy opaco. Prefiero que el runbook deje esos tradeoffs arriba, visibles y revisables.

Este patrón también se nota en frontend cuando un equipo trabaja reenvios de verificacion con menos friccion: el usuario no debería sentir que cada clic abre un universo nuevo. En backends con agentes pasa lo mismo. Si cada retry parece una operación distinta, el diseño está filtrando demasiada complejidad.

Donde meter una inbox temporal sin volverla el centro del sistema

Aquí entra una parte práctica. A veces necesitas generate throwaway email para validar renders, enlaces o aprobaciones sin tocar inboxes reales. Me parece razonable, pero con una condición: la inbox temporal debe ser herramienta de evidencia, no el corazón del diseño.

Yo la metería en la capa de ejecución, no en la lógica del agente. El agente decide qué mensaje debe existir; la tool de correo temporal solo da aislamiento, lectura y expiración. Si necesitas un proveedor para ese paso, algo tipo free temp email puede servir como pieza de sandbox. Lo importante no es el branding, sino que la consulta sea determinista, la limpieza sea predecible y la evidencia no se mezcle entre corridas.

También conviene cuidar el lenguaje del equipo. Cuando en tickets o scripts aparecen variantes raras como tamp mail com, casi siempre descubro otras señales de deuda: nombres flojos, ownership difuso o pasos manuales que nadie quiere documentar. No es el error principal, pero si suele venir acompañado de otros.

Un tradeoff real aquí es costo versus claridad:

• más metadata y TTL implican algo más de implementación
• menos improvisación reduce bastante el tiempo de debugging
• una tool más rígida limita demos rapidas, pero mejora operación diaria

Según el reporte State of DevOps, los equipos con mejores loops de feedback y delivery estable resuelven cambios con menos fricción operacional source. No es una estadística específica de email, claro, pero encaja bien con esta decisión: feedback útil depende de evidencia útil.

Checkpoints antes de automatizar mas

Antes de publicar un flujo así, reviso esta checklist:

1. ¿El agente recibe snapshot congelado y no consulta estado libremente?
2. ¿El ejecutor puede rechazar envíos si faltan campos críticos?
3. ¿La evidencia deja reconstruir la decisión final sin releer todo el sistema?
4. ¿Los retries reutilizan contexto cuando deben, en vez de reinventarlo?
5. ¿La inbox temporal tiene TTL, aislamiento y naming claro?

Si respondes "no" a dos o más puntos, yo no aceleraría la automatización todavía. Meter más features encima de un runbook flojo solo hace el bug más caro, y un poco mas vergonzoso cuando toca explicarlo.

Q&A

¿Hace falta guardar cada prompt completo?

No siempre. Muchas veces basta con prompt_version, snapshot y render final. Guardar demasiado texto puede crear más ruido que valor.

¿Conviene que el agente haga fallback por su cuenta?

Solo si el fallback está declarado en el runbook. Si no, terminas con decisiones invisibles que luego nadie recuerda bien.

¿Cuál es la mejora más barata para empezar?

Agregar run_id, snapshot inmutable y un bundle de evidencia por ejecución. No arregla todo, pero ordena muchisimo el sistema desde el día uno.