Separa preparar y ejecutar
Un agente puede preparar una tarea, un pedido o una respuesta sin enviarlos todavía. Define qué estado es un borrador y qué acción lo vuelve efectivo. El usuario debe ver destinatario, importe o cambio propuesto antes de una confirmación relevante. Una aprobación genérica no explica qué operación concreta se realizará.
Clasifica las consecuencias
Distingue lectura, cambios reversibles y operaciones con efectos externos. Define límites de importe, volumen y destinatarios cuando proceda. Las decisiones que afecten dinero, permisos o clientes merecen controles explícitos. Empieza por un proceso limitado y amplía únicamente cuando los registros y las pruebas permitan evaluar su funcionamiento.
Gestiona incertidumbre y repetición
Si una herramienta no responde, el agente debe distinguir fallo de resultado desconocido. Antes de reintentar, comprueba si la operación ya ocurrió. Registra identificadores y estados verificables. Diseña una salida hacia una persona cuando los sistemas discrepan; inventar una confirmación satisfactoria oculta el problema y dificulta recuperarlo.
Prueba el proceso completo
Ensaya permisos insuficientes, datos incompletos, aprobación rechazada y caída de un sistema. Comprueba que el agente se detiene en el lugar correcto y deja una explicación útil. Define quién puede desactivarlo y cómo continúan las tareas manualmente. El objetivo es una automatización operable, no solo una demostración sin errores.
Ejemplo: preparar una reposición
En un escenario ficticio, el agente detecta una necesidad de 120 unidades a partir de una regla de inventario previamente acordada. Prepara un borrador con artículo, cantidad, proveedor propuesto, fuente y fecha del dato. Si falta el precio vigente o el proveedor no está autorizado, no inventa la información ni envía el pedido. Solicita completar o revisar el borrador. Cuando existe información suficiente, muestra el efecto exacto y requiere la aprobación configurada. Después de ejecutar, conserva la referencia devuelta por el sistema y diferencia “creado”, “rechazado” y “resultado desconocido”. La detección de una necesidad no constituye por sí misma autorización para gastar.
Criterios para permitir acciones reales
Comprueba que una aprobación se aplica a una versión concreta del borrador y deja de ser válida si cambian datos relevantes. Verifica que un usuario sin permiso no puede aprobar, que el rechazo impide ejecutar y que repetir la petición no duplica la operación. Ensaya datos externos que intenten cambiar las instrucciones y confirma que no conceden nuevas facultades. Define un mecanismo de parada y un propietario de incidencias. El registro debe permitir reconstruir qué se propuso, quién autorizó, qué herramienta actuó y cuál fue el resultado observado. Prueba primero con sistemas de ensayo y datos que no afecten pedidos reales.
Puntos clave
- Una buena aprobación muestra la acción concreta y sus consecuencias.