Problem
Mange teams instrumenterer agenter først, når noget går i stykker.
Det udelader halvdelen af problemet. En agent kan køre uden fejl og alligevel ødelægge marginen: for mange tokens, for meget latenstid, for mange retries eller for høje omkostninger per bruger i forhold til den værdi, den leverer.
Hvis observability kun hjælper dig med at undersøge incidents, kommer du for sent. Systemets økonomi er allerede tabt.
Tesen
Den nye AI observability er vigtig, fordi den flytter observationen fra teknisk debugging til økonomisk produktstyring.
Det er ikke nok at vide, hvilken prompt der kom ind, og hvilket output der kom ud. Man skal kunne se:
- hvor meget hver samtale koster
- hvilken organisation eller kunde der forbruger mest
- hvilken latenstid der forringer oplevelsen
- hvilke traces eller sessioner der forklarer omkostningen
Når det lag findes, holder agenten op med at være dyr magi og begynder at være en operabel enhed.
Rammeværk
En forretningsorienteret AI-observability har brug for fem visninger:
- Samtale: hvad der kom ind, hvad der kom ud, og med hvilken kontekst.
- Trace: hvilken kæde af kald og værktøjer der forekom.
- Omkostning: hvor meget der forbruges per chat, bruger, org eller workflow.
- Ydeevne: latenstid, fejl og throughput.
- Session: hvordan flere interaktioner forbindes inden for den reelle rejse.
Mini-case: en supportagent virker nyttig, fordi den svarer godt. Men når man samler omkostning, latenstid og sessioner, ser man, at 20% af kunderne udløser dyre loops, når de skifter sprog og vedhæfter skærmbilleder. Den indsigt viser sig ikke i en prompt-tabel. Den viser sig, når observability og produkt mødes.
Målbar indikator: samlet omkostning per nyttigt outcome, opdelt efter workflow og kundesegment.
Hvorfor det er vigtigt nu
PostHogs officielle dokumentation positionerer AI Observability som et lag til at indfange LLM-samtaler, tokens, omkostning, latenstid, fejl, traces og multi-konversations sessioner. Den understreger også noget relevant for driftsmodellen: hvor meget hver chat, bruger eller organisation koster.
Selve produktsiden forstærker den læsning. Den taler om cost analysis, performance monitoring, traces og native integrationer og præsenterer det som almindelige events i produktsystemet. Den kombination er vigtig, fordi den bringer AI tættere på et sprog, som forretning og produkt allerede forstår.
Konsekvensen er tydelig: agent-observability holder op med kun at være en konsol for ingeniører. Det begynder at være et lag af operationel accounting.
Modeksempel
“Vi har allerede prompt-logs.”
Det forklarer et isoleret kald. Det forklarer ikke akkumulerede omkostninger, ydeevne per kunde, lange sessioner, marginlækager eller sammenligninger mellem workflows.
Protokol (3 trin)
- Foren observability og P&L. Mål ikke tokens uden outcome.
- Se pr. organisation og workflow. Den gennemsnitlige omkostning skjuler de dyre problemer.
- Markér loops og retries. Mange lækager kommer fra stille iterationer.
| Lag | Spørgsmål | Risiko hvis det mangler |
|---|---|---|
| samtale | hvad skete der i hvert kald | delvis læsning |
| trace | hvilken kæde producerede det | langsom debugging |
| omkostning | hvem betaler hvor meget | blind margin |
| ydeevne | hvor falder oplevelsen | normaliseret latenstid |
| session | hvilket mønster gentager sig | usynlig lækage |
Relateret
- AI Traces: laget der gør agenter til auditable systemer
- Agent Memory from Trace: nyttig hukommelse lever ikke i chatten, den lever i driften
- Token-to-Outcome: KPI’en der adskiller brugt AI fra rentabel AI
Konsulterede kilder
- Getting started with AI Observability
- AI Observability - PostHog
- Manual capture AI Observability installation
Næste skridt
Vælg en agent, der allerede er i produktion, og beregn tre ting i den samme visning: omkostning per organisation, latenstid per workflow og procentdel af sessioner med retries. Her starter samtalen om reel margin normalt.
Oversat fra den spanske original med AI-hjælp og gennemset for nøjagtighed. Læs originalen på spansk.