Die aktuelle Dynamik rund um AI-Agenten erinnert stark an frühere Technologiezyklen der IT. Teams experimentieren, neue Frameworks entstehen beinahe wöchentlich, erste produktive Use Cases liefern beeindruckende Ergebnisse - und gleichzeitig beginnt sich bereits ein neues operatives Ökosystem zu bilden.

Copilots, Agent Frameworks, RAG-Pipelines, AI-Workflows, Model Gateways, Vector Stores, Agent Runtimes und spezialisierte Plattformen entstehen derzeit in hoher Geschwindigkeit. Das ist nachvollziehbar. Unternehmen wollen AI möglichst schnell produktiv nutzen. Viele der neuen Lösungen adressieren reale Herausforderungen rund um Evaluations, Governance, Tool Integration, Prompt Management oder Observability.

Trotzdem lohnt sich eine grundlegende architektonische Frage:

Entsteht hier gerade die nächste Generation integrierter Plattformfähigkeiten - oder die nächste Generation operativer Silos?

Genau an diesem Punkt wird das Thema für Platform Engineering und Cloud-native Architektur interessant. Denn vielleicht ist die wichtigste Erkenntnis gar nicht, dass AI-Agenten völlig neue Plattformen brauchen.

Vielleicht ist die wichtigste Erkenntnis:

AI-Agenten sind operativ näher an Microservices als an Magie.

Die überraschende Erkenntnis: Agenten sind Workloads

Betrachtet man aktuelle AI-Agenten nüchtern aus Sicht von Betrieb und Plattformarchitektur, dann sind sie überraschend vertraut. Hinter aller "Agentic AI"-Rhetorik verbergen sich letztlich Systeme mit klassischen operativen Anforderungen:

Runtime
Netzwerk
Skalierung
Secrets
Observability
Lifecycle Management
Policies
Rollbacks
Ownership
Deployment Pipelines

Ein AI-Agent benötigt Zugriff auf Daten, APIs, Modelle und Tools. Er muss versioniert, abgesichert, überwacht und ausgerollt werden. Genau diese Fähigkeiten gehören seit Jahren zum Kern moderner Cloud-native Plattformen.

Das bedeutet nicht, dass Agenten einfach nur neue REST-Services sind. Sie besitzen zusätzliche Eigenschaften wie reasoning-basierte Entscheidungen, probabilistisches Verhalten oder dynamische Tool-Nutzung. Operativ betrachtet bewegen sie sich jedoch erstaunlich nah an bestehenden Cloud-native Workloads.

Daraus folgt eine wichtige Konsequenz:

Vielleicht brauchen AI-Agenten langfristig keine komplett eigene Plattformwelt.

Sie brauchen gute Plattformfähigkeiten. Aber diese müssen nicht zwingend in einer neuen, parallelen AgentOps-Welt entstehen.

Technologiefreiheit heißt nicht Plattform-Anarchie

Ein starkes Argument aus der Microservices-Welt bleibt richtig: Technologiefreiheit soll Teams ermöglichen, für ihren Kontext passende Technologien auszuwählen.

Aber Technologiefreiheit bedeutet nicht, dass jedes Team alles neu erfinden muss. Sie funktioniert nur mit Rahmenbedingungen:

Sicherheitsvorgaben
Referenzimplementierungen
Golden Paths
Observability-Standards
Deployment-Patterns
Governance als Code
gemeinsame Betriebsfähigkeiten

Ein Team sollte entscheiden können, ob ein Agent mit Python, Java, TypeScript oder einem spezialisierten Framework gebaut wird. Es sollte aber nicht für jeden Agenten neu klären müssen, wie Secrets funktionieren, wie OAuth2 angebunden wird, wie Logs entstehen, wie Metriken erfasst werden, wie Images gehärtet werden, wie ein Rollback funktioniert, wie LLM-Tokens zu beschaffen sind, wie LLMs aufgerufen werden oder wie LLMs betrieben werden.

Genau hier liegt die Stärke bestehender Cloud-native Plattformen.

Sie erlauben technologische Vielfalt oberhalb gemeinsamer Betriebsprinzipien und stellen bewährte Lösungen dort out-of-the-box bereit, wo Teams sie nicht jedes Mal neu bauen sollten.

Das Problem ist nicht nur AI - das Problem ist Plattform-Proliferation

Viele Unternehmen kennen das Muster bereits. Ein Team betreibt ein System. Dann muss es dieses System an vielen Stellen manuell registrieren, dokumentieren und pflegen:

API-Management
Enterprise Architecture Management
Developer Experience Plattform
Security- und Firewall-Prozesse
IT-Design-Dokumentation
Logging- und Monitoring-Plattform
Data Plattform
Data Product Katalog
AI Agent Plattform

Jede Plattform hat gute Gründe. Jede Governance-Anforderung ist einzeln betrachtet nachvollziehbar. Aber in Summe entsteht ein Problem:

Die Komplexität wandert zum Team.

Und damit genau dorthin, wo sie den größten Schaden anrichtet: in den Arbeitsfluss der Menschen, die eigentlich fachlichen Wert liefern sollen.

Hier wird Team-Psychologie relevant. Bürokratische Plattformarbeit erzeugt kognitive Last. Sie führt zu Kontextwechseln, Wartezeiten, manueller Synchronisation und sinkender Ownership.

All diese Plattformen werden benötigt, um Standards und Governance einzuhalten und umzusetzen. Governance bleibt wichtig. Kritisch wird es dort, wo sie nicht mehr als integrierte Plattformfähigkeit wirkt, sondern als zusätzliche manuelle Arbeit beim Team landet.

Dann entscheidet sich, wie viel Governance automatisiert, deklarativ und plattformintegriert stattfinden kann, bevor sie Teams lähmt.

KISS ist kein naiver Wunsch nach Einfachheit

KISS - Keep it simple, stupid - wird in Architekturgesprächen manchmal, wie ein Kalenderspruch behandelt. Das ist ein Fehler. An dieser Stelle geht es nicht um Einfachheit als Geschmackssache. Es geht um die betriebliche Folge von Plattform-Proliferation. Wenn jedes neue Thema eine neue Plattform mit eigener Governance, eigenen Prozessen und eigener Pflege erzeugt, steigt nicht nur die technische Komplexität. Es steigt auch die kognitive Last der Teams. Genau deshalb ist KISS in diesem Kontext kein Kalenderspruch, sondern ein Architekturprinzip. Einfachheit ist nicht nur eine Architektureigenschaft. Sie hat betriebliche Relevanz. Komplexität erzeugt messbare Kosten:

mehr Aufwand für Koordination
mehr Abhängigkeiten zwischen den Teams, Technologien und Plattformen
mehr kognitive Last für einen jeden einzelnen und dadurch weniger Produktivität
mehr Fehlerquellen und damit mehr Fehler
langsamere Änderungen und dadurch schlechteres Time-To-Market
schlechtere Nachvollziehbarkeit (Audits), wer ist wofür zuständig

Die Forschungslage stützt diese Richtung, auch wenn sie selten unter dem Schlagwort KISS läuft. DevOps Research and Assessment (DORA) zeigt, dass lose gekoppelte Teams und Architekturen bessere Voraussetzungen für kontinuierliche Lieferung schaffen. Die DORA-Forschung zu Platform Engineering zeigt außerdem, dass interne Developer Platforms Produktivität, Team Performance und organisatorische Performance verbessern können - wenn sie auf Developer Independence ausgerichtet werden. Team Topologies weist auch drauf hin: die kognitive Last sei maßgeblich wichtig für eine starke Teamwirksamkeit. Oder wie Martin Fowler sagt:

Der primäre Nutzen einer Plattform liegt darin, die kognitive Last stream-aligned Teams zu reduzieren.

Auch in der Software-Engineering-Forschung ist kognitive Last kein Randthema. Nach einer Studie sei der Cognitive Load ein Indikator für Know-How Austausch, Produktivität und Qualität Für Gesamtarchitektur bedeutet das:

Es braucht eine Plattformstrategie.

Wenn für API, Data, Security, Developer Experience und AI jeweils eigene Plattformen entstehen, steigt nicht nur die Zahl technischer Systeme. Es steigt auch die mentale Last der Teams. Und irgendwann wird daraus ein Unternehmensrisiko.

AgentOps als Erweiterung der Plattform

AgentOps wird benötigt. Auch Agenten brauchen Lifecycle Management, Governance, Evaluations, Observability und Security. Entscheidend ist, ob diese Fähigkeiten als weitere separate Plattform entstehen oder als integrierter Teil bestehender Cloud-native Plattformen bereitgestellt werden. Aus meiner Sicht spricht viel für die Integration in die bestehende Cloud Plattform:

Agenten sind Workloads.
Agenten brauchen Identität.
Agenten brauchen Netzwerk.
Agenten brauchen Skalierung.
Agenten brauchen Secrets.
Agenten brauchen Deployments.
Agenten brauchen Observability.
Agenten brauchen Policies.
Agenten brauchen Ownership.

All das existiert bereits in modernen Cloud-Plattformen. Was fehlt, sind AI-spezifische Erweiterungen:

LLM Gateway
LLM Security Policies
Tool (& Data) Invocation Governance
Prompt- und Agent-Versionierung
Kosten- und Token-Transparenz
sichere Referenzimages

Klar bekommt man vieles davon auch mit einer dedizierten AI-Plattform. Man bekommt aber häufig auch die zusätzliche Komplexität und die beschriebenen Nachteile. Deshalb sollte zuerst geprüft werden, welche AI-spezifischen Plattformfähigkeiten auf der bestehenden Cloud-Plattform bereitgestellt werden können.

Make-or-buy ist dabei nicht die eigentliche Trennlinie. Auch gekaufte Komponenten können Teil der Lösung sein. Entscheidend ist, ob sie in die eigene Plattform integriert werden oder ob ein weiteres operatives Silo entsteht.

Ownership gehört in die Fachdomäne

Ein produktiver AI-Agent ist kein neutrales technisches Artefakt. Er handelt in einem fachlichen Kontext. Er nutzt Domänendaten, ruft Domänen-APIs auf, kennt Domänenregeln und erzeugt fachliche Wirkung.

Deshalb sollte auch das Ownership dort liegen, wo der fachliche Bedarf entsteht:

Der Agent gehört der Fachdomäne, die ihn benötigt.

Das ist analog zu Data Mesh. Data Mesh verschiebt Verantwortung für Datenprodukte in die Domänen, weil dort das Wissen über Bedeutung, Qualität, Nutzung und fachliche Verantwortung liegt. Genau die gleiche Logik gilt für AI-Agenten.

Wenn ein Team für eine Business Capability verantwortlich ist, wenn es die dazugehörigen Microservices betreibt und wenn es die Data Products dieser Domäne verantwortet, dann sollte es auch den Agenten verantworten, der diese Capability erweitert.

Ein Agent ist dann kein zentrales AI-Artefakt. Er ist ein weiterer Bestandteil der Domäne

Team Topologies: Gesunde Teams besitzen ihre Systeme

Team Topologies hat für moderne Organisationen einen wichtigen Punkt sehr klar gemacht: Ein gesundes, stream-aligned Team braucht Ownership über seine Systeme und möglichst wenige externe Abhängigkeiten. Das ist keine romantische Vorstellung von Autonomie. Es ist eine Voraussetzung für Flow. DORA beschreibt lose gekoppelte Teams und Architekturen als Grundlage dafür, dass Teams unabhängig liefern können: Teams sollen größere Änderungen ohne Erlaubnis außerhalb des Teams vornehmen, Arbeit ohne feinmaschige Koordination abschließen und unabhängig deployen können. Genau diese Eigenschaften verbessern Software Delivery Performance. Team Topologies formuliert denselben Gedanken aus Sicht der Team-Psychologie: Plattformen sind dann wertvoll, wenn sie die kognitive Last der Teams reduzieren. Nicht wenn sie neue Pflichtprozesse, neue Formulare und neue manuelle Pflegeaufgaben erzeugen. Folglich sollten auch AI-Agenten so entstehen können wie Microservices und Data Products: aus dem Team heraus, mit der im Team gewählten Arbeitsweise, entlang bestehender Domänengrenzen, mit klarer Verantwortung, aber auf einer Plattform mit gemeinsamen Guardrails.

Das Ziel ist nicht maximale Freiheit ohne Rahmen. Das Ziel ist: Team-Autonomie innerhalb gemeinsamer Plattformfähigkeiten.

Kubernetes ist gekommen, um zu bleiben

Kubernetes ist nicht perfekt. Kubernetes ist komplex. Und trotzdem hat sich Kubernetes in vielen Organisationen als gemeinsame Abstraktion für moderne Workloads etabliert. Der Grund ist nicht, dass Kubernetes jede einzelne Aufgabe einfacher macht. Kubernetes schafft eine gemeinsame Betriebsplattform:

deklarative Deployments
horizontale Skalierung
Health Checks
Service Discovery
Secrets
Config Management
Network Policies
Workload Identity
Scheduling
Rollouts und Rollbacks
Operators und Custom Resources

Oder zugespitzt: Kubernetes ist gekommen, um zu bleiben.

Nicht weil jedes Team Kubernetes lieben muss. Sondern weil DevOps- und Plattformteams Kubernetes an die eigenen Bedürfnisse anpassen können und weil es als gemeinsame Integrationsfläche für viele Workload-Typen funktioniert.

Wenn jetzt AI-Agenten produktiv werden, stellt sich die Frage:

Lässt sich die bestehende Cloud-Plattform erweitern, um auch als AI-Agents Runtime dienen zu können?

Skalierung: Ein Agent soll laufen, wenn er gebraucht wird

Ein Agent ist operativ ein Workload. Deshalb sollte er sich auch wie ein Workload verhalten. Wenn ein Agent nicht gebraucht wird, soll er nicht laufen. Wenn er selten gebraucht wird, soll er klein laufen. Und wenn er stark genutzt wird, soll er horizontal skalieren können. Das ist kein exotisches AI-Problem. Das ist ein klassisches Plattformproblem. Kubernetes ist ein autoscaling-fähige Runtime. Event-driven Workloads und serverless Patterns liefern dafür bereits etablierte Antworten. Agenten sollten diese Antworten nutzen, statt sie in einer Spezialplattform erneut zu implementieren. Gerade bei AI ist das relevant, weil Kosten nicht nur durch CPU und Memory entstehen. LLM-Aufrufe, GPU-Nutzung, Embeddings, Vector Search und Tool Calls erzeugen variable Kosten. Eine Plattform, die Agenten wie Workloads behandelt, kann diese Kosten sichtbar machen und technisch begrenzen.

Security beginnt bei Identität

Gerade werden viele extra für Agents entworfene Protokolle gehyped. Nachträglich wird versucht, in diesen Protokollen bestehende Sicherheitsmechanisimen zu implementieren. Es ist nicht so einfach. Vorhandene Security-Best-Practices sind eben nicht über Nacht entstanden.

Wenn ein Agent ein weiterer Microservice ist, dann kann er auch wie ein weiterer Microservice abgesichert werden. OAuth2, JWT, Workload Identity, Service Accounts, AD-Gruppen und bestehende IAM-Lösungen sind nicht plötzlich irrelevant, nur weil der Workload reasoning-fähig ist. Sie können für AI-Agents verwendet werden. Sie sind battle-proven und bereits on board. Lasst sie uns nutzen.

Ein Agent braucht eine eigene Identität. Nicht die Identität irgendeines generischen technischen Users. Nicht versteckt hinter der Identität eines Menschen. Nicht als anonymer Aufruf aus einer AI-Plattform. Sondern als klar erkennbarer digitaler Akteur.

Was darf der Agent?

Die Antwort sollte aus der Domänenverantwortung kommen.

Ein Agent ist Mitglied der Fachdomäne, die ihn verantwortet. Wenn die Domäne eine AD-Gruppe besitzt, dann kann der Agent dieser Gruppe zugeordnet werden. Er darf dann die Daten und Tools nutzen, für die diese Domäne berechtigt ist. Das klingt einfach, ist aber entscheidend für die Umsetzung des Domain-Ownership Prinzips.

Wenn der Customer-Service-Agent zur Customer-Service-Domäne gehört, dann darf er Kundenvorgänge bearbeiten, wenn genau diese Berechtigung vergeben wurde. Er darf aber nicht automatisch HR-Daten lesen, Finance-Aktionen auslösen oder Produktionssysteme verändern. Dafür bräuchte er separate explizite Berechtigungen der Fremddomäne. Um dem zu entgehen, stellt jede Domäne eigene Agents zur Verfügung, die sie selbst verantworten.

Analog zu den Tools: die Frage "Darf der Agent ein Tool aufrufen?". Ja, wenn seine Identität dafür berechtigt wurde. Und wenn nicht, dann nicht. Wie bei jedem anderen Service.

Tools müssen Maschinen und Menschen unterscheiden können

Es darf nicht passieren, dass Zielsysteme nicht unterscheiden können, ob eine Aktion durch einen Menschen, einen klassischen Service oder einen AI-Agenten ausgelöst wurde. Gerade bei Agenten ist Nachvollziehbarkeit zentral. Folgende Punkte müssen laut dem EU AI Act Transparent sein:

Welcher Agent hat die Aktion ausgeführt?
In welcher Version?
In welchem Auftrag?
Mit welchem Tool?
Auf Basis welcher Berechtigung und Begründung?
Wurde die Aktion direkt durch einen Menschen delegiert?
Oder autonom durch eine Agentenlogik ausgelöst?

Das Audit-Protokoll des Zielsystems muss zeigen, ob es ein Agent war, ein Service oder ein Mensch. Nicht als nachträgliches Reporting. Sondern als Teil des Sicherheitsmodells.

LLM Security ist Plattformaufgabe

AI-Agenten bringen neue Sicherheitsrisiken mit: Prompt Injection, Data Leakage, ungewollte Tool-Nutzung, unsichere Retrieval-Kontexte oder ungeeignete Modellwahl. Genau deshalb entsteht schnell der Reflex, eine fertige AI-Plattform einzuführen, die diese Risiken kapselt. Das kann sinnvoll sein. Aber es löst nur einen Teil des Problems. Wenn AI für Kernprozesse, Geschäftsmodelle oder den Umgang mit kritischen Unternehmensdaten strategisch wird, reicht es nicht, LLM Security als isolierte Produktfunktion zu betrachten. Dann muss die Integrationshoheit bei der eigenen Plattformarchitektur bleiben: Identität, Datenklassifizierung, Modellfreigaben, Audit, Policies und Tool-Berechtigungen müssen mit den bestehenden Governance-Mechanismen zusammenspielen. Make-or-buy ist deshalb nicht die eigentliche Trennlinie. Die strategische Frage ist, ob die Kontrolle über Identität, Datenklassifizierung, Modellzugriff, Audit und Governance innerhalb der eigenen Plattformarchitektur bleibt. Deshalb sprechen diese Risiken für gemeinsame Plattformfähigkeiten. Die Plattform sollte gehärtete Images bereitstellen, in denen zentrale Sicherheitsmechanismen bereits vorimplementiert sind:

sichere Defaults für Agent Runtimes
standardisierte Logging- und Audit-Hooks
Secrets Handling
Policy Enforcement
Output Filtering
Prompt-Injection-Schutz
sichere Tool-Invocation-Patterns
zentrale Konfiguration für Model Gateways

Zusätzlich braucht es Security Layer vor dem LLM Gateway:

Darf dieser Agent dieses Modell aufrufen?
Darf dieser Agent mit diesen Daten dieses Modell aufrufen?
Sind die Daten PII-relevant?
Ist das Zielmodell für diese Datenklasse freigegeben?
Wurde das Modell explizit spezifiziert oder automatisch gewählt?
Gibt es Datenresidenz- oder Compliance-Vorgaben?

Das ist Plattform-Governance.

Fazit: Die Befreiung der KI-Agenten beginnt nicht mit dem nächsten Silo

AI-Agenten sind wichtig. Sie werden produktive digitale Akteure in Unternehmen. Sie werden Daten lesen, Tools nutzen, Entscheidungen vorbereiten und Prozesse ausführen. Gerade deshalb dürfen sie nicht als magische Sonderwelt betrieben werden. Sie brauchen Ownership. Sie brauchen Identität. Sie brauchen Audit. Sie brauchen Skalierung. Sie brauchen Security. Sie brauchen Governance. Sie brauchen Plattformfähigkeiten. Aber vieles davon haben moderne Cloud-native Plattformen bereits gelernt.

Vielleicht ist die eigentliche Befreiung der KI-Agenten deshalb nicht der Aufbau einer neuen Agentenplattform, sondern die Integration von AI in die Prinzipien, die moderne Softwarearchitektur bereits stark gemacht haben:

Domänenverantwortung
lose gekoppelte Teams
deklarative Plattformen
GitOps
Kubernetes
Security by Design
Governance als Code
KISS als Architekturprinzip

Oder kurz: Agenten sind Workloads. Behandeln wir sie auch so. PS: Das ist übrigens nicht nur Theorie. Wir haben bei adorsys dazu einen Prototyp gebaut und auf der CloudLand als Demo gezeigt. Wenn dich interessiert, wie das konkret aussehen kann: melde dich gern. Ich zeige dir die Demo.