Observability van AI-agents: zien wat een agent in realtime doet

Hoe meer een AI-agent aan autonomie wint, hoe centraler de vraag "wat heeft hij precies gedaan?" wordt. Een agent die continu draait, via meerdere kanalen wordt aangesproken, tools aanroept en soms werk delegeert aan subagents, produceert activiteit die met het blote oog moeilijk te volgen is. Observability is het technische antwoord op dat probleem: zichtbaar, traceerbaar en begrijpelijk maken wat er werkelijk binnen het systeem gebeurt.

Definitie in detail

Observability, in de brede zin van het woord binnen software engineering, is het vermogen om de interne toestand van een systeem te begrijpen door te kijken naar wat het naar buiten toe produceert, doorgaans traces, metrieken en logs. Dat is de definitie die OpenTelemetry hanteert, de open referentiestandaard voor software-instrumentatie, gedragen door talloze leveranciers van observability-tools. Deze drie soorten gegevens spelen complementaire rollen: traces volgen een aanvraag doorheen een gedistribueerd systeem, logs registreren gebeurtenissen met tijdstempel die al dan niet aan een precieze aanvraag zijn gekoppeld, en metrieken aggregeren cijfermatige metingen in de tijd.

Observability van agents past ditzelfde principe toe op het specifieke geval van een autonome AI-agent. Er bestaat nog geen enkele, breed gestabiliseerde norm die precies vastlegt wat agentische observability moet dekken, in tegenstelling tot klassieke software-observability, die met OpenTelemetry al een volwassen standaard kent. In de praktijk convergeren de platformen die agents laten draaien echter naar gedeelde behoeften: weten welke actie een agent heeft uitgevoerd, op welke tool, op welk moment, met welk resultaat, en op initiatief van welke trigger (een gesprek, een e-mail, een geplande taak).

Dat is geen technische luxe voor grote teams alleen. Zodra een agent kan handelen zonder systematische validatie op elke stap, wordt observability de concrete manier om achteraf te antwoorden op de vraag "waarom heeft hij dat gedaan?", of om afwijkend gedrag op te sporen voordat het een echt probleem veroorzaakt.

Hoe het werkt

Concreet steunt de observability van een agent op drie opeenvolgende lagen. De eerste is het vastleggen van gebeurtenissen: elke beslissing, elke tool-aanroep, elke betekenisvolle redeneerstap wordt geregistreerd op het moment dat ze plaatsvindt, met een tijdstempel, een status (bezig, geslaagd, mislukt) en de oorsprong van de trigger. De tweede is structurering: deze ruwe gebeurtenissen worden gecategoriseerd (een actie op een bestand wordt niet op dezelfde manier gelogd als een aanroep van een externe tool of een redeneerstap van het model), zodat er efficiënt gefilterd en gezocht kan worden. De derde is weergave: een interface of export waarmee een mens deze activiteit kan doorlopen, voor een specifieke agent of voor een hele organisatie.

Een goed systeem voor agentische observability onderscheidt ook gedelegeerd werk: wanneer een agent een subtaak toevertrouwt aan een tijdelijke subagent, moet die delegatie zichtbaar blijven in de tijdlijn van de bovenliggende agent, anders wordt een deel van het werkelijke werk onzichtbaar.

Concreet voorbeeld met Atako

Bij Atako steunt de observability per agent op een realtime activiteitentijdlijn: elke gebeurtenis wordt daarin gecategoriseerd (web, bestanden, geheugen, code, integratie, planning, delegatie, redenering van het model, overig), met een status (bezig, geslaagd, mislukt), een duur en een precieze oorsprong (chat, e-mail, webhook, geplande taak, bericht tussen agents, subagent, of systeem). Een apart paneel, "Tool logs", geeft afzonderlijk elke integratieaanroep van de agent weer, met het resultaat (geslaagd, geweigerd, mislukt).

Deze observability per agent wordt aangevuld met een bedrijfsbreed overzicht, voorbehouden aan beheerders: een pagina "Integration logs", filterbaar op team, agent, leverancier en datum, met een CSV-export tot 50.000 regels, plus een geaggregeerd overzicht van het gebruik per integratieleverancier. Elke gelogde aanroep bewaart de betrokken agent, de gebruikte verbinding, de leverancier, de precieze actie, de argumenten (met gevoelige velden zoals de inhoud van een e-mail of een zoekopdracht systematisch gemaskeerd), de status, de HTTP-code van de leverancier, de latency en het tijdstempel. De vangrails voor permissies (de grants) en observability werken hand in hand: het ene beslist of een actie is toegestaan, het andere houdt bij wat er werkelijk is gebeurd.

Veelgemaakte fouten

Een veelgemaakte fout is observability verwarren met een gewoon foutenlogboek. Een observeerbaar systeem meldt niet alleen wanneer iets breekt, het geeft ook zicht op de normale werking, wat het mogelijk maakt om onverwacht gedrag te begrijpen, zelfs wanneer technisch niets is mislukt.

Tweede fout: denken dat observability verhindert dat een agent verkeerd handelt. Het is geen blokkeermechanisme, het is een zichtbaarheidsmechanisme. Het wordt gecombineerd met permissies en, voor gevoelige acties, met een punt van menselijke validatie, maar vervangt geen van beide.

Derde fout: observability voorbehouden aan beheerders zonder ze toegankelijk te maken voor de teams die de agent dagelijks daadwerkelijk gebruiken. Nuttige observability moet de persoon die een agent heeft aangemaakt of gebruikt in staat stellen zijn gedrag te begrijpen, niet alleen een geïsoleerde technische rol.

Ten slotte is het onderschatten van het belang van delegaties aan subagents in de activiteitentijdlijn een klassieke fout. Een agent die een subtaak delegeert, blijft in de ogen van de gebruiker verantwoordelijk voor het resultaat: als die delegatie niet duidelijk in de tijdlijn verschijnt, wordt een deel van het werkelijke werk onzichtbaar en achteraf onbegrijpelijk.