Objetivos de aprendizaje
- Distinguir retry de modelo, retry de tool y retry de workflow.
- Diseñar acciones idempotentes para pagos, emails, tickets y cambios de datos.
- Crear una tabla de ejecuciones que bloquee duplicados.
En cristiano: idempotencia. Es la propiedad de que repetir una operación con la misma clave no produzca efectos duplicados.
tabla_tool_executions:
idempotency_key: "invoice-email:cliente-42:2026-07"
tool: "send_email"
status: "completed"
result_id: "msg_abc123"
regla:
si existe completed con misma key:
devolver result_id anterior
no ejecutar tool otra vez
si existe running:
esperar o marcar conflicto
si falla:
guardar error y decidir retry con humanoPatrón seguro
- Genera una `idempotency_key` antes de llamar la tool.
- Registra `running` antes del efecto externo.
- Marca `completed` solo cuando el proveedor confirma.
- En retry, consulta la tabla antes de actuar.
- Para acciones irreversibles, añade aprobación humana.
Idea clave. Reintenta el sistema, no el razonamiento completo. Si la tool falló por red, reintenta la tool con la misma clave; no pidas al agente que “lo piense otra vez” desde cero.
Cuidado. “Exactly-once” real es difícil en sistemas distribuidos. En práctica educativa, busca “efecto externo una sola vez” mediante claves, registros y reconciliación.
Comprueba que funciona. Lista tus tools peligrosas: enviar email, cobrar, borrar, publicar, crear usuario, tocar CRM. Cada una necesita clave de idempotencia.
Guardar y reabrir el proyecto.
Cualquier tool con efecto externo debe poder responder: “¿ya hice esto antes?”.
Siguiente misión recomendada
Si has guardado la evidencia de esta lección, continúa con «Estado persistente». Si no, repite la comprobación antes de avanzar.