Cómo aislar emails de agentes LLM en flujos automatizados sin perder trazabilidad

#ai #automation #llm #testing

Cuando un agente LLM empieza a abrir tickets, disparar aprobaciones o enviar resúmenes por correo, el problema ya no es solo "si el prompt funciona". El sistema completo pasa a depender de tres capas distintas: decisión, ejecución y verificación. Si esas capas quedan pegadas, el equipo termina mirando una bandeja y adivinando qué hizo realmente el agente.

Ese patrón aparece mucho en workflows de Automation porque el correo parece el último paso, cuando en realidad es el primer lugar donde se ve el fallo. Un agente puede clasificar bien una solicitud y aun así mandar el mensaje al destinatario equivocado, repetir un envío o usar un enlace vencido. Ahi nace la necesidad de aislar pruebas y trazas, no solo prompts.

También influye algo bastante humano: cuando alguien del equipo busca temp mail mail o disposable mail address, casi nunca está buscando una herramienta "de growth". Está buscando una superficie limpia para observar el sistema. Quiere comprobar qué produjo el agente sin ruido de mensajes viejos, y eso es totalmente razonable.

Por qué este problema aparece cuando un LLM toca correo

En un flujo clásico, una API recibe un evento, lo pasa a una cola y un worker envía el email. Con un LLM en medio, aparece otra fase: una decisión probabilística que puede cambiar asunto, prioridad, template o incluso si el correo debe salir. Esa fase no es mala, pero sí obliga a separar responsabilidades con más cuidado.

Yo suelo pensarlo como un diagrama en palabras:

El evento de negocio entra.
Un componente determinista prepara contexto y reglas.
El LLM decide o redacta dentro de límites claros.
Un ejecutor transforma esa salida en un comando verificable.
El sistema de correo entrega el mensaje.
La prueba confirma contenido, destinatario y efecto final.

Si mezclas esos pasos en un solo test, el fallo se vuelve opaco. No sabes si el error está en el modelo, en la política de herramientas, en el worker o en la bandeja usada para validar. Por eso me gusta medir cada borde del flujo con un trace_id compartido desde el evento inicial hasta el clic final.

Un diseño de flujo que separa decision, envio y verificacion

El diseño más estable no intenta "testear la inteligencia" de una sola vez. Divide el sistema en contratos pequeños:

Contrato de entrada: qué datos puede usar el agente y qué acción está autorizado a pedir.
Contrato de ejecución: cómo se convierte esa acción en un envío de correo concreto.
Contrato de observabilidad: cómo enlazas logs, mensaje recibido y estado final del sistema.

En este punto ayuda mucho copiar buenas prácticas de guías cercanas, como probar emails transaccionales en FastAPI. El stack puede cambiar, pero la idea de fondo sigue igual: una bandeja por escenario, una intención por prueba y una forma simple de reconstruir la secuencia.

Para agentes LLM, yo dejaría el correo fuera del prompt libre. El modelo puede sugerir send_followup_email, pero no debería decidir directamente headers, destinatarios alternativos o políticas de reintento. Esa traducción tiene que vivir en código determinista. Suena menos "mágico", aunque en la practica baja bastante el riesgo operacional.

Una implementación minima puede verse así:

def handle_agent_action(action, trace_id):
    if action["type"] != "send_followup_email":
        return {"ok": False, "reason": "unsupported_action"}

    command = {
        "template": "followup_v2",
        "user_id": action["user_id"],
        "trace_id": trace_id,
    }
    return dispatch_email(command)

No resuelve todo, pero deja una frontera clara: el LLM propone, el sistema valida y el ejecutor envía. Ese pequeño detalle evita un monton de debugging confuso despues.

Qué observar para no confundir un fallo del agente con un fallo del correo

La observabilidad útil aquí no es enorme; solo tiene que unir los puntos correctos. Yo revisaría cuatro señales:

La decisión generada por el agente y el contexto que la produjo.
El comando final que se entregó al ejecutor de correo.
El mensaje recibido en una bandeja aislada.
El efecto final tras abrir el enlace o confirmar la acción.

Cuando falta una de esas piezas, el equipo se inventa explicaciones. "Seguro fue el modelo". "Seguro fue el proveedor". A veces sí, pero muchas veces es una condición de carrera o una bandeja compartida. En entornos donde hay varios flujos de alta, renovación o trial, el ruido se parece bastante a lo que se cuenta en estas pruebas de onboarding en SaaS: si una bandeja recibe mensajes de varios escenarios, la confianza del test cae rapido.

También conviene registrar términos y atajos que usa el equipo en tickets o runbooks. He visto notas con tepm mail com o temp mailid escritas al vuelo. No es grave, pero suele indicar que la operación diaria depende más de memoria informal que de un procedimiento repetible. Cuando el sistema crece, eso te pasa factura.

Si quieres una validación más fuerte, añade un paso que compare la acción pedida por el agente con la acción realmente ejecutada. Si el modelo propuso "recordatorio de pago" y terminó saliendo "bienvenida", ya encontraste la zona del fallo sin mirar diez dashboards.

Tradeoffs y checklist antes de meterlo en produccion

Separar contratos agrega algo de fricción. Hay más logs, más ids y un poco más de trabajo de integración. Pero ese costo compra algo muy valioso: capacidad de explicar por qué un correo salió, no salió o salió mal. Para sistemas con LLMs, esa explicabilidad es casi parte del producto, aunque a veces no lo parezca.

Yo evaluaría estos tradeoffs antes de subir el flujo:

Más control determinista reduce libertad del agente, pero mejora auditoría.
Bandejas aisladas por escenario cuestan algo más de operación, pero bajan falsos positivos.
Reintentos automáticos ayudan a entrega, pero pueden esconder duplicados si no hay idempotencia.
Tests end to end son más lentos, pero detectan errores que un mock nunca va a mostrar.

Checklist corto:

Cada ejecución tiene trace_id propio.
El LLM solo puede pedir acciones dentro de un esquema valido.
El ejecutor de correo revalida destinatario, template y contexto.
La bandeja de prueba pertenece a un solo escenario.
El clic final confirma el cambio de estado esperado.
Los logs permiten seguir el caso sin adivinar demasiado.

No hace falta perseguir perfección total desde el día uno. Hace falta que el equipo pueda repetir el flujo mañana, entender qué pasó y corregirlo sin drama. Ese punto, aunque suene simple, ya separa un experimento bonito de una automatización util.

Preguntas frecuentes

¿Debo dejar que el LLM redacte el cuerpo completo del email?

Depende del riesgo. Para correos sensibles, prefiero que el modelo rellene bloques acotados y que el template principal siga en código o en un CMS controlado.

¿Qué pruebo primero si el agente "hizo todo bien" pero el usuario no recibió lo esperado?

Primero compararía la acción propuesta con el comando realmente ejecutado. Luego revisaría la bandeja aislada y el enlace final. Muchas veces el problema está en esa traducción intermedia.

¿Necesito pruebas reales si ya tengo unit tests del prompt y del worker?

Sí. Los unit tests sirven, pero no capturan del todo la cadena completa entre decisión, envío y verificación. En sistemas con LLMs, ese borde entre componentes es justo donde se esconden varios fallos raros.