Das Gespräch beginnt immer mit einem Werkzeugnamen. Irgendwer hat eine Demo gesehen, irgendwer einen Thread gelesen, und die Frage, die im Meeting landet, ist: hosten wir Langfuse selbst oder zahlen wir für eine Plattform? Es ist die falsche Frage, und drei Wochen später merkt man es: Tracing steht, das Dashboard existiert, und niemand kann sagen, ob der Agent schlechter antwortet als letzten Monat.
Die These in einem Satz: Observability für KI-Agenten ist kein Werkzeug, sondern vier Schichten, die du getrennt entscheidest — und offene Bausteine decken heute alle vier ab. Was bricht, ist nicht das Werkzeug — die offenen funktionieren — sondern die zwei Dinge, die niemand in die Vergleichstabelle schreibt: die Datenkonvention ist noch in Entwicklung und ihre Dokumentation ist umgezogen, und „offen“ meint mindestens drei Lizenzen, die dir nicht dasselbe erlauben.
Die Werkzeuge für Observability von KI-Agenten, die du selbst hosten kannst: vier Schichten, nicht eine
Der Anfangsfehler ist, das als einen einzigen Kauf zu behandeln. „Observability“ wird benutzt, als wäre es ein Produkt, dabei sind es bei einem Agenten vier verschiedene Aufgaben, die unterschiedlich scheitern und von denen du fast nie alle vier am selben Tag brauchst. Sie zu trennen ist das, was aus einer Markenwahl eine Engineering-Entscheidung macht.
| Schicht | Welche Frage sie beantwortet | Was ohne sie passiert |
|---|---|---|
| Korrelierte Traces | Was hat der Agent getan, in welcher Reihenfolge, mit welchen Werkzeugen und mit welcher Eingabe pro Schritt? | Du debuggst blind: du hast das Endergebnis und keine Möglichkeit zu sehen, in welchem Schritt es kippte |
| Evaluierung vor dem Produktivgang | Ist diese Prompt- oder Modelländerung besser als die Baseline oder schlechter? | Jede Änderung ist eine Wette, und der einzige Test ist zu warten, bis sich jemand beschwert |
| Kostenzuordnung | Was kostet jeder Fall, jeder Agent, jedes Werkzeug — nicht die aggregierte Rechnung? | Du siehst zum Monatsende die Summe des Anbieters und kannst sie weder zuordnen noch kappen |
| Drift-Erkennung | Antwortet er noch wie vor einem Monat, mit demselben Modell darunter? | Die Qualität rutscht langsam, klassisches Monitoring zeigt alles grün, und ein Kunde findet es zuerst |
Die ersten zwei deckt heute jeder ernsthafte offene Baustein ab. Die dritte hängt davon ab, dass du von Anfang an in der richtigen Granularität instrumentiert hast — später hinzufügen heißt neu instrumentieren. Die vierte ist keine Funktion, die man einschaltet: sie ist eine Kadenz, die jemand ausführen muss, und sie ist die, die am häufigsten ohne Verantwortlichen endet. Warum Drift kein Fehler, sondern ein Abrutschen ist, entwickeln wir in was passiert, wenn sich das KI-Modell unter deinen Automatisierungen ändert; hier zählt, welche Schicht es hätte fangen müssen.
Was zuerst bricht, ist nicht das Werkzeug: es ist die Konvention
Damit die vier Schichten miteinander reden, müssen alle dieselben Dinge gleich benennen: was ein Modellaufruf ist, was ein Agentenaufruf ist, was eine Werkzeugausführung ist. Das ist eine semantische Konvention, und es ist der Teil des Stacks, den fast niemand vor der Auswahl prüft. Es ist auch der am wenigsten gefestigte.
Zwei konkrete Fakten, beide an der Primärquelle prüfbar. Erstens: die GenAI-Konventionen von OpenTelemetry — die gen_ai.*-Attribute — sind weiterhin als in Entwicklung markiert, nicht als stabil. Zweitens, und das ist das, was dich wirklich beißen wird: diese Dokumentation lebt nicht mehr dort, wohin deine Suchmaschine dich schickt. Die historische Seite im Semantic-Conventions-Repository sagt jetzt nur noch, dass der Inhalt in das GenAI-Konventions-Repository verschoben wurde und die alte nicht mehr gepflegt wird.
Darüber läuft eine zweite Konvention: OpenInference, die semantische Schicht, die Arize pflegt und auf der sein offenes Werkzeug arbeitet. Kein Problem an sich — Exporter übersetzen — aber der Grund, warum zwei Bausteine, beide „OpenTelemetry-kompatibel“, mit Span-Bäumen ankommen können, die nicht zusammenpassen. Entscheide dich für eine und mach sie zum Hausstandard; lass nicht jedes instrumentierende Team selbst wählen.
„Offen“ meint drei verschiedene Lizenzen, und nur eine erlaubt dir, was du denkst
Hier gleicht der offene Stack der Debatte, die es in der Automatisierung längst gibt, viel mehr, als irgendwer zugibt. Es ist genau die Falle, die wir in Open-Source-Werkzeuge für KI-Automatisierung auseinandernehmen: „0 € Lizenz“ ist nicht „0 € Kosten“, und „Open Source“ ist nicht immer, was das Wort suggeriert. Bei Agenten-Observability ist es dasselbe, mit einem eigenen Dreh.
| Baustein | Was die eigene Dokumentation sagt | Was das in der Praxis bedeutet |
|---|---|---|
| Langfuse | Open Source und mit Docker auf eigener Infrastruktur selbst hostbar; einige Zusatzfunktionen brauchen einen Lizenzschlüssel | Für den Betrieb der eigenen Flotte reicht der Kern. In der Funktionsliste zum Self-Hosting sind drei als Enterprise markiert — Organisationsersteller, Instance-Management-API und UI-Anpassung |
| Arize Phoenix | Unter Elastic License 2.0 veröffentlicht; Self-Hosting auf eigener Infrastruktur oder im eigenen Cloud-Konto ist kostenlos und vollständig erlaubt, ohne bezahlte Funktionen | Intern genutzt hast du keine beschnittenen Funktionen. Die ELv2 ist nicht OSI-anerkannt, und ihre zentrale Einschränkung ist, es Dritten als Managed Service anzubieten |
| OpenTelemetry | CNCF-Projekt; die GenAI-Konventionen sind in Entwicklung | Die Rohrleitung ist der solideste und am wenigsten diskutable Teil des Stacks. Die Instabilität sitzt im Vokabular, nicht im Transport |
Die operative Lesart: baust du das für den eigenen Betrieb, erlauben es dir alle drei Lizenzen, und das juristische Gespräch ist kurz. Willst du irgendwann das Dashboard an deine Kunden als Service weiterverkaufen — eine Agentur, ein Managed-Service-Anbieter — ist die ELv2 genau das, was es verbietet, und das sollte man wissen, bevor man das Geschäft darauf baut, nicht danach.
Ab wann sich der offene Stack nicht mehr rechnet (und es ist keine Zahl von Agenten)
Erwartet wird hier eine Zahl: bis X Agenten selbst hosten, ab X kaufen. Diese Zahl existiert nicht, und wer sie dir gibt, verkauft dir die Seite, die ihm passt. Die Schwelle ist keine Frage des Volumens, sondern der Garantien.
Der Anbieter sagt es selbst in seiner Dokumentation, und es ist der ehrlichste Satz der ganzen Kategorie. In der Tabelle der Deployment-Optionen von Langfuse wird der Start über Docker Compose beschrieben als eine einzelne virtuelle Maschine ohne Hochverfügbarkeit, ohne Skalierung und ohne Backups, und beim produktiven Self-Hosting — Kubernetes, AWS, Azure, GCP — steht die Verantwortung in genau einer Spalte: deine Infrastruktur.
Da liegt die echte Schwelle, und sie hat nichts damit zu tun, wie viele Agenten du hast. Der offene Stack rechnet sich nicht mehr an dem Tag, an dem das Dashboard kritische Infrastruktur wird: wenn jemand von außen den Ausfall merkt, wenn der Trace der Beweis ist, den du brauchst, um einem Kunden oder einem Prüfer zu antworten, oder wenn sechs Monate Traces aufzubewahren eine Anforderung wird und keine Vorliebe. An dem Tag wählst du kein Werkzeug mehr, du entscheidest, wer nachts aufsteht, um es zu reparieren. Das ist dieselbe Frage — für Automatisierungen gestellt — wie wer antwortet, wenn eine Automatisierung ausfällt.
Man sollte außerdem die Skalenzahlen jedes Anbieters mit Abstand lesen. Langfuse gibt in seiner Dokumentation an, mehr als 90 Milliarden Observations pro Monat zu verarbeiten und von 21 der Fortune 50 genutzt zu werden. Das sind Herstellerangaben über das eigene Produkt, keine unabhängige Messung und kein Ergebnis von uns; sie sagen, dass der Baustein Last trägt, nicht was er bei dir tragen wird.
Wann du den offenen Stack NICHT bauen solltest
Vier Situationen, in denen dieses Projekt ein Umweg ist und kein Fortschritt. Alle vier sind real und alle vier kommen als gute Idee verkleidet:
- Du hast einen Agenten und er ist nicht instrumentiert. Dir fehlt keine Observability-Plattform, dir fehlt das Tracing. Instrumentiere zuerst mit gepinnter Konvention und entscheide danach, wohin du es schickst; die umgekehrte Reihenfolge lässt dich ein Werkzeug wählen, ohne Daten darüber, was du sehen musst.
- Niemand wird das Dashboard ansehen. Ein Dashboard ohne Rufbereitschaft ist keine Observability, sondern Infrastrukturkosten mit Diagrammen. Gibt es keine namentlich benannte Person mit Schicht, bau erst das.
- Dein Problem ist Qualität, nicht Gesundheit. Lautet die Beschwerde „er antwortet schlecht“, repariert kein Trace das: du brauchst eine Bewertungsmatrix und eine Fallsammlung, und das ist eine andere Arbeit — wir behandeln sie in die Qualität von KI-Agenten bewerten.
- Der Agent schreibt in ein System of Record und hat noch keine Zugriffsmatrix. Observability sagt dir, was er getan hat; sie verhindert nicht, dass er es kann. Diese Reihenfolge steht in welche Rechte ein KI-Agent bekommen soll, und sie kommt zuerst.
Was im ersten Monat gemessen wird
Das Zeichen, dass der Stack wirklich steht, ist nicht, dass das Dashboard lädt. Es sind vier Fragen, die du vorher nicht beantworten konntest und jetzt in einer Minute beantwortest, mit dem Trace vor dir:
- Von den Ausfällen des Monats: wie viele hat ein Alarm entdeckt und wie viele eine Person von außen. Das ist die einzige Metrik, die sagt, ob das Dashboard etwas bringt.
- Was der teuerste Fall gekostet hat, und warum. Lautet die Antwort „lässt sich nicht aufschlüsseln“, fehlt die Zuordnungsschicht, Token-Diagramm hin oder her.
- Wie lange du brauchst, um zu rekonstruieren, was in einem konkreten Fall von vor drei Wochen passiert ist. Sind es Stunden, sind die Traces da, aber die Korrelation nicht.
- Wie viele Prompt- oder Modelländerungen ohne Baseline durchgegangen sind. Diese Zahl sollte null sein, und im ersten Monat ist sie es fast nie.
Keine der vier ist eine Metrik über das Werkzeug. Es sind Metriken über den Betrieb, und darum endet der offene Stack nicht am Tag des Deployments: was Docker dir gibt, ist die billige Hälfte. Wenn das Team diese laufende Arbeit nicht tragen kann, heißt das Gespräch KI im Produktivbetrieb überwachen als Funktion, nicht als Dashboard.
Der Satz für das nächste Meeting
Wenn das nächste Mal gefragt wird, welches Agenten-Observability-Werkzeug wir aufsetzen, ist die nützliche Antwort kein Name. Sie lautet: sag mir, welche der vier Schichten dir fehlt, welche Konvention du pinnst, und wer aufsteht, wenn das kippt. Mit diesen drei Antworten entscheidet sich das Werkzeug von selbst, und es ist fast immer das offene.