Agent observability: een stack kiezen bij 4M spans per maand

Het is 22:47 op een dinsdag. Een operations lead bij een Nederlands HR-tech bedrijf van 28 mensen pingt ons in Slack. Hun procurement-agent heeft deze week één tool call 4,1 miljoen keer uitgevoerd. Ergens na het eten zakte het succespercentage van 99,3% naar 86%. Niemand werd gepiept, want hun agent observability is een Grafana-dashboard dat na 18:00 niemand opent. De agent bleef API-credits opmaken tot een finance-bot om 22:30 aan de bel trok.

Dit is de saaie failure mode van agent-software. Geen jailbreak, geen hallucinatie. Een retry-loop die niemand in de gaten houdt, in een systeem dat miljoenen gestructureerde events per maand produceert. De vraag waar we de volgende ochtend mee binnenkomen is altijd dezelfde: welke observability-stack moeten we installeren zodat dit nooit twee keer gebeurt, met een team van vier engineers en een reëel budget?

De drie stacks op onze shortlist

We hebben inmiddels veertien productie-agents live staan. Voor een Nederlandse B2B SaaS met een omzet tussen €2M en €20M halen drie opties daadwerkelijk de lat:

• Langfuse, self-hosted op Hetzner. Open source onder de Langfuse EE-splitsing. Postgres voor metadata, ClickHouse voor traces sinds v3. Heeft prompts, evals, datasets en een UI die ook iemand zonder engineering-achtergrond kan lezen.
• Arize Phoenix Cloud. Gehoste versie van het open source Phoenix-project. OpenTelemetry-native, OpenInference semantic conventions, evals ingebouwd. Je betaalt per geïngeste span en per seat.
• Zelf gebouwde OpenTelemetry-collector naar ClickHouse, met Grafana eroverheen. Geen vendor in de loop. Jij bezit het schema, de dashboards en elke alertregel.

We hebben LangSmith de afgelopen twaalf maanden geen enkele keer zien landen bij een Nederlandse koper. Het DPO-gesprek maakt er een einde aan voordat de prijs er nog toe doet.

Trace-replay kosten bij vier miljoen spans per maand

Replay is het onderdeel dat de meeste teams vergeten te prijzen. Wanneer een prompt of tool-definitie verandert, wil je de laatste 30 dagen productie-traces opnieuw draaien tegen de nieuwe versie en de outputs vergelijken. Bij 4M spans per maand is een venster van 30 dagen zo'n 16 tot 24 GB aan gecomprimeerde trace-data, afhankelijk van de payloadgrootte van de tool calls. De kosten zitten niet in opslag. Ze zitten in de model spend tijdens de replay, plus het systeem dat snel genoeg over die spans kan itereren om bruikbaar te zijn.

De rekensom, afgerond op wat we daadwerkelijk hebben betaald:

• Langfuse self-hosted. Eén Hetzner CCX33 (zo'n €48 per maand) trekt 4M spans zonder moeite. Replay draait binnen Langfuse tegen je prompt-versies, dus de enige echte kostenpost is de model spend zelf. Back-ups naar een Hetzner Storage Box kosten daar nog zo'n €5 bovenop.
• Phoenix Cloud. Boven de free tier lopen de span-ingestiekosten snel op. Je betaalt ook seats. Replay is goed geïntegreerd, maar je krijgt de data er niet uit zonder voor export te betalen. Reken op €400 tot €900 per maand bij 4M spans, afhankelijk van de retentie.
• Zelf gebouwde OTel en ClickHouse. Dezelfde Hetzner-bak plus een tweede voor Grafana, zo'n €70 per maand. Maar replay is wat je zelf bouwt. De eerste keer dat iemand 200k spans opnieuw moet draaien tegen een nieuwe prompt, kom je erachter dat dat script nog nooit geschreven is. Reserveer twee engineer-weken voor tooling die Langfuse uit de doos meelevert.

DPO-vriendelijkheid

Elke Nederlandse B2B SaaS onder de €20M waar we mee werken heeft een parttime DPO, soms een fractionele die gedeeld wordt met drie andere startups. Ze zijn niet vijandig. Ze zijn moe. De stack die de minste uitleg vereist, wint.

Self-hosted Langfuse op een Hetzner-bak in Falkenstein of Helsinki is een toevoeging van vijf regels aan het bestaande verwerkingsregister. De verwerker is dezelfde die al gebruikt wordt voor Postgres. Geen nieuwe subverwerker, geen nieuwe transfer impact assessment.

Phoenix Cloud draait op AWS, voornamelijk US-east. Dat betekent een onderbouwing onder het EU-US Data Privacy Framework en, voor elke klant met salaris- of gezondheidsdata, een apart gesprek met de Autoriteit Persoonsgegevens dat niemand wil voeren. De leverancier tekent een DPA. Procurement bij de klant heeft alsnog zes weken nodig om het goed te keuren.

Zelf gebouwd wint op papier. Het dwingt je ook om degene te zijn die de tracegeschiedenis van een gebruiker wist als er een verzoek onder artikel 17 binnenkomt. Dat script hebben we nu drie keer geschreven. Reken er een dag voor.

Wie bouwt de 92%-alert

De alert die het dinsdagincident had opgemerkt is makkelijk te schrijven en makkelijk te vergeten. Tool-call success onder 92% gedurende vijf minuten, piep iemand op. De interessante vraag is wie er eigenaar van is.

In Langfuse zet je het op in de UI in zo'n tien minuten. Evaluators draaien op een schedule, een Slack-webhook vuurt, klaar. Een operations lead kan het onderhouden zonder een ticket aan te maken.

In Phoenix zijn evals first-class, maar de alerting-laag leunt erop dat jij de evaluation-hooks van de cloud zelf koppelt aan PagerDuty of Opsgenie. Te doen in een sprint. Niet te onderhouden door iemand die geen engineer is.

In de zelf gebouwde stack schrijf je de regel zelf. De basisvorm, zodra je OTel-collector tool-call spans exporteert met een status attribute:

groups:
  - name: agent-tool-calls
    rules:
      - alert: AgentToolCallSuccessLow
        expr: |
          sum(rate(agent_tool_calls_total{status="ok"}[10m]))
            /
          sum(rate(agent_tool_calls_total[10m]))
            < 0.92
        for: 5m
        labels:
          severity: page
        annotations:
          summary: "Tool-call success rate below 92% for 5 minutes"
          runbook: "https://wiki.internal/runbooks/agent-toolcall-low"

Die regel is twintig regels YAML. De verborgen kostenpost is de runbook-URL. De eerste keer dat de alert om 02:00 afgaat, wil de on-call engineer de trace-ID's van de gefaalde calls in de alertbody. Dat vergt het templaten van de Grafana-link met het juiste tijdsvenster en het juiste filter. Reken een dag voor die afwerking.

De scoring sheet die we echt gebruiken

We draaien deze matrix bij elk agent-project. De cijfers lopen van 1 tot 5, hoger is beter voor de koper.

De interessante rij is de laatste. Als je evaluatielogica bestaat uit een panel van drie model-judges en een regexcheck, krijg je dat zowel bij Langfuse als bij Phoenix uit de doos. Als je evaluatielogica inhoudt dat je een tool call replayt tegen een sandbox van je eigen ERP, helpt geen van drieën je. Dat bouw je in alle drie de werelden zelf.

Wat we meestal kiezen

Voor een Nederlandse B2B SaaS in de band van €2M tot €20M is onze default Langfuse self-hosted op een Hetzner CCX33 in Helsinki, met back-ups naar een Storage Box en een SOPS-encrypted secrets-bestand in de repo. We verplaatsen ze pas naar managed Postgres als ze Series A halen en het procurement-verhaal strakker wordt.

We stappen in twee gevallen over op de zelf gebouwde OTel- en ClickHouse-stack. Eén: het spanvolume gaat boven de 20M per maand uit en de evaluator-scheduling van Langfuse begint achter te lopen. Twee: de data van de klant leeft in een gereguleerde omgeving (een Nederlandse zorgverzekeraar, een bank) waar elke afhankelijkheid een interne security review nodig heeft en een Langfuse-pod toevoegen aan het bestaande cluster goedkoper is dan een Langfuse-leverancier toevoegen.

We hebben Phoenix Cloud het afgelopen jaar precies twee keer aanbevolen. Allebei waren het teams zonder platform engineer en met een Amerikaans moederbedrijf dat al een AWS-DPA had geregeld. Hun constraint was geen technologie. Het was dat niemand in het team ooit naar een server had geSSH'd.

De failure modes van agents in 2026 worden gedomineerd door retries, loops en stille degradatie, niet door exotische safety-incidenten. Het team dat ze op tijd vangt is het team dat iemand op de 92%-drempel oppiepte, niet het team dat in maart een red-team workshop op directieniveau draaide.

Toen we dit voorjaar de procurement-agent bouwden voor een Nederlandse HR-tech klant, liepen we ertegenaan dat het tool-call succespercentage in totaal prima leek, maar op één klant-tenant op 60% zat omdat hun API-quota stilletjes was gehalveerd. We hebben uiteindelijk per-tenant evaluators in Langfuse opgeleverd als onderdeel van een AI-agents-uitrol, gepiept op een 90%-drempel, en de regressie werd gepakt op de dag dat hij begon.

Het kleinste wat je vandaag kunt doen: open de meest aangeroepen tool van je agent, noteer het succespercentage over de laatste zeven dagen uit je bestaande logs en bepaal in welke rij van de matrix je zit. Tien minuten zodra je dat ene getal hebt.