El verdadero SLO de un agente es cuánto tarda la organización en detectar una desviación y contenerla

La tasa de éxito no cuenta toda la historia. Un agente puede completar 99 de 100 tareas y aun así ser peligroso si el único fallo tarda horas en detectarse. En sistemas autónomos, la seguridad necesita métricas de tiempo, no solo porcentajes. El marco de AWS insiste en detección y respuesta continuas porque el comportamiento agentic puede cambiar a medida que interactúa con herramientas y datos. Eso sugiere un SLO práctico: cuánto tarda el sistema en reconocer una desviación relevante, limitar el radio de impacto y devolver la operación a un estado conocido.

Primero hay que definir qué es desviación. No todo comportamiento inesperado es un incidente. Un agente creativo puede escoger una ruta distinta y seguir cumpliendo el contrato. La señal aparece cuando rompe una frontera: usa una tool no autorizada, consume más presupuesto del permitido, intenta enviar información a un destino incorrecto, repite una acción irreversible o genera una secuencia incompatible con el run. Convertir esas condiciones en eventos permite distinguir variabilidad útil de comportamiento que necesita contención. Sin definición previa, la organización termina juzgando incidentes después de conocer el resultado.

El reloj empieza cuando ocurre la primera señal. Mide tiempo hasta detección, tiempo hasta contención y tiempo hasta recuperación. La primera cifra muestra observabilidad; la segunda, capacidad defensiva; la tercera, resiliencia operacional. Un workflow puede detectar rápido y aun quedar detenido durante horas porque no sabe cómo recuperar el artefacto correcto. Por eso el SLO completo necesita cerrar el ciclo. La recuperación también debe comprobar que el destino volvió al estado esperado, no simplemente registrar que alguien ejecutó un comando de reparación.

La automatización de respuesta necesita niveles. Contener una credencial temporal o detener una ejecución puede ser automático cuando la condición es inequívoca. Otras situaciones necesitan juicio: una campaña, una transferencia o un mensaje externo puede tener contexto de negocio difícil de codificar. La organización debería clasificar respuestas por reversibilidad e impacto. Esa jerarquía evita dos extremos: sistemas que nunca reaccionan sin una persona y sistemas que convierten una falsa alarma en un daño automático. La velocidad es útil cuando la regla de contención está diseñada antes del incidente.

La evidencia convierte el SLO en aprendizaje. Cada run que se desvía debería conservar la secuencia mínima: evento inicial, señal detectada, acción de contención, estado final y tiempo de cada etapa. Con varios casos, aparecen patrones. Tal vez una tool concentra incidentes; quizá una integración tarda demasiado en confirmar cambios; quizá la mayoría de fallos proviene de referencias de archivo y no del razonamiento. Esa información permite invertir donde se reduce más riesgo. La observabilidad deja de ser un panel y se convierte en un backlog de ingeniería basado en efectos reales.

Aplicado a Goatify, esto cambia la definición de confiabilidad. No prometemos que un agente nunca falle; prometemos que el sistema puede detectar determinados fallos, limitar consecuencias y recuperar sin duplicar acciones. Para NewsDesk, por ejemplo, una publicación no termina con updatefile; termina cuando el vivo descargado coincide y existe backup. El mismo patrón puede aplicarse a Meta, CRM o navegador. Un SLO de detección y recuperación es más honesto y útil que una promesa abstracta de autonomía perfecta. 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.