Cómo instrumentar un agente para detectar comportamiento anómalo antes de darle más autonomía

1. Escribe el comportamiento normal. Antes de buscar anomalías, define qué secuencia espera la habilidad. Incluye objetivo, herramientas permitidas, destinos autorizados, límites de tiempo y condición de éxito. No necesitas predecir cada paso interno; necesitas fronteras observables. Un publicador puede leer un archivo, escribir un destino específico y verificarlo. Si intenta otro destino o repite una mutación después de la verificación, ya existe una señal. El contrato normal sirve como referencia para distinguir flexibilidad útil de una desviación que merece atención.

2. Registra eventos pequeños y estructurados. Cada uso de herramienta debería producir nombre, timestamp, recurso, resultado y runKey. Añade costo o duración cuando sea relevante. Evita depender de logs narrativos largos que luego nadie puede comparar. Un evento estructurado permite construir reglas y estadísticas. También facilita responder quién actuó y sobre qué recurso. La observabilidad mejora cuando los campos son consistentes entre habilidades, porque un mismo panel puede mostrar publicación, navegador, correo o CRM sin inventar una taxonomía diferente para cada integración.

3. Define límites que puedan comprobarse. Presupuesto máximo, número de tool calls, dominios permitidos, cantidad de destinatarios o tamaño de archivo son ejemplos de fronteras medibles. El límite debe disparar una condición antes de que la ejecución acumule consecuencias. Si una tarea normal necesita cinco llamadas y lleva treinta, quizá existe un loop. Si un agente intenta escribir fuera del FileId configurado, detén la mutación. Los guardrails más útiles son simples, locales y vinculados a una acción concreta.

4. Separa observación de respuesta. Detectar un evento no significa decidir automáticamente la misma reacción para todo. Clasifica señales por severidad. Una referencia de archivo inválida puede pedir rematerialización; un destino inesperado puede detener el run; una desviación con impacto financiero puede escalar a una persona. Este mapa evita automatizar respuestas demasiado agresivas. También permite mejorar gradualmente: cuando una señal se vuelve bien entendida y repetible, puede pasar de revisión humana a contención automática.

5. Verifica recuperación. Después de contener, el sistema debe comprobar que el estado final es seguro. Detener una tool no basta si ya ocurrió una escritura parcial. Relee el destino, compara versión o confirma que no hubo efecto. Si el run puede continuar, reutiliza artefactos que ya fueron validados. Si no, termina con error explícito y siguiente acción. La recuperación es una etapa observable, no una frase de “se corrigió”. Esa evidencia es la que permite confiar en que el incidente realmente cerró.

6. Usa incidentes como pruebas de regresión. Cada desviación real debe convertirse en un caso reproducible. Si un BLOCKEDFILEREFERENCE interrumpe publicación, crea una prueba que confirme rematerialización y reintento sin regenerar contenido. Si una tool recibe un destino incorrecto, prueba que el guardrail detenga antes de escribir. La biblioteca de fallos conocidos aumenta la cobertura de seguridad más rápido que una política abstracta. Con el tiempo, la autonomía puede crecer porque cada nueva capacidad hereda un conjunto de límites ya demostrados. La disciplina útil consiste en convertir esa idea en una condición observable, con responsables claros y una evidencia que permita comprobar el resultado sin depender de una explicación posterior. En producción, esa diferencia importa porque una decisión que parece correcta en una demostración puede comportarse de otra manera cuando intervienen múltiples usuarios, sistemas, permisos y excepciones. La mejor implementación no busca añadir complejidad por sí misma, sino reducir incertidumbre y hacer que el siguiente paso sea comprensible para quienes operan, supervisan o reciben el servicio.