Du hast einen KI-Agenten programmiert. Er kann reasoning, Daten aus Millionen Dokumenten suchen, Schritte planen. Aber im Unternehmen tritt er auf der Stelle. Kein Fortschritt. Frustration. Kommt dir bekannt vor?
Es liegt nicht an den Modellen. Die sind heute gut genug. Das Problem ist die Infrastruktur, auf der sie laufen. Das sagten drei Infrastruktur-Chefs auf der VB Transform 2026: Animesh Singh von LinkedIn, Desiree Gosby von Walmart und Sami Ghoche von Zendesk. Alle drei waren beim Skalieren von KI-Agenten auf Probleme gestoßen. Ihr Fazit: Die Probleme lagen nicht an den Modellen, sondern an der Infrastruktur.
Stell dir die klassische Unternehmens-IT wie ein altes Straßennetz vor. Gebaut für langsame Fußgänger, die an jeder Kreuzung anhalten. KI-Agenten sind wie autonom fahrende Sportwagen, die keine Zeit für Ampeln haben – es knallt. Genau das passierte.
LinkedIn: Kubernetes war der Flaschenhals
Bei LinkedIn stieß Singh auf zwei Hindernisse. Der erste war Kubernetes. Der Container-Orchestrator startet Container auf Anfrage – das dauert Sekunden. Für Menschen ist das okay, aber KI-Agenten arbeiten in Millisekunden. Singhs Team änderte den Ansatz: Statt Container bei Bedarf zu starten, legen sie jetzt vorgefertigte Container-Pools an, in die agentische Workloads in Echtzeit ein- und ausgeswappt werden. Das löste das erste Problem.
Der zweite war schwieriger. LinkedIn erlaubte Agenten, ihre eigene Orchestrierung zu steuern – sie sollten selbst entscheiden, welche Schritte als Nächstes kommen. Ein fünfteiliges Evaluierungssystem sollte Halluzinationen unterbinden. Trotzdem traten sie auf. Singh erkannte das strukturelle Problem: Ein LLM, das die Ausgabe eines anderen LLMs bewertet, hat denselben Denkfehler wie das, was es bewertet. LinkedIn baute das System um: 80 Prozent des Workflows sind jetzt deterministischer Code, skriptgesteuert. LLMs kommen nur dort zum Einsatz, wo Reasoning nötig ist. Jeder Schritt protokolliert seine Ergebnisse, bevor es weitergeht.
Walmart: Der Erfolg wurde zum Problem
Bei Walmart sah die Hürde anders aus. Desiree Gosby ließ ein Agent-Harness direkt an die Mitarbeiter ausrollen – ein Werkzeug, mit dem selbst Citizen Developer eigene Agenten bauen können. Es ging viral. Plötzlich entstanden Dutzende Agenten für dieselben Probleme. Keine Koordination, keine Governance. Die Lösung war nicht, das Harness zurückzuholen, sondern eine Governance-Struktur aufzubauen, die Duplikate erkennt, die beste Version eines Agenten auswählt und in Produktion bringt – ohne dass Engineering den Prozess verlangsamt.
Gosby sagte: Engineering soll nie wieder der Engpass sein. Stattdessen sollen die Mitarbeiter innovativ sein können, während die Infrastruktur die Qualität sichert.
Zendesk: Die Datenflut zähmen
Sami Ghoche von Zendesk hatte es mit einer anderen Art von Infrastruktur zu tun: den Datenpipelinen. Zendesk sitzt auf rund 20 Milliarden Kundengesprächen – ein großer Bestand. Der naive Ansatz wäre, alles in ein großes Kontextfenster zu stopfen und ein LLM daraus Agenten generieren zu lassen. „Das funktioniert nicht“, sagte Ghoche. Stattdessen investierte Zendesk massiv in Datenpipelines, die die relevanten Informationen filtern und strukturieren, bevor ein Agent sie sieht.
Große Kontextfenster sind verlockend, aber sie ersetzen keine saubere Dateninfrastruktur. Ohne sie verlieren Agenten den Überblick oder liefern falsche Ergebnisse.
Open Source als Strategie
Alle drei Unternehmen verfolgen eine ähnliche Strategie: Unabhängigkeit von einzelnen Modellanbietern. Ghoche sagte, die meisten Unternehmen besitzen lieber eigene Modelle und Infrastruktur, wenn möglich. Nur für reine Frontier-Reasoning-Aufgaben greifen sie auf die führenden Labs zurück. Dieser Anteil sinkt, je mehr normale Enterprise-Anwendungen hinzukommen.
LinkedIn hat dafür zwei Bausteine entwickelt: ein AI Gateway, durch das jeder ausgehende Aufruf an ein Modell läuft, egal ob öffentliche Cloud oder eigenes Rechenzentrum. Und ein Memory-Subsystem, das Kontext unabhängig vom Modellanbieter speichert. So kann das Unternehmen schnell zwischen verschiedenen Anbietern wechseln.
Walmart hat sein eigenes internes Gateway gebaut, das drei Workload-Typen unterstützt: vollständig deterministische Abläufe, Planer-und-Validierer-Workflows für offene Aufgaben und eine Mischung aus beidem. Governance, Sicherheit und Evaluation laufen immer durch dieses Gateway – egal welches Modell gerade am anderen Ende sitzt.
Für alle gilt: Die Wahl zwischen einem Frontier-Modell und einem Open-Weight-Modell erfolgt nach Effektivität für die Aufgabe, nicht nach ideologischen Gründen.
Drei Ratschläge
Aus den Erfahrungen ergeben sich drei Empfehlungen:
Erstens: Investiere früh in Evaluierung. Ghoche nannte Evals die Basis jedes Use Cases. „Ein robustes Set von Evals hilft dir, das Problem zu zerlegen, danach kannst du viel schneller vorankommen.“ Ohne klare Metriken weißt du nicht, ob dein Agent besser wird oder nur anders funktioniert.
Zweitens: Gib Mitarbeitern früh ein Agent-Harness in die Hand. Gosbys Erfahrung zeigt: Das schafft enorme Innovation. Aber baue parallel die Infrastruktur auf, die entstandene Agenten überwachen und koordinieren kann. Sonst entsteht Chaos.
Drittens: Setze auf Modell- und Kontextunabhängigkeit. Singhs Rat: „Sorge für Unabhängigkeit – egal ob Frontier-Modell heute oder Open-Source-Modell morgen. Behalte den Kontext in deinem Unternehmen, damit du ihn wiederverwenden kannst, wenn du nächstes Jahr ein anderes Modell oder Harness einsetzt.“
Konsequenzen für dein Unternehmen
Wenn du KI-Agenten in deinem Unternehmen einsetzen willst, wirf zuerst einen genauen Blick auf deine Infrastruktur. Die Modelle sind bereit, aber deine Systeme sind es meistens nicht. Kubernetes, Datenpipelines, Governance – das sind die wichtigen Komponenten. Nicht das nächste große Sprachmodell, sondern grundlegende Arbeit. Die drei Unternehmen auf der VB Transform haben gezeigt: zuerst die Infrastruktur aufbauen, dann die Agenten einsetzen. Erst dann funktionieren sie zuverlässig.
Quelle: venturebeat.com
