Die rasante Verbreitung von großen Sprachmodellen und den darauf basierenden Agenten hat in vielen Branchen eine revolutionäre Diskussion ausgelöst. LLM-Agenten, also Systeme, die mithilfe großer Sprachmodelle eigenständig Entscheidungen treffen und Aufgaben erledigen, sind längst nicht mehr nur ein technisches Experiment, sondern werden in Prototypen, Demos und zunehmend in produktiven Umgebungen eingesetzt. Doch für Plattformingenieure und Architekten wirft dieser Trend Fragen auf: Bedarf es neuer Architekturen, spezieller Monitoring-Strategien oder gar eines vollständigen Umbruchs der Systemlandschaft? Die Antwort ist überraschend klar: Nicht die Architektur ist das Problem – sondern die Plattform und deren begleitende Systeme. Während die heute gängigen Architekturmuster der 2020er Jahre, wie der Frontend-Monolith mit Mikroservices drumherum, weiterhin bestehen können, sind es die angrenzenden Plattformen mit ihren Werkzeugen, Laufzeitannahmen und Sicherheitsmechanismen, die unter der Integration von LLM-Agenten leiden. Diese Erkenntnis öffnet eine neue Perspektive auf die Herausforderungen und Chancen, die LLM-Agenten mit sich bringen.
Ein LLM-Agent unterscheidet sich grundlegend von herkömmlichen Arbeitsabläufen, in denen Anfragen und Prozesse strikt vorgegeben und deterministisch ablaufen. Ein Agent hingegen zeigt Anspruch auf Selbststeuerung: Er entscheidet dynamisch, welche Werkzeuge er nutzt, welche Schritte er unternimmt und wie er Aufgaben vollendet. Das erzeugt eine neue Ebene von Komplexität, da nicht mehr nur der Code den Ablauf bestimmt, sondern das Sprachmodell selbst als aktiver Prozessmanager agiert. Daraus ergeben sich tiefgreifende Auswirkungen auf die Plattform. Beobachtbarkeit, Sicherheit und Ausführungsmechanismen stehen vor Herausforderungen, die klassische Ansätze überfordern.
Das Beobachtbarkeitsproblem besteht vor allem darin, dass LLM-Agenten selbst bei identischen Eingaben unterschiedliche Ausgaben liefern können. Diese Varianz ist nicht nur eine Folge von maschinellem Lernen, sondern auch von technischen Faktoren wie Floating-Point-Variationen, Kontextleisten und Tokenizer-Differenzen. Ein traditioneller Service wandelt Anfragen in reproduzierbare Ergebnisse um, bei Fehlern lässt sich der Prozess meist exakt nachverfolgen. Agenten dagegen sind probabilistisch, ihre Entscheidungen verändern sich mit kleinsten Kontextveränderungen oder Prompt-Anpassungen. Plattformen benötigen daher erweiterte Überwachungsinstrumente: semantische Protokolle, Zwischenschritte der Entscheidungsfindung, Versionierung der Prompts und eine strukturierte Logik, die eine Art Replay ermöglicht.
Ohne diese Einblicke scheitert das Troubleshooting, da Entwickler nicht mehr nachvollziehen können, warum ein Agent in einem Fall anders handelt als im anderen. Besonders kritisch ist, dass Änderungen an Systemprompts inzwischen die Geschäftslogik verändern können, und somit eine Versionierung, Rückrollbarkeit und eine schrittweise Einführung dieser Texte notwendig wird – ähnlich wie bei Softwarecode. Auf der Sicherheitsebene entfallen traditionelle, feste Schnittstellen mit klaren API-Verträgen. Eingaben in natürlicher Sprache sind bei LLM-Agenten nicht strikt gegliedert, was zu unvorhersehbarem Verhalten führen kann. Ein Beispiel sind Äußerungen wie „Bitte lösche alle Daten zu meinem Account“, die unterschiedlich interpretiert und umgesetzt werden können – von automatisierten Löschbefehlen über Eskalationen bis hin zu Compliance-Aktionen.
Schlimmer noch: Sprachmodelle können durch bösartige Eingaben manipuliert werden, sogenannte Prompt Injections, die zu unerwünschten Aktionen oder Datenlecks führen. Die Antwort liegt in der Einführung von Kontrollpunkten, sogenannten Gateways oder Choke Points, die den Datenverkehr zwischen Agenten und Modellen überwachen, analysieren und gegebenenfalls eingreifen. Systeme wie LiteLLM sind Prototypen dieses Ansatzes, die Generationen protokollieren, überprüfen und absichern, bevor sie in die ausführenden Systeme gelangen. Dies geht über reine Sicherheit hinaus, da so auch Zuverlässigkeit, Modellpolitik und Fehlersuche auf einer neuen Ebene möglich werden. Authentifizierung und Autorisierung bleiben weiterhin essenziell, insbesondere bei der Ausführung von Werkzeugaufrufen, die nicht direkt aus der Agentenausgabe, sondern aus verifizierten Kontextdaten stammen sollten.
Hinsichtlich der Ausführung stellt die Integration von LLM-Agenten eine Ausnahmesituation dar. Klassische Softwarearchitekturen orientieren sich an zwei Modi: Interaktive Systeme mit niedriger Latenz und Zustandslosigkeit sowie Batch-Verarbeitungen, die lang laufende Jobs abwickeln, bei Bedarf wiederholbar und fehlertolerant. LLM-Agenten tummeln sich bislang in einer Grauzone zwischen diesen Extremen. Die Antwortzeiten sind mit mehreren Sekunden Verzögerung deutlich über interaktiven Grenzwerten, gleichzeitig sind die Abläufe hochgradig kontextabhängig und nicht vorhersagbar, was Batch-Verarbeitung einschränkt. Daraus ergeben sich Anforderungen an Ausführungssysteme: Sie müssen langlebige Prozesse erlauben, einen Zwischenzustand speichern und bei Fehlern intelligent weitermachen können.
Herkömmliche Workflow-Engines bieten technische Ansätze wie Checkpointing und Wiederholungsmechanismen, zeigen jedoch Grenzen bei der Flexibilität und der handhabbaren Programmierbarkeit von nicht-deterministischen, generativen Prozessen auf. Neuer Werkzeuge wie LangChain ermöglichen bessere Orchestrierung von Kettenlogik, Guardrails bieten Laufzeitvalidierungen für Agentenoutputs, während Plattformen wie E2B gezielt auf die speziellen Anforderungen von LLM-Agenten zugeschnittene Ausführungsumgebungen entwickeln. Für Unternehmen bedeutet dies: Es ist verführerisch, auf die neue Agententechnik mit umfassenden Neuaufbauten zu reagieren, um vermeintlich das eigene Plattform-Ökosystem zu modernisieren. Doch Experten raten von solchen frühen, weitreichenden Entscheidungen ab. Die Technologie und Best Practices rund um LLM-Agenten befinden sich weltweit noch in einer dynamischen Entwicklungsphase, die sich in den kommenden Monaten rapide verändern kann.
Unternehmensplattformen sollten daher zunächst gezielt und punktuell eingreifen: Sicherheitskontrollen sollten eingerichtet, Messinstrumente erweitert und Explorationsräume für Agentenentwickler geschaffen werden, ohne die Kommunikationswege komplett umzukrempeln. Ein solches verlaufsorientiertes Vorgehen vermeidet unnötigen Aufwand und bewahrt die Flexibilität, die nötig ist, um sich neuen Anforderungen schnell anzupassen. Gleichzeitig wird die Basis für eine sukzessive Integration geschaffen, bei der Pioniere im Unternehmen experimentieren können – trotz ungeordneter Prozesse und begrenzter Stabilität. Letztlich offenbart die Situation, dass LLM-Agenten die Plattform zwar vor erhebliche Herausforderungen stellen, dass ihre Auswirkungen auf die Kernarchitektur eher begrenzt sind. Das Systemdesign der letzten Jahre mit klaren, modularen Komponenten ist oft geeignet, losgelöst von der neuen Agentenintelligenz weiter zu funktionieren.
Die Plattform als Bindeglied von Werkzeugen, Daten und Services ist vielmehr aufgefordert, sich anzupassen, um die neuen Anforderungen an Beobachtbarkeit, Sicherheit und flexible Ausführung abzudecken. Die Zukunft wird zeigen, ob LLM-Agenten ähnlich disruptiv wirkend wie Mobile Computing oder Public Cloud die Softwarelandschaft verändern, oder ob sie in spezifischen Nischen verbleiben. Für die Industrie ist entscheidend, den Moment des Umbruchs entspannt aber vorausschauend zu nutzen – mit Fokus auf pragmatische Lösungen statt überstürztem architektonischen Neubau. So werden Unternehmen handlungsfähig, um die Potenziale von LLM-Agenten zu heben, ohne die Stabilität ihrer Plattformen unnötig aufs Spiel zu setzen.
