Het Foundry-team van Microsoft heeft OpenTelemetry-gebaseerde tracing toegevoegd aan zijn agent-framework, waardoor ontwikkelaars een manier hebben om de end-to-end uitvoering te zien over heterogene, door LLM ondersteunde agents.

Waarom multi-agent-systemen meer nodig hebben dan logbestanden

Een typische AI-gestuurde incident-response oefening maakt gebruik van een commander agent die verschillende specialist agents orkestreert: één analyseert logs, een andere detecteert afwijkingen in metrieken, een derde koppelt symptomen aan runbooks, en een router kiest het beste taalmodel voor elke subtaak. Elke specialist kan een ander model aanroepen — bijvoorbeeld een “gpt-5-mini” variant — en zijn eigen tools aanroepen. Wanneer er iets misgaat, staren engineers naar geïsoleerde logs die laten zien wat elk onderdeel deed, maar zonder overzicht van hoe de stukjes in elkaar passen.

Zonder een verenigde trace verbergt de oorzaak zich in de overdracht tussen agents. De commander stuurt mogelijk een verzoek dat de log-reader correct afhandelt, maar de metriek-specialist interpreteert de gegevens verkeerd en stelt het verkeerde runbook voor. Het handmatig debuggen van die keten kost tijd en is foutgevoelig.

Hoe OpenTelemetry de workflow samenvoegt

OpenTelemetry definieert twee kernconcepten: traces en spans. Een trace is een unieke identifier die een verzoek volgt van binnenkomst tot de uiteindelijke respons. Een span legt een enkele operatie vast — zoals een aanroep naar een taalmodel of een tool-aanroep — binnen die trace.

Wanneer een agent een verzoek ontvangt, haalt deze de inkomende Trace ID uit de metadata van het verzoek en maakt een child span aan die dezelfde ID erft. De child span logt de starttijd, duur, attributen (modelnaam, gebruikte tool) en eventuele fouten. Het proces herhaalt zich voor elke downstream agent, waardoor een boomstructuur ontstaat die de logische flow van de totale taak weerspiegelt.

OpenTelemetry ondersteunt ook Baggage, een lichtgewicht drager voor aangepaste key-value paren. Door een “drill-id” of andere zakelijke context aan de baggage toe te voegen aan de top van de trace, erft elke downstream span automatisch die identifier. Een span processor promoot de baggage vervolgens naar reguliere attributen, waardoor het eenvoudig is om alle spans op te vragen die bij een specifieke incident-oefening horen.

Hoe de nieuwe tracing-interface eruitziet

Met de instrumentatie op zijn plaats, toont Azure Monitor (of een andere OpenTelemetry-compatibele backend) een visuele hiërarchie:

  • Agentnaam / ID – laat zien welke component de operatie heeft uitgevoerd.
  • Toolgebruik – legt vast welke externe service of functie is aangeroepen.
  • Modelversie – logt het exacte gebruikte LLM, wat nuttig is voor het bijhouden van regressies na een modelupgrade.
  • Tokenverbruik – legt vast hoeveel tokens naar het model zijn verzonden en ervan zijn ontvangen, wat teams helpt de kosten te beheren.
  • Latency / duur – markeert waar knelpunten optreden, of dat nu in model-inferentie of tool I/O is.

In het voorbeeld van de incident-oefening genereert de root span van de commander child spans voor elke specialist, en elke specialist genereert verdere kinderen voor zijn model-aanroepen. Door op een node te klikken, wordt de volledige set attributen onthuld, zodat een engineer direct de details van elke operatie ziet.

De belangen voor AI-centrische operaties

  • Snelheid van root-cause analyse – Teams traceren een fout terug naar de exacte span die een fout veroorzaakte, wat de gemiddelde tijd tot oplossing verkort.
  • Kosteninzicht – Tokenaantallen staan naast de latency, waardoor finance ongecontroleerd gebruik kan signaleren voordat de cloudfacturen exploderen.
  • Prestatieoptimalisatie – Spans met een hoge latency over verschillende agents wijzen naar plekken waar caching, modelselectie of het herontwerpen van tools de doorvoer kan verhogen.

Wat je verder kunt verwachten

Projecten gebouwd op LangChain, de OpenAI SDK of andere orchestratielagen kunnen dezelfde semantische conventies voor GenAI adopteren, wat de weg vrijmaakt voor traces die stromen over cloudproviders en on-premise implementaties.

Organisaties hoeven alleen de OpenTelemetry SDK in hun agents in te schakelen en gegevens naar Azure Monitor of een open-source collector te sturen.

Conclusie

OpenTelemetry biedt multi-agent AI-systemen de ontbrekende lijm die een verzameling losse logs verandert in een samenhangend verhaal. Door een enkele Trace ID te verspreiden over heterogene LLM's, routers en tool-aanroepen, kunnen ontwikkelaars fouten lokaliseren, kosten monitoren en prestaties optimaliseren zonder de tracing-infrastructuur opnieuw uit te hoeven vinden.