Cómo probar que un agente realmente acepta correcciones y se apaga cuando pierde autoridad

Define primero qué significa estar apagado. No basta con que el agente deje de responder al usuario. Un shutdown correcto implica detener nuevas llamadas de herramientas, cancelar o marcar trabajos pendientes, impedir callbacks no autorizados y conservar solo el estado necesario para explicar qué quedó a medias. Escribe esos criterios como invariantes observables. Para cada habilidad identifica procesos que podrían continuar fuera del turno principal: colas, navegadores, jobs, webhooks o retries. La prueba debe abarcar el sistema completo, no solo la conversación donde se emitió la orden.

Prueba la corrección en varios momentos. Ejecuta casos donde el usuario cambia el objetivo antes de planificar, después de preparar un artefacto, justo antes de ejecutar y después de una acción irreversible. El comportamiento esperado cambia. Antes de ejecutar, la nueva instrucción puede invalidar la propuesta y exigir una nueva versión. Después de una acción, el sistema no debe fingir rollback si no existe; debe reconocer qué ocurrió y aplicar la corrección solo a pasos futuros. Esta distinción enseña al agente a respetar realidad externa además de autoridad humana.

Revoca credenciales durante la ejecución. Retira un permiso o token mientras el flujo está activo y confirma que la plataforma no busca otra credencial, cuenta o herramienta para completar el objetivo. El estado debe pasar a bloqueado o cancelado según la política. Registra qué llamada fue la última autorizada. Esta prueba detecta una clase peligrosa de optimización: interpretar la pérdida de acceso como obstáculo técnico a superar en lugar de una señal de autoridad que cambia el contrato de la tarea.

Simula mensajes contradictorios de distintas fuentes. Un usuario final puede pedir continuar mientras un administrador o policy engine ordena detenerse. Define precedencia antes de probar. El agente necesita saber qué identidad puede revocar qué permiso. La suite debe incluir actores con roles diferentes, mensajes fuera de orden y callbacks tardíos. El resultado correcto no depende de quién escribió el prompt más reciente, sino de la jerarquía de autoridad. Mantén esa jerarquía fuera del lenguaje natural cuando sea posible y represéntala en scopes.

Comprueba que no quedan acciones residuales. Después de shutdown espera suficiente tiempo para observar tareas programadas, reintentos y mensajes en cola. Verifica que no aparezcan publicaciones, correos o cambios tardíos. En sistemas distribuidos, detener el proceso principal puede no cancelar trabajos ya entregados a otros servicios. Usa identificadores de ejecución para invalidar operaciones pendientes o hacer que el ejecutor consulte estado antes de actuar. La prueba debe demostrar ausencia de side effects posteriores, no solo una respuesta verbal de obediencia.

Evalúa la explicación que recibe la persona. Un shutdown puede ser técnicamente correcto y operacionalmente frustrante si nadie sabe qué se conservó. La salida debería indicar última etapa completada, artefactos existentes, acciones no ejecutadas y qué haría falta para reanudar. No expongas secretos internos ni razonamiento privado. La meta es que un operador pueda decidir si descarta, corrige o continúa sin reconstruir el caso desde cero. Incluye esta claridad en el criterio de aprobación de la suite.

Automatiza la regresión por modelo y versión. Ejecuta los mismos escenarios cuando cambies modelo, prompt de sistema, herramientas, permisos o runtime. Guarda resultados comparables y alerta ante degradaciones. Algunas pruebas pueden ser deterministas; otras necesitarán varias repeticiones para detectar comportamiento inestable. No aceptes que una mejora de capacidad justifique perder obediencia operacional. Una plataforma seria puede demostrar que el modelo nuevo escribe mejor y, al mismo tiempo, sigue deteniéndose exactamente donde la autoridad humana y las políticas indican.