Los flujos con LLMs suelen fallar en un punto poco glamuroso: el reintento. Una llamada tarda demasiado, el worker pierde la conexión o el modelo devuelve una tool call válida pero la respuesta no llega al orquestador. Si el sistema vuelve a ejecutar todo sin contexto, puede duplicar correos, crear registros repetidos o avanzar una etapa que todavía no tiene evidencia.
La solución no es pedirle al modelo que “tenga más cuidado”. Es diseñar límites claros alrededor de él. En mi experiencia con automatización, un flujo fiable se parece más a una pequeña máquina de estados que a una conversación lineal.
El problema: un reintento no es una excepción
Imagina este recorrido: recibir datos, validar un correo, crear una cuenta y enviar una notificación. El tercer paso termina en el proveedor, pero el proceso se cae antes de guardar el resultado. En el siguiente intento, repetir la creación puede producir un duplicado.
En un diagrama de palabras:
entrada -> decisión del LLM -> tool -> recibo durable -> siguiente estado
El recibo durable es la pieza importante. Sin él, el sistema solo conoce lo que cree que ocurrió.
El contrato mínimo de una tool
Cada herramienta debería declarar cuatro cosas: un identificador idempotente, sus entradas normalizadas, los efectos que puede producir y el formato de su recibo. Por ejemplo:
{
"tool": "crear_cuenta",
"idempotency_key": "signup:8f21",
"input": {"email": "persona@example.com"},
"expected_receipt": {"status": "created|already_exists", "account_id": "string"}
}
La clave debe venir del trabajo de negocio, no de un timestamp generado en cada reintento. Si la misma operación llega otra vez, la tool responde con el resultado conocido o con un estado que permita reconciliarla.
También conviene separar decisión y efecto. El LLM puede proponer crear_cuenta, pero un componente determinista valida permisos, esquema y límites antes de ejecutarla. Esto hace la Prompt Engineering menos teatral y más verificable.
Una arquitectura con recibos
Usa una tabla o almacén pequeño de ejecuciones con run_id, step_id, status, attempt, input_hash y receipt. El orquestador consulta ese registro antes de llamar a una tool. Si existe un recibo exitoso, continúa. Si existe un fallo transitorio, reintenta con la misma clave. Si el estado es ambiguo, pausa para reconciliación.
Este patrón es útil tanto si construyes un agente que usa un temp email generator para pruebas como si automatizas un proceso interno sensible. Incluso una búsqueda informal como temp org mail puede terminar en entradas inconsistentes si no hay una frontera de validación.
Para tareas con correo, registra además el proveedor, el mensaje lógico y la confirmación de entrega. Los límites de polling importan: esta guía sobre polling de inbox con límites sanos explica una parte concreta del problema. Y hacer visible el progreso evita que un operador adivine si la tarea sigue viva; véase estado visible para correos asíncronos.
Implementación por checkpoints
Empieza con un solo flujo y tres checkpoints:
-
Antes de la tool: valida esquema, autorización y
idempotency_key. - Después del efecto: persiste el recibo antes de informar éxito al modelo.
- Al reanudar: carga el último estado y ejecuta solo el paso pendiente.
No guardes únicamente el texto final. Conserva una versión reducida de la entrada, la decisión estructurada y los errores clasificados. Así puedes reproducir el razonamiento operativo sin almacenar datos innecesarios.
Qué medir y qué no
Mide reintentos por paso, operaciones ambiguas, tiempo hasta reconciliación y porcentaje de recibos reutilizados. El número bruto de tokens dice poco sobre la fiabilidad del flujo. Tampoco conviertas cada respuesta del modelo en una métrica de calidad: una respuesta bien escrita puede haber ejecutado una tool incorrecta.
Checklist final
- ¿La misma operación usa la misma clave en cada intento?
- ¿Una tool puede devolver
already_existssin romper el flujo? - ¿Se persiste un recibo antes de declarar éxito?
- ¿Los efectos están separados de la decisión del LLM?
- ¿Existe un estado explícito para casos ambiguos?
- ¿Puedes reanudar desde el último checkpoint?
La automatización madura cuando un fallo deja pistas, no misterio. Diseña primero el contrato y los recibos; después ajusta el prompt. El modelo será más útil porque el sistema ya sabe qué significa avanzar.
Top comments (0)