SLO y error budget en agentes: 4 SLIs, burn rápido/lento y política 50/100

La observabilidad mide. El SLO contrata. Sin contrato, un dashboard de Langfuse es un diario: útil para debug, inútil para decidir si hoy se mergea el modelo nuevo o se congela.

Google SRE separa tres palabras que en Slack se usan mal: SLI (número), SLO (objetivo interno), SLA (contrato legal). Un “SLA violation” casi siempre es un SLO fallido. Un SLO que no puede fallar no es un SLO: es 100 % uptime disfrazado.

Contrato de esta guía: cuatro SLIs, error budget = 1 − SLO, burn rápido pagina, burn lento abre ticket, política 50 % / 100 %.

No es el circuit breaker (corta una dependencia). No es el kill switch (apaga el proceso). No es el juez LLM (una métrica más). El SLO decide si hay permiso para cambiar el sistema.

Cuatro SLIs, no un “uptime del bot”

SRE Workbook: el SLI útil es un ratio good / total entre 0 % y 100 %. Así el error budget es aritmética, no un panel de 14 gráficas. Un agente no es HTTP puro, pero el mismo molde cabe si dejas de medir “el contenedor está up”.

SLI	Good event	Total	Umbral de partida	Qué no cuenta
Entrega	Turno con ack + respuesta visible al usuario	Inbound autenticado (webhook, cola, cron)	99.5 % / 28 d	Probes internos, retries del mismo update_id
Tools	Tool que termina sin 5xx / timeout / schema inválido	Tool calls ejecutadas	99.0 % / 28 d	Rechazo de guardrail (eso es calidad)
Latencia	Turno bajo presupuesto (p. ej. TTFB < 8 s y fin < 45 s)	Turnos entregados	95 % / 28 d	Cola de HITL a propósito
Calidad	Tarea que pasa golden / rúbrica o no dispara loop, fuga, acción no pedida	Tareas cerradas	98 % / 28 d	Opinión del modelo sobre sí mismo

Especificación ≠ implementación. Ratio of home page requests that loaded in < 100 ms es spec; medirlo en el log del server no ve al cliente que nunca llegó. En un agente: medir “200 del webhook” no es entrega. Entrega es el mensaje que el usuario vio (ack Telegram / Slack ok: true / SSE cerrado con done). Tools se miden en el adapter, no en el texto que el modelo dijo que llamó.

Empieza por lo que ya tienes. El Workbook admite el performance actual solo si hay proceso para iterar. No ancles 99.99 % porque el bot estuvo quieto un domingo.

Error budget: permiso para cambiar

error budget = 1 − SLO. Un 99.5 % de entrega en 28 días, con 20 000 turnos, son 100 fallos contratados. SRE: If a service receives 3 million requests over four weeks, a 99.9 % success ratio SLO gives a budget of 3,000 errors. Un incidente de 50 fallos se come el 50 % del presupuesto de entrega. Eso no es “un mal día”: es una decisión de producto.

El presupuesto no es el spend de tokens. Los techos por tenant protegen la factura. El error budget protege la calidad percibida. Queman ambos si un loop de tools dispara 5xx y además paga el modelo; se operan con palancas distintas.

Ventana: 28 días rolling (el ejemplo canónico de política es four-week). No reinicies el mes calendario para “empezar de cero” después de un outage: eso es hacer trampa al usuario.

Burn rápido y burn lento

Alertar “error rate > 1 %” pagina de más o de menos. SRE Workbook, Alerting on SLOs: burn rate = qué tan rápido, relativo al SLO, se come el presupuesto. Burn 1 con SLO 99.9 % / 30 d es 0.1 % de error constante: agotas el mes justo al final. Burn 14.4 en 1 h consume ~2 % del presupuesto; burn 6 en 6 h consume ~5 %.

Tabla de partida para un agente con SLO 99.5 % (error 0.5 %) — mismos porcentajes de presupuesto que Table 5-8, no copies el 0.001 de 99.9 %:

Severidad	Ventana larga	Ventana corta (1/12)	Presupuesto	Qué haces
Page (rápido)	1 h	5 min	2 %	Página: dependencia o deploy reciente
Page (rápido)	6 h	30 min	5 %	Página: degradación que no es un spike
Ticket (lento)	3 d	6 h	10 %	Ticket al siguiente día laboral

La ventana corta evita que un incidente ya cerrado te siga paginando una hora. Notify only when we’re still actively burning. AND de larga + corta; OR entre pares. Si 10 % en 5 min también cumple 2 % en 1 h, suprime el duplicado.

Tráfico bajo: un agente de soporte con 8 turnos/hora no puede paginar por un 5xx. El Workbook lo dice: 1 fallo / 10 req = 10 % en la hora, 1 000× burn para un 99.9 %. Opciones honestas: bajar el SLO (99 % no es vergüenza), medir minutos buenos (good user minutes), o sumar un probe sintético que no cuente como usuario real. No infles el denominador con healthchecks para “mejorar” el ratio.

Política 50 % / 100 %

Un SLO sin dientes es un wallpaper. La política de ejemplo de SRE (2018-02-19, Steven Thurgood) congela releases que no sean P0/security cuando el servicio agotó el presupuesto de las 4 semanas. Para un agente chico, esperar al 0 % es tarde: el modelo nuevo ya salió. Política operativa:

Presupuesto restante (28 d, el SLI más flojo)	Releases	Features	On-call
> 50 %	Según la política normal	Sí	Burn como arriba
≤ 50 %	Solo reliability + P0 + security	Freeze de tools nuevas, modelos, prompts de sistema	Reliability primero
0 % (100 % consumido)	Halt total salvo P0/security hasta volver al SLO	Cero	Postmortem si un incidente se comió ≥ 20 %

SRE: This policy is not intended to serve as a punishment. El freeze da permiso para dejar de shippear. Must trabajar reliability si el miss fue bug propio o error de procedimiento. May seguir con features si el outage fue red de la empresa, un proveedor ya frozen, o carga fuera de alcance (pentest, load test). Un incidente ≥ 20 % del presupuesto en 4 semanas → postmortem con al menos un P0. Una clase de outage ≥ 20 % en el trimestre → P0 del siguiente quarter.

El freeze no es el kill switch. El agente sigue sirviendo. Lo que para es cambiarlo.

Checklist de un SLO que se puede defender

1. Cuatro ratios good/total con spec e implementación escritos (log, probe o cliente).
2. Ventana 28 d rolling; error budget visible por SLI, no un “score” mezclado.
3. Alertas multiwindow: page 1 h/5 min y 6 h/30 min; ticket 3 d/6 h.
4. Política 50/100 firmada por quien mergea (tú, si eres el equipo).
5. Un incidente ≥ 20 % dispara postmortem; el juez LLM no vota el freeze.

Si no hay stakeholders que acepten el número, el Workbook es claro: without SLOs, there is no need for SREs. En un indie agent: sin SLO, no hay permiso para decir “hoy no se deploya”.

FAQ

¿99.9 % para un bot de Telegram? Casi nunca. 99.9 % / 28 d con 5 000 turnos son 5 fallos. Un timeout de OpenAI se come el mes. Empieza 99 %–99.5 % en entrega y 95 % en latencia.

¿El juez LLM es el SLI de calidad? No. Es un grader. Calíbralo con kappa contra humanos; el SLO de calidad usa goldens + fallos duros (loop, fuga, acción no pedida). El juez puede alimentar el numerador, no sustituirlo.

¿Páginas por CPU / RAM? No. Eso es síntoma. El SLI es el usuario. CPU sirve para capacity, no para el contrato.

¿Dónde encaja el curso? Si aún no hay loop de tools + logs, empieza por instalar un agente y el hub de seguridad, coste y operación. El SLO llega con tráfico real, no en la demo.

Fuentes verificadas 2026-09-06: SRE Book cap. 4; Workbook Implementing SLOs, Alerting on SLOs (Table 5-8) y Example Error Budget Policy.