Muchos equipos que integran LLMs con correo se obsesionan con el prompt y dejan medio borroso el contrato de ejecución. En mi experiencia, el fallo repetido no suele ser "el modelo escribió algo raro". Suele ser más simple y más molesto: una acción poco definida, una plantilla sin versión clara o un ejecutor que acepta demasiadas variantes. Ahí es donde la automatización se vuelve dificil de operar y peor de depurar.
Cuando además hay pruebas en staging, la falta de contrato rompe dos cosas a la vez: el envío real y la evidencia. He visto equipos discutir media hora si el agente pidió el email correcto, cuando el problema era que send_email aceptaba payloads con campos opcionales demasiado libres. Ese tipo de diseño parece flexible al inicio, pero luego cobra factura.
El problema no es el prompt, es la acción
Para mí, el patrón más sano es describir el sistema como un diagrama en palabras: evento de producto, reducción de contexto, decisión del agente, acción versionada, ejecutor determinista y verificación final. Si una capa puede reinventar a la otra, ya tienes una fuente de ambigüedad.
En vez de dejar que el agente "explique" el correo, prefiero que solo seleccione una acción cerrada, por ejemplo:
