Unternehmen testen KI-Agenten längst nicht mehr nur im Pilot. Sobald sie echte Prozesse auslösen, zählen andere Fragen als die reine Modellqualität: Wer verwaltet Laufzeit, Speicher, Werkzeugzugriffe, Protokolle, Freigaben und Kosten? Genau hier erklärt sich, warum viele Firmen bei KI-Agenten im Unternehmen eher auf Plattformen als auf kompletten Eigenbau setzen. Der Ausbau von Cloudflares Agent-Cloud mit OpenAI ist dafür vor allem ein anschauliches Beispiel. Der eigentliche Trend ist breiter: Agentische Systeme brauchen eine verlässliche Betriebsplattform, sonst werden sie teuer, schwer kontrollierbar und im Alltag kaum skalierbar.
Das Wichtigste in Kürze
- Plattformen gewinnen meist nicht wegen besserer Modelle, sondern weil sie Orchestrierung, Zustandsspeicher, Beobachtbarkeit und Sicherheitskontrollen als Betriebsgrundlage bündeln.
- Für produktive Agenten reichen Prompt und API nicht aus: Nötig sind typisierte Tool-Schnittstellen, eindeutige Identitäten, Ablaufsteuerung, Protokollierung und Budgetgrenzen.
- Vollständiger Eigenbau bleibt möglich, lohnt sich aber vor allem dort, wo Unternehmen besonders strenge Integrations-, Kontroll- oder Differenzierungsanforderungen haben.
Der eigentliche Engpass liegt im Betrieb, nicht im Modell
Die Kernfrage lautet nicht, ob ein Sprachmodell Aufgaben sinnvoll planen kann. Die entscheidende Frage ist, wie daraus ein belastbarer Unternehmensdienst wird. Ein Agent muss Informationen abrufen, Werkzeuge aufrufen, Zwischenschritte speichern, auf Fehler reagieren, Freigaben einholen und seine Entscheidungen nachvollziehbar hinterlassen. Solange das nur in einer Demo läuft, lässt sich vieles improvisieren. Im produktiven Betrieb wird genau diese Improvisation zum Risiko.
Der aktuelle Plattformschritt von Cloudflare mit OpenAI zeigt das Muster recht klar: Die eigentliche „Kognition“ des Agenten kann von einem Modellsystem oder SDK kommen, während eine separate Plattform Ausführung, Persistenz, Routing und Langläufer-Prozesse übernimmt. Für Unternehmen ist das relevant, weil sich der Schwerpunkt verschiebt. Nicht mehr das einzelne Modell ist das Nadelöhr, sondern die Frage, ob ein Agent zuverlässig, sicher und wirtschaftlich in bestehende Prozesse eingebettet werden kann.
Eine Agenten-Plattform bündelt die Arbeit, die im Eigenbau schnell ausufert
Ein produktiver Agent ist kein einzelner API-Aufruf. Er besteht aus mehreren Schichten: Modellzugriff, Ablaufsteuerung, Speicher für Zustand und Kontext, Anbindung an Werkzeuge, Fehlerbehandlung, Protokollierung und Rechteverwaltung. Genau diese Trennung beschreiben auch die Referenzmuster in den Dokumentationen großer Plattformanbieter. AWS trennt in seiner Agenten-Architektur klar zwischen Bauphase und Laufzeit: Instruktionen, Wissensquellen und Tool-Definitionen stehen auf der einen Seite, Orchestrierung, Tool-Aufrufe und Tracing auf der anderen.
Cloudflare formuliert denselben Gedanken aus der Infrastrukturperspektive. Dort soll das OpenAI Agents SDK die Planungs- und Reasoning-Seite liefern, während Cloudflare mit Workers, Workflows und Durable Objects die Ausführung und den persistenten Zustand übernimmt. Für Unternehmen ist das attraktiv, weil sich damit ein wiederkehrendes Problem entschärft: Was im Pilot als lose Sammlung von Skripten, Datenbankeinträgen und Hintergrundjobs startet, wird in der Fläche zu einer schwer beherrschbaren Eigenplattform. Verwaltete Plattformen versprechen, diese Betriebsarbeit zu standardisieren.
Diese Bausteine müssen KI-Agenten im Unternehmen mitbringen
Wer Agenten produktiv betreiben will, braucht mehr als ein gutes Modell und eine hübsche Oberfläche. Die belastbaren Quellen aus Cloud-Infrastruktur, Governance-Leitfäden und Forschung laufen auf denselben Kern hinaus: Ohne definierte Betriebsbausteine werden Agenten unzuverlässig, intransparent oder unnötig teuer.
- Orchestrierung: Der Agent braucht eine kontrollierte Ablaufsteuerung für mehrstufige Aufgaben, Wiederholungen, Wartezeiten und Abbrüche.
- Speicher und Zustand: Laufende Sitzungen, Zwischenergebnisse und längerfristige Informationen müssen getrennt und gezielt gespeichert werden.
- Typisierte Werkzeugzugriffe: Tools sollten über definierte Schnittstellen beschrieben sein, etwa per Funktionsschema oder OpenAPI, damit Aufrufe prüfbar bleiben.
- Beobachtbarkeit: Für jeden Schritt braucht es Traces, Logs und Metriken, damit Fehler, Kosten und unerwünschte Aktionen nachvollziehbar sind.
- Governance: Agenten brauchen Identitäten, Zuständigkeiten, Richtlinien, Freigaben und Audit-Spuren statt bloßer Entwickler-Workarounds.
- Sicherheitsgrenzen: Rechte sollten minimal vergeben werden; kritische Aktionen brauchen Filtersysteme, Sandboxing oder menschliche Freigaben.
- Kostenkontrolle: Token, Laufzeit, externe API-Aufrufe und Infrastrukturverbrauch müssen pro Agent oder Prozess sichtbar und begrenzbar sein.
Gerade Beobachtbarkeit und Governance werden häufig unterschätzt. Microsoft beschreibt in seinem Governance-Leitfaden für Organisationsumgebungen ausdrücklich zentrale Agenten-Register, eindeutige Identitäten und konsistente Richtlinien als Grundvoraussetzung. In der Forschung zu agentischen Architekturen tauchen dieselben Punkte unter anderen Namen auf: versionierte Artefakte, begrenzte Schleifen, Circuit Breaker und nachvollziehbare Provenienz jedes Schritts.
Warum verwaltete Plattformen oft schneller produktiv werden
Der wichtigste Vorteil einer Plattform ist nicht Bequemlichkeit, sondern Wiederholbarkeit. Wenn mehrere Teams parallel Agenten bauen, entstehen sonst dieselben Probleme immer wieder neu: Authentifizierung, Tool-Wrapper, Hintergrundjobs, Zustandsverwaltung, Sitzungslogik, Freigabeprozesse und Monitoring. Eine verwaltete Plattform legt dafür gemeinsame Muster fest. Das senkt den Integrationsaufwand, beschleunigt die Inbetriebnahme und macht Ergebnisse teamübergreifend vergleichbarer.
Auch wirtschaftlich spricht einiges dafür. Kosten bei Agenten entstehen nicht nur durch Modellaufrufe, sondern durch eine Kette aus Speicher, Netzwerk, Tool-Zugriffen, Fehlerläufen und Wiederholungen. Ohne zentrale Sicht werden diese Kosten schnell unscharf. Plattformen können hier Grenzen, Tagging, Alarme und Protokolle zusammenführen. Das macht sie besonders interessant für große IT-Organisationen, für regulierte Branchen und für Unternehmen in Deutschland und Europa, die Datenflüsse, Zuständigkeiten und Eingriffsrechte sauber dokumentieren müssen. „Managed“ heißt allerdings nicht automatisch „billiger“: Wer sehr spezielle Lastprofile oder stabile, stark optimierte Eigenprozesse hat, kann auf Dauer auch mit Eigenkomponenten günstiger fahren.
Die Grenzen: Lock-in, Kontrolle und Anpassbarkeit verschwinden nicht
Plattformen lösen nicht jedes Problem. Wer Ausführung, Speicher, Logs und Sicherheitsmechanismen eng an einen Anbieter bindet, schafft neue Abhängigkeiten. Lock-in entsteht besonders dann, wenn Geschäftslogik tief in proprietäre Workflows, Speicherobjekte oder Observability-Werkzeuge eingebaut wird. Unternehmen sollten deshalb darauf achten, dass Werkzeuge über offene oder zumindest klar beschriebene Schnittstellen angebunden werden und dass die fachliche Logik nicht vollständig in plattformspezifischen Bausteinen verschwindet.
Hinzu kommt die Frage der Kontrolle. Manche Organisationen wollen sensible Daten, interne Regelwerke oder kritische Aktionssysteme nicht in eine vollständig fremdverwaltete Laufzeit verlagern. Dann sind Mischmodelle oft plausibler: Die Plattform übernimmt Orchestrierung, Identität und Monitoring, während Datenhaltung, Spezialtools oder besonders kritische Ausführungsschritte im eigenen Umfeld bleiben. Vollständiger Eigenbau bleibt vor allem dort sinnvoll, wo Unternehmen technische Differenzierung suchen, bereits starke interne Plattformteams haben oder ungewöhnliche Anforderungen an Latenz, Sicherheit oder Integration erfüllen müssen. Für die breite Masse ist das jedoch die aufwendigste Option.
Plattform statt Eigenbau ist meist eine Betriebsentscheidung
Ob sich verwaltete Agent-Plattformen, Mischmodelle oder weiterer Eigenbau durchsetzen, entscheidet sich weniger an der Demoqualität eines Modells als an der Betriebsrealität. Sobald Agenten in Unternehmen dauerhaft Aufgaben übernehmen, wird Infrastruktur wichtiger als Experimentiergeschwindigkeit: Speicher, Tracing, Richtlinien, Rechte, Kostenkontrolle und sichere Werkzeugaufrufe sind keine Zusatzfunktionen, sondern die eigentliche Produktionsschicht. Deshalb spricht viel dafür, dass Plattformen den Standardfall bilden werden, während Hybridmodelle für sensible oder stark angepasste Umgebungen an Bedeutung gewinnen. Reiner Eigenbau bleibt möglich, aber eher als bewusste Ausnahme mit klarer Begründung.
Vor der Architekturentscheidung lohnt meist zuerst die Frage nach dem Betriebsmodell, nicht nach dem eindrucksvollsten Demo-Agenten.
