Agentic AI

In den bisherigen Posts haben wir einen Agenten von Grund auf gebaut, ihm ein Fundament gegeben, Multi-Agent-Koordination untersucht, Evaluation und Guardrails implementiert und den Agenten als lokalen Service exponiert. Jetzt der letzte Schritt: Alles auf eigene Infrastruktur. Kein API-Call verlässt das Netzwerk. Das Szenario: Ein MLflow-Agent im Cluster Der Agent, den wir in dieser Phase bauen, hat einen konkreten Zweck: Er greift direkt auf MLflow zu — Experimente vergleichen, Modell-Deployments prüfen, Alias-Strategien abfragen. Ohne UI-Navigation, ohne manuelle API-Calls. Stattdessen natürliche Sprache: “Welche Modelle sind im Status Live?” — und der Agent ruft die richtigen Tools auf. ...

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. ...

Im letzten Post haben wir gemessen, wie gut ein Agent arbeitet. Aber Evaluation beantwortet nur die Frage “wie gut?” — nicht “wie sicher?” Der Unterschied ist fundamental: Ein klassisches ML-Modell macht falsche Vorhersagen. Ein Agent kann falsche Aktionen ausführen — Tool-Calls, Deployments, Datenbankschreibvorgänge. Das eine ist ein Qualitätsproblem. Das andere kann konkreten Schaden anrichten. Deshalb brauchen Agenten Guardrails. Nicht als optionales Feature, sondern als Voraussetzung für den produktiven Einsatz. Fünf Schichten, ein Prinzip Die Guardrails werden von außen um den Agenten gelegt — ohne den Agenten-Code zu ändern. Das ist bewusst so: Je mehr man den Agenten selbst ändern muss, um ihn abzusichern, desto schlechter ist die Architektur. Fachlogik und Sicherheitslogik gehören in getrennte Schichten. ...

Im letzten Post haben wir Agenten auf mehrere Schultern verteilt — Handoff, Supervisor, Swarm. Aber egal ob ein Agent oder zehn: Woher weiß man, ob sie gut arbeiten? Bei einem klassischen ML-Modell gibt es klare Metriken: Accuracy, F1-Score, AUC. Man hat ein Testset, lässt das Modell laufen und bekommt eine Zahl. Besser oder schlechter — eindeutig. Bei Agenten ist das anders. Das LLM als zentrale Komponente ist nicht-deterministisch — derselbe Input kann zu unterschiedlichen Pfaden führen. Die Anzahl der Schritte variiert. Und “richtig” ist oft eine Einschätzung, keine Ja/Nein-Entscheidung. War die Diagnose vollständig? Waren die Maßnahmen umsetzbar? Hat der Agent halluziniert? ...

Im letzten Post haben wir dem Agenten ein Fundament gegeben — LangGraph für Struktur, MCP für standardisierte Tools. Das Ergebnis: ein einzelner Agent, der verschiedene Tool-Quellen kombiniert und dessen Kontrollfluss transparent und testbar ist. Aber irgendwann reicht ein einzelner Agent nicht mehr aus. Nicht weil er zu wenig Tools hat, sondern weil die Aufgabe so komplex wird, dass ein einzelnes LLM zu viele Rollen gleichzeitig übernehmen muss. Es soll analysieren, Maßnahmen ableiten und einen Bericht schreiben — alles in einem Kontext. Je mehr Verantwortung man einem Agent gibt, desto größer wird der Kontext und desto wahrscheinlicher wird Halluzination. ...

Im letzten Post haben wir einen Agenten von Grund auf gebaut — ohne Framework, direkt gegen die Anthropic API. Das Ergebnis: ein funktionierender ReAct-Agent mit Calculator und Wikipedia als Tools. Funktioniert. Aber bei genauerem Hinsehen zeigen sich schnell einige Grenzen: Bei einem Crash startet der Agent von vorne — es gibt kein Checkpointing. Der Loop ist linear — bedingte Verzweigungen lassen sich zwar mit if/else einbauen, werden aber schnell unübersichtlich, intransparent und schwer wartbar. ...

Wenn man über Agenten redet, wird wie selbstverständlich davon ausgegangen, dass man sie mit Tools wie LangChain, LangGraph, CrewAI oder AutoGen baut. Das macht auch absolut Sinn. Wenn man aber gerade erst beginnt, sich mit Agenten zu beschäftigen, dann empfehle ich, zumindest einmal einen Agenten von Hand zu implementieren bzw. seine Komponenten und ihr Zusammenspiel ohne Framework zu betrachten. Ich für meinen Teil habe damit sehr gute Erfahrungen gemacht. Man entwickelt ein tieferes Verständnis davon, was einen Agenten ausmacht und versteht auch die Abstraktionen der Frameworks besser. ...