We kregen een telefoontje van een logistiekclient: een agent die transportboekingen moest automatiseren, begon consequent de duurdere vervoerder te kiezen in plaats van de goedkoopste. Het prijsverschil was zichtbaar — de oorzaak niet. Logs toonden invoer en uitvoer. Ze toonden niet waarom de agent in een bepaalde stap de tool aanriep met de parameters die hij gebruikte. Het kostte ons vier uur om de beslissingsvolgorde te reconstrueren uit ruwe logs. Het probleem was in vijftien minuten opgelost — maar alleen zodra we wisten waar we moesten zoeken.
Dit is een probleem dat zich herhaalt bij de meeste eerste productie-uitrollingen van agenten. Teams weten hoe ze een agent bouwen, weten hoe ze hem starten, maar weten niet hoe ze hem moeten debuggen. Observability — het vermogen om de interne toestand van een systeem te begrijpen aan de hand van zijn externe uitvoer — is voor agenten geen luxe. Het is de voorwaarde om een systeem te kunnen onderhouden en verbeteren.
Eval versus observability: twee verschillende dingen
Voordat we ingaan op tools en aanpak, is het belangrijk twee dingen te onderscheiden die vaak worden verward.
Eval (evaluatie) beantwoordt de vraag: *is de kwaliteit van de uitvoer van de agent voldoende?* Dit wordt offline of op historische data gemeten — bijvoorbeeld: had de agent in 87% van de gevallen gelijk? Genereerde hij het juiste formaat? Beantwoordde hij vragen correct?
Observability beantwoordt de vraag: *wat gebeurde er precies tijdens één uitvoering?* Dit wordt gemeten tijdens runtime — terwijl de agent draait of nadat de uitvoering is voltooid — en legt de volgorde van beslissingen, tool-aanroepen, tussenliggende toestand en fouten vast.
Eval is retrospectieve statistiek. Observability is een chirurgisch instrument voor een concreet incident. Beide zijn nodig — ze dupliceren elkaar niet.
De meeste teams beginnen met eval en negeren observability. In de praktijk werkt dit tot het eerste productie-incident. Daarna draaien de prioriteiten om.
Wat u moet vastleggen
Een agent is niet één functie. Het is een netwerk van stappen — elke stap heeft invoer, uitvoer, een LLM-prompt, een beslissing en eventueel een fout. Voor elke uitvoering van de agent moet u het volgende kunnen zien:
- Trace: de volledige aanroepboom van de beginprompt tot het eindantwoord, inclusief alle deelbomen
- Spans: de afzonderlijke stappen binnen een trace — elke LLM-aanroep, elke tool-aanroep, elke retrieval
- State diff: wat er veranderde in de interne toestand van de agent tussen stappen (cruciaal bij
LangGraph) - Tool calls: de exacte parameters van elke tool-aanroep en de exacte uitvoer die de tool retourneerde
- LLM-prompts: wat de werkelijke prompt was die naar het model werd gestuurd (niet de sjabloon — de definitieve tekst na interpolatie)
- Tokens en latency: aantal tokens per span, tijd per span — voor het identificeren van bottlenecks
- Fouten en retries: waar de agent mislukte, hoe vaak hij het opnieuw probeerde, met welk resultaat
Elk van deze elementen is onmisbaar. Als u alleen de uitvoer van de laatste stap vastlegt, heeft u een applicatielog — geen agent-observability.
Waarom klassieke logging niet volstaat
Wanneer ontwikkelaars voor het eerst "observability" horen, antwoorden ze gewoonlijk: "maar we loggen toch". Ze loggen — maar niet op de juiste manier voor agenten.
Een klassieke log is sequentieel. Record na record, timestamp, bericht. Voor een eenvoudige API is dat voldoende. Voor een agent waarbij één gebruikersinvoer tientallen LLM-aanroepen, tool-aanroepen en retrieval-stappen activeert — in een boom, niet in een reeks — is een platte log onbruikbaar. U heeft geen context, geen hiërarchie, geen toestand in de tijd.
Een tweede probleem: agentframeworks zoals LangGraph internaliseren veel beslissingen. Welk node werd geselecteerd, waarom een bepaalde edge werd geactiveerd, wat de toestand was bij een checkpoint — dit is niet zichtbaar in een gewone stdout-log. U heeft directe integratie met het framework nodig, niet een wrapper eromheen.
Het derde probleem is sampling en kosten. Een productieagent kan dagelijks duizenden uitvoeringen draaien. Alles loggen in een gestructureerde trace is duur qua opslag. U heeft een sampling-strategie nodig — bijvoorbeeld 100% van fouten en lange uitvoeringen vastleggen, 10–20% willekeurig gesampelde succesvolle uitvoeringen.
Trace: de basis van agent-observability
Een trace is de root-container van één agentuitvoering. Het correspondeert met één taak — bijvoorbeeld één gebruikersverzoek of één geplande operatie. Binnen een trace bevinden zich spans — elke span is één stap met metadata.
De hiërarchie ziet er als volgt uit:
- Trace: "Boek transport voor bestelling #4821"
- - Span: LLM-aanroep — begrip van het verzoek
- - Span: Tool-aanroep —
search_carriers(origin, destination, date) - - Span: Tool-aanroep —
get_price(carrier_id=12) - - Span: Tool-aanroep —
get_price(carrier_id=17) - - Span: LLM-aanroep — beslissing en redenering
- - Span: Tool-aanroep —
book_shipment(carrier_id, price, ...)
Elke span heeft: begintijd en eindtijd, invoer, uitvoer, eventuele fout, parent-ID. Hiermee kunt u het volledige beslissingsverloop reconstrueren zonder te raden.
In LangGraph wordt deze boom op een natuurlijke manier gekoppeld aan grafen — elke node in de graaf is een span. Tools zoals LangSmith leggen de state diff vast bij elke overgang van een graafedge, wat een gedetailleerd inzicht geeft in de ontwikkeling van de toestand.
ReAct tracing: reason-act-observe in de logs
Wanneer een agent de ReAct-architectuur gebruikt — de Reason, Act, Observe-lus — moet observability elk van deze stappen expliciet vastleggen.
Reason-stap: wat de agent "dacht" — de chain-of-thought-uitvoer van het model vóór de tool-aanroep. Dit is de waardevolste stap voor debugging. Wanneer een agent de verkeerde tool aanroept, is het antwoord bijna altijd zichtbaar in de reason-stap — het model "besloot" fout op basis van een redenering die in de tekst staat.
Act-stap: de exacte tool-aanroep met parameters. Niet de sjabloon — de werkelijke waarden na interpolatie. Fouten in tool-calling — onjuist gevormde parameters, verkeerd type — zijn hier zichtbaar.
Observe-stap: wat de tool retourneerde. Belangrijk: de ruwe uitvoer van de tool vóórdat het model die verwerkt. Wanneer een tool een onverwacht formaat of een foutmelding retourneert, is dit de plek waar u dat ziet.
Zonder expliciete logging van deze drie stappen per iteratie heeft u alleen de einduitvoer. En de einduitvoer vertelt u niet waarom de agent na de derde iteratie van beslissing veranderde.
Metrics om bij te houden
Naast een trace per uitvoering heeft u geaggregeerde metrics nodig voor monitoring:
- Latency p50/p95/p99 — niet alleen de totale uitvoeringslatency, maar per-node latency. Waar besteedt de agent zijn tijd?
- Tokenverbruik per uitvoering — trend, uitschieters (uitvoeringen met 10× meer tokens = foutpatroon)
- Tool error rate — percentage uitvoeringen waarbij ten minste één tool-aanroep mislukte
- Retry rate — hoeveel procent van de uitvoeringen een retry vereiste. Een retry rate van 12% of meer signaleert gewoonlijk een probleem in schema-validatie of in de prompt
- Abandonment rate — uitvoeringen waarbij de agent het doel niet bereikte en een fallback-antwoord retourneerde
- Human escalation rate — bij HITL (human-in-the-loop)-systemen: percentage uitvoeringen geëscaleerd naar een mens
Elk van deze metrics heeft een symptomatisch karakter. Een hoge retry rate wijst op instabiel tool-calling. Een hoge p99-latency bij lage p50-latency wijst op outlier-scenario's — waarschijnlijk lange contexten of retry-lussen. Een hoge abandonment rate wijst op randgevallen die de agent niet kan verwerken.
Tools: LangSmith, Langfuse, Arize Phoenix
Voor productie-uitrollingen bestaan er vandaag drie hoofdplatformen:
`LangSmith` — de diepste integratie met LangGraph en LangChain. Legt automatisch traces, state diff, tokens en latency vast. Heeft een playground voor het herspelen van uitvoeringen — u kunt een specifieke trace nemen en opnieuw uitvoeren met een aangepaste prompt. Cloud-hosted, met pricing op basis van tracevolume. Als uw stack LangGraph is, is LangSmith de voor de hand liggende keuze.
`Langfuse` — framework-agnostisch, self-hostable (Postgres + ClickHouse). SDK voor Python, TypeScript, REST. Werkt ook als u niet via LangGraph schrijft — u roept de SDK rechtstreeks aan bij elke LLM-aanroep en tool-aanroep. Geschikt voor teams die volledige controle over hun data willen (gereguleerde sectoren, on-prem-eisen). Self-hosting voegt operationele overhead toe — het ClickHouse-cluster moet worden onderhouden.
`Arize Phoenix` — op OpenTelemetry gebaseerd. Legt traces vast via het standaard OTel-protocol, wat integratie met een bestaande monitoring-stack mogelijk maakt (Prometheus, Grafana, Jaeger). Bovendien: 50+ eval-metrics rechtstreeks in het platform — faithfulness, hallucination detection, relevance. Voor teams waarbij agent-observability deel moet uitmaken van een breder APM-oplossing.
Keuzerichtlijn: als u op LangGraph in de cloud zit — LangSmith. Als u self-hosting nodig heeft of een heterogene stack heeft — Langfuse. Als u observability én eval in één wilt en een OTel-infrastructuur heeft — Arize Phoenix.
Voor kleinere projecten in een vroeg stadium: Langfuse self-hosted op een eenvoudige Docker Compose volstaat en bespaart kosten.
Replay en het debuggen van een concreet incident
Observability heeft de meeste waarde bij een concreet incident. De aanpak die in de praktijk werkt:
- 1.Identificeer de trace op basis van trace-ID of op basis van een filter (bijvoorbeeld: alle uitvoeringen met tool error rate > 0 in de afgelopen 24 uur)
- 2.Open de state diff — bekijk hoe de toestand van de agent stap voor stap veranderde. Waar trad een verandering op die u niet verwachtte?
- 3.Lees de reason-tekst in elke LLM-aanroep — zoek de logica die antwoord geeft op "waarom nam de agent deze beslissing"
- 4.Controleer de tool-uitvoer — kon het probleem liggen in wat de tool retourneerde, en niet in wat de agent met die uitvoer deed?
- 5.Voer een replay uit met een aangepaste prompt of parameters — hypothesebevestiging zonder echte omgeving
Deze aanpak verkort de MTTR (mean time to resolution) van uren naar minuten. Uit ervaring: de meeste agentbugs zitten niet in LLM-redenering — ze zitten in tool-calling, in een onverwacht uitvoerformaat van de tool of in state management. Observability maakt dit onderscheid in seconden mogelijk.
Alerts en proactieve bewaking
Reactief debuggen is slechts één laag. Een productiesysteem heeft ook proactieve alerts nodig.
Basisregels voor alerting:
- Tool error rate > 5% over een uurvenster → alert, waarschijnlijk een wijziging in het downstream-systeem of in het tool-schema
- Gemiddelde uitvoeringslatency > 2× baseline → alert, outlier-scenario of upstream-vertraging
- Abandonment rate > 10% per dag → alert, nieuwe randgevallen in productie
- Tokenkosten per dag > X EUR — kostenalert, onmisbaar bij agenten waarbij looping onbeperkt aanroepen kan genereren. Een agent zonder kostenalert kan 's nachts duizenden aanroepen genereren en een rekening van duizenden euro's — een risico dat we in de praktijk regelmatig zien
Alerts moeten naar een trace verwijzen, niet alleen naar een getal. Wanneer ik een alert ontvang "tool error rate 8%", wil ik rechtstreeks een link naar de trace waar dit zich voordeed — niet een getal zonder context.
Observability en agentkosten
Observability zelf genereert kosten — opslag voor traces, compute voor analytics. Voor productiesystemen met een groot volume is het belangrijk een sampling-strategie in te stellen.
Aanbevolen aanpak:
- 100% sampling voor foutieve uitvoeringen (tool error, abandonment, timeout)
- 100% sampling voor uitvoeringen met ongebruikelijke latency (p99-uitschieters)
- 10–20% sampling voor succesvolle uitvoeringen binnen de norm
- 100% sampling tijdens de uitrol van een nieuwe agentversie (eerste 24–48 uur)
Dit verlaagt de opslagkosten met 5–10× met behoud van volledige zichtbaarheid voor diagnostiek. Platforms zoals Langfuse ondersteunen configuratie van de sampling rate natively.
Samenhang met agentkosten in productie: observability stelt u in staat te identificeren welke uitvoeringen inefficiënt zijn — bijvoorbeeld uitvoeringen waarbij de agent herhaaldelijk dezelfde tool aanroept vanwege een onduidelijk antwoord. Dit is typisch een probleem in de betrouwbaarheid van tool-calling dat observability blootlegt voordat het de kosten significant verhoogt.
De beveiligingsdimensie van tracing
Traces bevatten gevoelige data — prompts, tool-uitvoer, interne agenttoestand. In gereguleerde sectoren (financiën, gezondheidszorg, juridisch) vereist dit:
- Versleuteling van traces at rest en in transit
- Toegangscontrole — wie mag tracerecords lezen?
- Retentiebeleid — hoe lang bewaart u traces?
- PII-scrubbing — persoonsgegevens in prompts of tool-uitvoer mogen niet in plain text worden opgeslagen
Self-hosted Langfuse geeft volledige controle over deze aspecten. Cloudplatformen moeten worden beoordeeld aan de hand van uw GDPR/data residency-eisen — met name wanneer traces bedrijfs- of klantgegevens bevatten.
Voor on-prem LLM-uitrollingen is self-hosted observability vrijwel altijd een vereiste, geen keuze.
Veelgestelde vragen
Moet ik observability hebben vóór de eerste uitrol van de agent?
Niet per se vóór de eerste testuitrol — maar wel vóór uitrol naar productie met echte gebruikers of echte data. Zonder observability heeft u geen manier om te identificeren waar de agent faalt, noch waarom. Het eerste productie-incident dat debugging vereist zonder tracing overtuigt een team doorgaans sneller dan welk argument dan ook.
Wat is het verschil tussen tracing en standaard logging?
Een klassieke log is een platte reeks records. Tracing legt een hiërarchische boom vast — een trace bevat spans, spans bevatten child spans. Voor een agent waarbij één invoer tientallen aanroepen in een boom activeert, is de hiërarchische structuur onmisbaar. Bovendien legt tracing de state diff tussen stappen vast, wat een platte log niet mogelijk maakt.
Werkt observability ook voor agenten die niet op LangGraph draaien?
Ja. Langfuse en Arize Phoenix zijn framework-agnostisch — u hoeft alleen de SDK aan te roepen bij elke LLM-aanroep en tool-aanroep. Als u een eigen agent schrijft zonder framework, kunt u OpenTelemetry-spans handmatig toevoegen. LangSmith heeft de diepste integratie met LangGraph, maar ook voor andere frameworks bestaan er integraties.
Wat zijn de kosten?
Langfuse self-hosted is gratis (alleen operationele infrastructuurkosten — een eenvoudige Docker Compose met Postgres + ClickHouse). LangSmith en Arize Phoenix hebben een free tier voor lage volumes; betaalde plannen beginnen in de orde van tientallen euro's per maand. De hoofdkosten zijn niet het platform — het is de opslag voor traces, met name bij een hoog uitvoeringsvolume.
Moet ik volledige LLM-prompts loggen?
Ja — met één voorwaarde: als prompts persoonlijke of bedrijfsgegevens bevatten, moet u PII-scrubbing regelen vóór opslag. Alleen metadata loggen (token count, latency, tool name) zonder promptinhoud is goedkoper, maar beperkt de debugbaarheid aanzienlijk. Wij adviseren volledige prompts te loggen met een retentiebeleid en toegangscontrole.
Conclusie
*Observability van AI-agenten gaat niet over tools — het gaat over de cultuur van verantwoordelijkheid voor wat het systeem in productie doet. Wanneer een agent faalt, moet de vraag "waarom" binnen minuten een antwoord hebben, niet binnen uren. Bij MP Industrial Solutions helpen we teams om observability in te richten als onderdeel van de agentarchitectuur — niet als een extra laag achteraf. Als u nadenkt over de uitrol van een agent of een incident in een bestaand systeem aanpakt, kijken we graag mee naar uw concrete situatie.*