Tu agente de IA no se cae, se desvia: SLOs de razonamiento para agentes de Bedrock AgentCore
Pusiste un agente de IA en produccion. Responde bien en las demos. Pero un martes cualquiera empieza a tardar el triple, a llamar a la herramienta equivocada, o a gastar tokens en un loop que nadie ve. Tus metricas de siempre (CPU, memoria, errores HTTP) estan todas en verde. El agente no se cayo, se desvio. Y ahi esta el problema: un agente falla en el razonamiento, no en la infraestructura.
La misma disciplina, una carga distinta
Si seguiste esta serie, ya tienes el metodo. Eliges la senal correcta (no promedies lo que deberias percentilar). La conviertes en un objetivo con presupuesto de error. Organizas el dashboard por lo que siente el usuario, no por servicio. Y cuando el presupuesto se quema rapido, tienes un runbook.
Un agente de IA generativa no rompe ese metodo. Lo estira. La diferencia es donde vive la falla. Un servicio web falla con un error 500 y una alarma de CPU. Un agente sigue respondiendo, pero razona mal: elige mal la herramienta, entra en un bucle de reintentos, alucina, o duplica las llamadas al modelo por cada peticion. Nada de eso mueve una metrica de infraestructura. Por eso la senal correcta para un agente no es CPU ni latencia de red, es el razonamiento mismo.
Las senales del razonamiento son tus SLIs de agente
Un SLI es lo que mides porque refleja la experiencia. Para un agente, las senales que importan viven en la traza de cada invocacion, no en el host. Estas son las que valen como SLI:
- Tokens por invocacion. Un salto sostenido casi siempre significa un bucle de reintentos o un prompt que se inflo. Es el SLI mas barato de vigilar y el que primero delata una desviacion.
- Llamadas a herramientas por invocacion. Mide si el agente esta pivotando de mas. Un agente sano resuelve en dos o tres llamadas lo que uno desviado intenta en doce.
- Latencia por paso. No la latencia total, sino la de cada paso del razonamiento. Ahi ves cual herramienta o cual llamada al modelo es la que se rompe.
- Tasa de invocaciones que completan el objetivo. La version de agente de una tasa de exito: cuantas invocaciones terminaron la tarea sin intervencion.
La regla del primer peldano de esta serie aplica igual: promediar estos numeros los arruina. El promedio de tokens por invocacion se ve estable mientras el percentil 99 se dispara por los agentes que entraron en bucle. Percentila el razonamiento igual que percentilas la latencia.
El presupuesto de comportamiento
Aqui esta la pieza que hace operable todo lo anterior, y es el mismo presupuesto de error de fiabilidad apuntado al comportamiento del agente.
Defines un objetivo sobre una senal de razonamiento. Por ejemplo: el 95 por ciento de las invocaciones deben resolverse en 5 llamadas a herramientas o menos. Ese 5 por ciento restante es tu presupuesto de comportamiento. Mientras te quede presupuesto, el agente se comporta dentro de lo esperado y sigues iterando. Cuando lo quemas, algo cambio (un despliegue, un prompt nuevo, datos de entrada distintos) y la prioridad pasa de agregar features a entender la desviacion.
Es exactamente el mecanismo del Blog 2 de esta serie, solo que la unidad no es tiempo de inactividad sino comportamiento fuera de rango. Y como es un presupuesto, tiene burn rate: que tan rapido lo estas gastando. Un salto abrupto en el burn rate es un despliegue que rompio el prompt o cambio una herramienta. Una subida lenta es deriva gradual a medida que cambian los datos que recibe el agente.
La vista por filas, aplicada al agente
El patron de dashboard por filas del Blog 4 aplica sin cambios. De lo mas abstracto arriba a lo mas detallado abajo:
- Fila 1, salud del agente. Latencia de extremo a extremo por invocacion, tasa de error, invocaciones por minuto. Responde: esta respondiendo y a que velocidad.
- Fila 2, SLIs del razonamiento. Tokens por invocacion, llamadas a herramientas por invocacion, latencia por paso. Los indicadores que la infraestructura no te da.
- Fila 3, presupuesto de comportamiento. Cuanto presupuesto te queda contra tu objetivo. La fila que te dice si iteras o si frenas a investigar.
- Fila 4, detalle por traza. La invocacion concreta, span por span: que herramienta, cuanto tardo, que devolvio. Donde bajas a investigar la que se rompio.
Burn rate y runbook
El dashboard muestra el estado; el runbook define la respuesta, igual que en el Blog 5. Con la telemetria del agente en CloudWatch Logs, un Log Alarm sobre una consulta de Logs Insights evalua las senales directamente: alarma cuando el promedio de llamadas a herramientas por invocacion supera tu umbral en una ventana, o cuando los tokens por invocacion se disparan. El burn rate te da la severidad y la severidad te da la respuesta:
- Burn rapido (un despliegue disparo la desviacion en muchas invocaciones a la vez): revierte o congela el cambio, es el equivalente a paginar.
- Burn lento (deriva gradual): investiga en horario habil que esta cambiando en los datos de entrada.
El mismo bucle senal-objetivo-runbook que usaste para latencia, ahora para razonamiento.
Lo minimo para instrumentar (referencia rapida)
La telemetria de servicio de Amazon Bedrock AgentCore llega sin esfuerzo: metricas integradas de runtime, memory, gateway, built-in tools, e identity aparecen en la pagina de generative AI observability de la consola de Amazon CloudWatch. Para las trazas y spans del razonamiento (los que alimentan tus SLIs de agente) necesitas tres cosas:
- Habilitar Amazon CloudWatch Transaction Search una sola vez. Sin esto no ves los spans del servicio.
- Instrumentar con el AWS Distro for OpenTelemetry (ADOT) SDK para exportar la telemetria a CloudWatch. Funciona con agentes dentro del runtime de AgentCore y con agentes fuera de el, y con frameworks de codigo abierto como Strands Agents, LangGraph, y CrewAI que emitan en formato OpenTelemetry (OTEL).
- Habilitar el rastreo al crear recursos de memory, porque sus spans no se emiten por defecto.
Un detalle de fechas que evita confusion: los agentes creados en o despues del 20 de julio de 2026 usan telemetria unificada por defecto (trazas, prompts, y registros en un unico log group por agente) y requieren ADOT 0.18; los creados antes usan telemetria dividida. Si operas agentes de distintas epocas, tus consultas tienen que contemplar los dos formatos hasta que migres los viejos. Para el rastreo entre componentes, AgentCore se integra con AWS X-Ray.
Lo que este enfoque no cubre (limitaciones honestas)
Instrumentar cuesta volumen. Las trazas y spans de un agente activo generan datos, y el volumen tiene costo de ingestion y de escaneo. Instrumenta las senales que vas a vigilar, no todo por defecto.
Observabilidad no es evaluacion de calidad. Ver tokens, llamadas y latencia te dice como se comporta el agente, no si sus respuestas son correctas. Un agente rapido y barato puede estar respondiendo mal. La calidad de las respuestas es otro problema, con otras herramientas.
El presupuesto de comportamiento es un proxy, no una verdad. Que un agente resuelva en pocas llamadas no garantiza que resolvio bien. El presupuesto detecta desviaciones de comportamiento, que es donde empiezan la mayoria de los problemas operativos, pero no reemplaza la revision de calidad.
Split contra unificado segun la edad del agente. Hasta que migres los agentes viejos, tus consultas y dashboards tienen que manejar los dos formatos de telemetria, y esa es una fuente real de confusion.
Conclusion
No necesitas una disciplina nueva para operar agentes de IA. Necesitas apuntar la que ya tienes a senales nuevas. El agente no se cae, se desvia, y la desviacion vive en el razonamiento: tokens, llamadas a herramientas, pasos. Eligelas como SLIs, ponles un presupuesto de comportamiento, monta la vista por filas, y ten el runbook para cuando el burn rate se dispare. El agente va a seguir tomando decisiones solo. Al menos vas a poder ver cuando empieza a tomarlas mal.
Recursos
- Observabilidad de IA generativa en CloudWatch - La vista dedicada para cargas de IA generativa
- Configurar observabilidad en Bedrock AgentCore - Metricas integradas e instrumentacion con ADOT
- Empezar con AgentCore Observability - Guia inicial de habilitacion
- Telemetry setup and delivery - Telemetria unificada vs dividida y ADOT 0.18
- AgentCore observabilidad unificada en un solo log group - El cambio de julio 2026
- Bedrock AgentCore y AWS X-Ray - Rastreo de solicitudes entre componentes
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article