Fast niemand nimmt sich vor, eine KI-Agenten-Plattform zu bauen. Am Anfang soll nur ein Agent live gehen. Doch der produktive Betrieb stellt Anforderungen, und für jede davon gibt es ein spezialisiertes Tool. So wächst der Stack schrittweise um ein Framework, eine Vektordatenbank, ein Observability-Tool, ein Evaluationstool, ein Experiment-Tool, einen Secrets Manager und Integrationscode, der alles miteinander verbindet.
Jedes einzelne Element ist eine vernünftige Wahl. Die Kosten stecken nicht in einem bestimmten Tool, sondern in den Übergängen dazwischen. Diese Rechnung erscheint später als Wartungsaufwand statt als eigene Position im Budget.
Der daraus entstehende Stack
Ordnet man die Anforderungen eines produktiven Agenten den Tools zu, die Teams dafür auswählen, entsteht ein vertrautes Bild. In jeder Kategorie stehen führende Produkte. Keines davon wurde dafür entwickelt, die anderen zu verstehen.
Bündle den Agenten-Stack in einer Runtime
Retrieval, Observability, Evaluation, A/B-Tests und Verbindungen laufen auf einer Plattform. Dadurch entfällt eigener Wartungscode an den Übergängen.
Der Aufwand, den niemand einkalkuliert
Addiert man die Abonnements, wirkt die Summe überschaubar. Der teure Teil steht auf keiner Rechnung.
Integrationscode bleibt dauerhafter Wartungsaufwand
Die Verbindung vom Framework zum Evaluationstool, von dessen Ergebnissen zum Experiment-Tool und von den Traces zum Observability-Backend ist individueller Code. Er hat keinen Product Owner, fällt bei einem Upgrade als Erstes aus und ist genau der Code, den niemand pflegen möchte.
Versionsdrift verstärkt sich
Sechs Tools bedeuten sechs Release-Zyklen. Ein Breaking Change in einem davon wirkt sich auf den Integrationscode aus. Statt den Agenten zu verbessern, verbringt das Team einen festen Anteil jedes Sprints damit, die Übergänge intakt zu halten.
Der Bereitschaftsdienst muss den gesamten Stack beherrschen
Wenn sich ein Agent um zwei Uhr morgens falsch verhält, lautet die Frage: Welche Schicht ist ausgefallen? Die Antwort erfordert den Abgleich von Tools ohne gemeinsame Request-ID. Ohne einen durchgängigen Trace vom Trigger über den Tool-Call bis zur Evaluation muss das Team bei der Fehlersuche Informationen aus mehreren Dashboards zusammenführen.
Das ähnelt stark dem Self-Hosting
Der Aufbau entspricht eigener Infrastruktur, nur eine Ebene höher: Die Kosten entstehen durch Menschen und Zeit, nicht durch Compute. Konkrete Zahlen zur Infrastrukturvariante stehen im Beitrag über die versteckten Kosten des Self-Hostings von KI-Agenten und unserem TCO-Vergleich von verwaltetem Betrieb und Self-Hosting. Der Aufwand des zusammengestellten Stacks kommt noch obendrauf.
Wann ein eigener Stack die richtige Wahl ist
Einen Stack selbst zusammenzustellen ist nicht grundsätzlich falsch. Wenn eine dieser Schichten das Produkt ist, etwa weil das Unternehmen Observability anbietet oder Retrieval-Qualität den Wettbewerbsvorteil bildet, lohnt sich die vollständige Kontrolle. Eine allgemeine Plattform kann hier Grenzen setzen. Das gilt auch für ungewöhnliche Anforderungen, die kein integriertes Produkt erfüllt, oder für einen bestehenden Stack, den das Team hervorragend kennt und aus dem es nicht herauswachsen wird. Eigenentwicklung lohnt sich für Komponenten, die den Wettbewerbsvorteil des Produkts ausmachen. Standardaufgaben kann eine integrierte Plattform übernehmen.
Was eine integrierte Plattform verändert
Die Alternative ist eine Plattform, auf der diese Schichten bereits ein gemeinsames Datenmodell verwenden. Wir bündeln Retrieval, Observability, Evaluation, A/B-Tests, Verbindungen und Secrets in einer Runtime: Ein Trace reicht vom Trigger über den Tool-Call bis zum Judge-Score, Upgrades sind Aufgabe der Plattform und eigener Integrationscode entfällt. Teams definieren den Agenten in YAML, schreiben Tools in Python und pushen nach Git. Einen Überblick darüber, wo Agenten laufen, bietet unser Leitfaden zu Deployment-Plattformen für KI-Agenten 2026.