AgentOps: Session-Telemetrie für Python-Agenten, mit Self-Hosting-Option

Welches Problem die Session als Einheit löst

Ein einzelner LLM-Aufruf ist einfach zu loggen. Ein Agentenlauf ist es nicht. Zwischen dem ersten Prompt und dem letzten Tool-Result liegen bei CrewAI oder AG2 mehrere Modelle, mehrere Rollen und mehrere Fehlerpfade, und die Frage lautet selten "was hat Modell X geantwortet", sondern "warum hat der Lauf um Schritt vier die falsche Datei geschrieben". Genau hier setzt AgentOps an: Das README beschreibt das Produkt als Observability- und DevTool-Plattform für AI Agents, mit Session Replays, Step-by-Step Execution Graphs und LLM Cost Management als den vier hervorgehobenen Fähigkeiten.

Die Zielgruppe ist damit enger, als die Themenliste vermuten lässt. Wer einen einzelnen Chatbot mit einem Modell betreibt, bekommt wenig zusätzlichen Nutzen. Wer dagegen mehrere Frameworks parallel einsetzt, also etwa CrewAI für Rechercheketten und die OpenAI Agents SDK für Tool-Aufrufe, für den ist die Vereinheitlichung interessant: Das README nennt CrewAI, Agno, OpenAI Agents SDK, LangChain, Autogen, AG2 und CamelAI als Integrationen. Ein gemeinsames Telemetrieformat über diese Frameworks hinweg ist der eigentliche Verkaufsgrund, nicht das Dashboard allein.

Wie das SDK Telemetrie erzeugt: init, Session, Span

Der Datenfluss beginnt mit agentops.init() am Programmanfang und endet mit agentops.end_session('Success') am Programmende. Dazwischen sammelt das SDK laut README automatisch Analytics über alle LLM-Aufrufe. Das ist der Kern: keine manuellen Log-Aufrufe pro Modellaufruf, sondern Instrumentierung auf Bibliotheksebene.

Für feinere Struktur gibt es Dekoratoren. Das README zeigt aus agentops.sdk.decorators den Dekorator session, der eine Funktion als Session-Span markiert, also als Wurzel für alle untergeordneten Spans. Der Kommentar im Beispiel ist explizit: "Create a session span (root for all other spans)". Daraus lässt sich die Architektur ablesen, auch ohne den Quellcode: Sessions enthalten Spans, Spans bilden den Ausführungsgraphen, und die im README gezeigten Screenshots von Event Graphs und Session Replays sind die Visualisierung genau dieser Struktur. Der Ausdruck "one line at a time" im Abschnitt First class Developer Experience beschreibt die Absicht, die Instrumentierung schrittweise zu verdichten, statt sie von Anfang an vollständig auszurollen.

Was das README nicht zeigt, ist das Wire-Format. Ob Spans als OpenTelemetry-ähnliche Strukturen übertragen werden, ob es einen Batch-Export gibt und wie sich Sampling konfigurieren lässt, geht aus dem vorliegenden Material nicht hervor. Wer das für die Kapazitätsplanung braucht, muss die Dokumentation unter docs.agentops.ai lesen.

Installation und die zwei Zeilen, die den Datenpfad festlegen

Die Installation ist ein einzelner Befehl: pip install agentops. Danach folgt die Initialisierung mit einem API-Key, den das README über app.agentops.ai/settings/projects verlinkt. Der Key wird direkt an agentops.init() übergeben, im Beispiel als Positionsargument. Das ist bequem und gleichzeitig der Punkt, an dem die Architekturentscheidung fällt: Mit diesem Aufruf zeigt die Bibliothek auf einen gehosteten Endpunkt. Wer den Key nicht im Code haben will, muss ihn über eine Umgebungsvariable oder einen Konfigurationsmechanismus einspeisen. Welche Umgebungsvariablen das SDK liest, steht im vorliegenden README nicht, also lässt sich dazu hier keine Aussage treffen.

Für den selbst betriebenen Pfad verweist das README auf app/README.md im Repository, überschrieben mit "Run the App and Backend (Dashboard + API)". Der entscheidende Satz lautet: "The AgentOps app is open source under the MIT license. Explore the code in our app directory". Dashboard und API-Backend liegen also im selben Repository unter app/ und sind unter derselben Lizenz verfügbar. Das ist der einzige im Material belegte Weg, Telemetrie nicht an einen fremden Endpunkt zu senden. Ob der Self-Hosting-Pfad dieselben Funktionen abdeckt wie die gehostete Variante, sagt das README nicht.

Wo die Grenzen des Materials liegen

Das README ist ein Einstiegsdokument, keine Betriebsanleitung. Drei Dinge fehlen, die für eine Adoption relevant wären. Erstens die Frage der Datenhaltung: Wie lange Sessions gespeichert werden, ob es eine Löschfunktion gibt und wie personenbezogene Daten in Prompts behandelt werden, ist nicht beschrieben. Zweitens die Frage des Overheads: Das SDK instrumentiert LLM-Aufrufe, aber das README nennt keine Angaben dazu, ob Aufrufe synchron blockieren oder gepuffert gesendet werden. Drittens die Fehlersemantik. Wenn agentops.end_session('Success') nicht erreicht wird, weil der Prozess abstürzt, was passiert dann mit der Session? Das README beantwortet das nicht.

Ein weiterer Punkt ist die Framework-Abdeckung. Die Liste der Integrationen ist lang, aber sie ist eine Liste von Namen, keine Matrix mit Funktionsumfang. Ob Cost Tracking für alle genannten Anbieter gleich gut funktioniert oder ob es Unterschiede zwischen OpenAI, Anthropic, Mistral und lokal betriebenen Modellen über Ollama gibt, lässt sich aus dem Material nicht ableiten. Wer Kosten auf ein lokales Modell über Ollama zuordnen will, sollte das vor der Adoption mit einem Testlauf klären, statt sich auf die Themenliste zu verlassen.

Versionsrhythmus und was das für Upgrades bedeutet

Die letzten drei Releases liegen jeweils rund zwei Wochen auseinander: 0.4.19 am 1. August 2025, 0.4.20 am 15. August, 0.4.21 am 29. August. Das ist ein zügiger Rhythmus auf einer 0.x-Versionslinie. Der letzte Push ins Repository ist mit Juni 2026 datiert, also deutlich später als das jüngste Release. Beide Angaben zusammen deuten auf ein aktiv gepflegtes Projekt, aber die 0.x-Nummer ist der eigentliche Hinweis: Solange die Hauptversion 0 ist, sind Breaking Changes zwischen Minor-Versionen möglich. Ein Team, das agentops.init() in Produktionscode einbaut, sollte die Version in requirements.txt oder pyproject.toml festnageln und Upgrades bewusst durchführen, nicht bei jedem pip install -U mitnehmen.

Die Lizenz ist MIT, sowohl für das SDK als auch laut README für die App. Das ist permissiv: kommerzielle Nutzung, Modifikation und Weiterverbreitung sind zulässig, solange der Lizenztext und der Copyright-Hinweis beibehalten werden. Für ein Unternehmen bedeutet das vor allem, dass die Self-Hosting-Variante rechtlich unkompliziert ist. Eine rechtliche Einschätzung ersetzt das nicht, und die Nutzungsbedingungen des gehosteten Dienstes sind ein separates Thema, das die Repository-Lizenz nicht abdeckt.

Was ein Wechsel zu reinem OpenTelemetry kostet

Die naheliegende Alternative ist, Agenten direkt mit OpenTelemetry zu instrumentieren und Spans an ein beliebiges Backend zu senden. Der Unterschied liegt nicht im Ziel, sondern im Aufwand und in der Kopplung. OpenTelemetry gibt ein Protokoll und eine Semantik vor, aber keine Agenten-Semantik: Was ein Tool-Aufruf ist, was ein Modellaufruf, wie Kosten pro Span berechnet werden, muss man selbst definieren und pflegen. Dafür bleibt die Wahl des Backends offen, und es gibt keinen SDK-spezifischen Endpunkt, an den Daten fließen.

AgentOps tauscht diese Freiheit gegen Vorarbeit. Die Integrationen für CrewAI, AG2, LangChain und die OpenAI Agents SDK sind im SDK enthalten, die Kostenberechnung ist Teil des Produkts, und der Ausführungsgraph wird laut README ohne eigene Visualisierung geliefert. Der Preis dafür ist die Bindung an das AgentOps-Datenmodell. Wer später zu einem anderen Backend wechseln will, muss die Instrumentierung neu aufbauen. Wer ohnehin nur ein Backend braucht und dessen Semantik akzeptiert, spart mit AgentOps die Definitionsarbeit. Das ist eine Abwägung zwischen Zeit und Portabilität, keine Frage von besser oder schlechter.

Für wen sich der Einstieg lohnt und was vorher zu klären ist

Der stärkste Fall für AgentOps ist ein Team, das bereits mehrere Agenten-Frameworks im Einsatz hat und dessen Fehlersuche heute darin besteht, Prompt-Logs aus verschiedenen Quellen zusammenzusuchen. Dort ist der Gewinn konkret: eine Session-ID, ein Ausführungsgraph, eine Kostenübersicht. Der zweitstärkste Fall ist ein Team mit Datenschutzauflagen, das die App aus app/ selbst betreibt und damit die Kontrolle über den Telemetrie-Endpunkt behält. Der schwächste Fall ist ein einzelner Assistent mit einem Modell und ohne Tool-Aufrufe. Dort übersteigt der Integrationsaufwand den diagnostischen Nutzen.

Vor der ersten Zeile in Produktionscode sind drei Dinge zu prüfen, und alle drei lassen sich nur gegen die Dokumentation oder einen Testlauf klären, nicht gegen dieses README. Erstens: Welche Konfigurationswege akzeptiert agentops.init() außer dem direkten Key, und gibt es eine Umgebungsvariable. Zweitens: Welche Funktionen der gehosteten Variante fehlen im Self-Hosting-Pfad aus app/README.md. Drittens: Ob der Cost-Tracking-Pfad für die eigenen Modellanbieter vollständig ist. Wer diese drei Fragen beantwortet hat, kann entscheiden, ob die zwei Zeilen aus dem Quick Start in den eigenen Code gehören oder nicht.

Redaktionelles Fazit

Wer bereits CrewAI, AG2 oder die OpenAI Agents SDK einsetzt und Sessions mit Event-Graphen und Kostenzuordnung braucht, findet hier ein SDK, das laut README in zwei Zeilen eingebunden ist. Wer keine Telemetrie an einen externen Endpunkt senden darf, muss zuerst app/README.md lesen und die Self-Hosting-Route prüfen, bevor die erste Zeile agentops.init() im Produktivcode steht. Ohne geklärten Datenpfad ist die Bibliothek die falsche Wahl.

Offizielle Quellen

1. AgentOps-AI/agentops on GitHub
2. License: MIT
3. Project website
4. README
5. Releases