Problema
Muchos equipos instrumentan agentes solo cuando algo se rompe.
Eso deja fuera la mitad del problema. Un agente puede no fallar y aun asi destruir margen: demasiados tokens, demasiada latencia, demasiadas retries o demasiado coste por usuario para el valor que entrega.
Si la observabilidad solo te ayuda a investigar incidentes, llegas tarde. La economia del sistema ya se ha ido.
Tesis
La nueva AI observability importa porque mueve la observacion desde el debugging tecnico hacia la gestion economica del producto.
No basta con saber que prompt entro y que output salio. Hace falta ver:
- cuanto cuesta cada conversacion
- que organizacion o cliente consume mas
- que latencia empeora la experiencia
- que traces o sesiones explican el coste
Cuando esa capa existe, el agente deja de ser una magia cara y empieza a ser una unidad operable.
Framework
Una observabilidad de IA orientada a negocio necesita cinco vistas:
- Conversacion: que entro, que salio y con que contexto.
- Trace: que cadena de llamadas y herramientas ocurrio.
- Coste: cuanto consume por chat, usuario, org o workflow.
- Rendimiento: latencia, errores y throughput.
- Sesion: como se conectan varias interacciones dentro del viaje real.
Mini-caso: un agente de soporte parece util porque responde bien. Pero al unir coste, latencia y sesiones ves que un 20% de clientes dispara loops caros cuando cambia de idioma y adjunta capturas. Ese hallazgo no aparece en una tabla de prompts. Aparece cuando observabilidad y producto se tocan.
Senal medible: coste total por outcome util, separado por workflow y segmento de cliente.
Por que importa ahora
La documentacion oficial de PostHog posiciona AI Observability como una capa para capturar conversaciones LLM, tokens, coste, latencia, errores, trazas y sesiones multi-conversacion. Tambien subraya algo relevante para operating model: cuanto esta costando cada chat, usuario u organizacion.
La propia pagina de producto refuerza esa lectura. Habla de cost analysis, performance monitoring, trazas e integraciones nativas, y lo presenta como eventos regulares dentro del sistema de producto. Esa combinacion importa porque acerca la IA a un lenguaje que negocio y producto ya entienden.
La consecuencia es clara: la observabilidad de agentes deja de ser solo una consola para ingenieros. Empieza a ser una capa de accounting operativo.
Anti-ejemplo
“Ya tenemos logs de prompts.”
Eso explica una llamada aislada. No explica coste acumulado, rendimiento por cliente, sesiones largas, fugas de margen ni comparativas entre workflows.
Protocolo (3 pasos)
- Une observabilidad y P&L. No midas tokens sin outcome.
- Mira por organizacion y workflow. El coste promedio oculta los problemas caros.
- Etiqueta loops y retries. Muchas fugas vienen de iteraciones silenciosas.
| Capa | Pregunta | Riesgo si falta |
|---|---|---|
| conversacion | que paso en cada llamada | lectura parcial |
| trace | que cadena lo produjo | debugging lento |
| coste | quien paga cuanto | margen ciego |
| rendimiento | donde cae la experiencia | latencia normalizada |
| sesion | que patron se repite | fuga invisible |
Relacionado
- AI Traces: la capa que convierte agentes en sistemas auditables
- Agent Memory from Trace: la memoria util no vive en el chat, vive en la operacion
- Token-to-Outcome: el KPI que separa IA usada de IA rentable
Fuentes consultadas
- Getting started with AI Observability
- AI Observability - PostHog
- Manual capture AI Observability installation
Proximo paso
Escoge un agente que ya este en produccion y calcula tres cosas en la misma vista: coste por organizacion, latencia por workflow y porcentaje de sesiones con retries. Ahi suele empezar la conversacion de margen real.