In den letzten beiden Posts haben wir den Agenten evaluiert und abgesichert. Er liefert gute Ergebnisse und läuft nicht aus dem Ruder.

Aber er ist immer noch Code auf einem Laptop. Kein anderes System kann ihn aufrufen. Niemand sieht, was er tut. Und wenn der Prozess abstürzt, ist alles weg.

Zwei Dinge fehlen: Sichtbarkeit und Erreichbarkeit.

Tracing: Sehen, was der Agent tut

Ein klassischer ML-Service hat vorhersagbare Metriken: Latenz, Throughput, Error Rate. Bei einem Agenten ist das anders. Ein Run kann 3 Knoten durchlaufen oder 8. Der Token-Verbrauch wächst mit jedem Schritt, weil jeder Knoten den akkumulierten Kontext aller vorherigen Schritte als Input bekommt. Standard-Monitoring-Metriken zeigen, dass ein Run lange dauerte — aber nicht warum und nicht welcher Knoten das Bottleneck war.

Tracing löst das. Jeder Graph-Aufruf wird zu einem Trace, jeder Knoten zu einem untergeordneten Run — mit Input, Output, Latenz und Token-Verbrauch. Statt einer aggregierten Zahl sieht man den Verlauf: Welcher Knoten hat wie lange gebraucht, wie viele Tokens verbraucht, und was hat er gelesen und geschrieben.

Das Bemerkenswerte: Für LangGraph-Agenten braucht man dafür keinen Code zu ändern. Drei Umgebungsvariablen reichen — und jeder graph.invoke()-Call wird automatisch getracet. Das ist kein Zufall, sondern eine Architektur-Eigenschaft: Tracing, Guardrails, Evaluation — alles wird von außen um den Agenten gelegt, nicht hineingebaut. Separation of Concerns.

LangSmith und die Datensouveränitäts-Frage

LangSmith als Tracing-Plattform funktioniert gut — aber alle Traces gehen an LangChain-Server. Bei sensiblen Daten (Kundendaten, Finanzdaten, interne Dokumente) ist das ein Problem.

Langfuse ist die Self-Hosted-Alternative: Open Source, auf eigener Infrastruktur deploybar, DSGVO-konform. Die Integration funktioniert über einen Callback-Handler — auch hier ohne Änderung am Agenten selbst. Für Produktion lässt sich Langfuse via Helm Chart auf Kubernetes deployen.

Das wird im nächsten Post relevant, wenn wir den gesamten Stack auf eigener Infrastruktur betreiben.

Welche Metriken für wen

Token-Monitoring ist direkt Kosten-Monitoring — was pro Run günstig wirkt, wird bei tausend Runs pro Tag schnell relevant. Aber nicht jeder schaut auf dieselben Metriken: ML-Engineers brauchen Latenz pro Knoten und Token-Verbrauch, Product Manager brauchen Kosten pro gelöstem Incident, DevOps braucht P99-Latenz und Throughput. Latenz interessiert alle drei — aus unterschiedlichen Gründen.

Und: Durchschnittswerte reichen nicht. Die Verteilung der Schrittanzahl ist eine eigenständige Metrik — sie zeigt, ob der Agent konsistent arbeitet oder ob Ausreißer auf Probleme hindeuten.

Der Agent als REST-Service

Ein Agent-Run kann je nach Aufgabe mehrere Sekunden bis Minuten dauern. Das ist oft zu lang für eine synchrone HTTP-Antwort — der Client würde warten, der Server wäre blockiert.

Die Lösung ist ein asynchrones Job-Pattern:

POST /incidents        → 202 Accepted, gibt job_id zurück (sofort)
GET  /incidents/{id}   → Status: pending → running → completed/failed
GET  /health           → Liveness-Check

Der Client schickt einen Request, bekommt sofort eine Job-ID zurück und pollt den Status. Der Agent läuft im Hintergrund. Das ist dasselbe Pattern, das man von Batch-Processing-Services kennt.

Ein Graph, viele Runs

Eine Eigenschaft von LangGraph, die sich beim Deployment auszahlt: Der kompilierte Graph ist stateless. Er kann als Singleton geteilt werden, weil jeder graph.invoke(state)-Call seinen eigenen State bekommt. Parallele Runs sind sicher — ähnlich wie eine Flask-View-Funktion, die auch als Singleton tausende Requests gleichzeitig bedient.

Die Guardrails aus dem vorherigen Post laufen dabei mit: Injection Detection, Circuit Breaker, Budget-Limiter, Output-Validierung — alles aktiv, alles von außen. Nur Human-in-the-Loop ist im API-Betrieb deaktiviert, weil ein input()-Aufruf die API blockieren würde.

Was bis zur Produktion fehlt

Das Setup aus diesem Post ist ein Startpunkt — kein Produktions-Deployment. Einige Lücken sind bewusst offen gelassen:

Authentifizierung ist die kritischste. Ohne API-Key kann jeder beliebig viele Requests einreichen — unkontrollierte Kosten, kein Audit-Trail.

Job-Persistenz ist die zweite: Jobs liegen im Speicher. Bei einem Neustart sind alle laufenden Jobs verloren. In Produktion gehört das in Redis oder eine Datenbank.

Skalierung ist die dritte: Ein einzelner Prozess mit Thread-Pool hat eine natürliche Grenze. In Produktion braucht man mehrere Instanzen mit einem gemeinsamen Job-Store.

Das echte Produktions-Deployment — auf Kubernetes, mit persistentem State und Self-Hosted-Tracing — ist Thema des letzten Posts in dieser Serie.

Ausblick

Der Agent ist jetzt evaluiert, abgesichert und lokal als Service erreichbar. Aber er ist noch abhängig von externen Diensten: LLM-API-Calls, Tracing an Cloud-Plattformen, Job-State im Speicher. Im letzten Post deployen wir den gesamten Stack in einen Kubernetes-Cluster — vom Agent-Code über das LLM bis zum Tracing, mit persistentem State. Vollständig datensouverän.

Code und Details: Tracing-Setup mit LangSmith und Langfuse-Alternative, REST-Service mit FastAPI und Docker — alles auf GitHub dokumentiert: → agentic-ai / Phase 4, Block 1: Observability → agentic-ai / Phase 4, Block 4: Deployment

Ich bin ML Engineer mit Fokus auf Self-Hosted AI und Datensouveränität. Ich helfe Unternehmen im DACH-Raum, ML- und AI-Systeme auf eigener Infrastruktur zu betreiben. Offen für Austausch und spannende Projekte — schreib mir auf LinkedIn.