Warum Ihr Framework für KI-Agenten nicht ausreicht: 7 Plattformfunktionen, die in der Produktion fehlen

Ihr Agent funktioniert. Ich weiß, dass er funktioniert. Sie haben ihn mit LangChain, CrewAI oder einer benutzerdefinierten Lösung entwickelt, ihn in realen Szenarien getestet und er hat sie bewältigt. Das Problem ist nicht der Agent. Das Problem ist das gesamte Umfeld.

Im Blog-Beitrag Warum gute KI-Agenten in der Produktion versagen: Die fehlende Infrastrukturschicht, führten 3 Ausfälle über Nacht in einem einzelnen KI-Agent-Deployment zu: 43 duplizierte Support-Tickets, 4.000 USD, die dem falschen Konto in Rechnung gestellt wurden, und eine halluzinierte Rückerstattungsrichtlinie, die zu einer Rückgabe im Wert von 280 USD führte, die das Unternehmen akzeptieren musste. Dieser Agent hat in der Entwicklung einwandfrei funktioniert, fiel aber in der Produktion aus, da die Infrastruktur unzureichend war. Die Lücke zwischen einem funktionierenden Agenten in der Entwicklung und einem produktionsbereiten Deployment ist kein Framework-Problem, sondern ein Infrastrukturproblem.

Dieser Artikel deckt diese Lücke auf. Ich werde über folgende Themen sprechen:

• 7 spezifische Funktionen, die derzeit von keinem Framework bereitgestellt werden
• Wo Ihr Framework aufhört
• Warum 3 gängige Workarounds nicht funktionieren
• Was tatsächlich hilft, die Lücke zu schließen – ohne dass Sie Ihren Agenten umschreiben müssen

7 Dinge, die Ihr Framework nicht mitliefert

Der Vorfall um 6.00 Uhr deckte 3 Fehler auf. Diese 3 Fehler sind jedoch Symptome einer weitreichenderen fehlenden Infrastruktur. Wenn ich Ausfälle von Produktions-Agenten in verschiedenen Unternehmen analysiere, treten immer die gleichen 7 Lücken auf.

1. Kryptografische Identität

Die kryptografische Identität bietet einen verifizierbaren Nachweis, welche Workload eine Anfrage stellt, mit Identitätsattributen, die bestimmen, welche Services sie erreichen kann. Die fehlerhafte Belastung eines Kontos in Höhe von 4.000 USD geschah, weil der Agent mit allgemeinen Anmeldedaten ausgeführt wurde, die nie für die Produktion eingeschränkt wurden. Ein Large Language Model (LLM) wählte die falsche Konto-ID aus, und die Infrastruktur verfügte über keinerlei Schutzmechanismen, um dies zu verhindern. Mit der kryptografischen Identität schränkt die Plattform ein, welche Services der Agent erreichen kann, und ordnungsgemäß konfigurierte Downstream-APIs setzen durch, welche Parameter für einen bestimmten Aufrufer gültig sind. Das Modell wählt eventuell weiterhin die falsche ID aus, aber die potenziellen Auswirkungen sind begrenzt – der Schaden beschränkt sich auf Ressourcen innerhalb des autorisierten Bereichs des Agenten und betrifft nicht jedes Konto im System. Für Entscheidungstragende ist dies der Unterschied zwischen „ein Konto war betroffen“ und „sämtliche Konten waren gefährdet“.

2. Execution Sandboxing

Execution Sandboxing bietet eine Isolierung auf Hardware- und Anwendungsebene, sodass eine kompromittierte oder fehlerhafte Workload nicht das Host-Betriebssystem erreichen oder andere Workloads beeinträchtigen kann. Dies betrifft nicht nur Agenten – jede Workload benötigt Isolierung. Bei Agenten ist dies jedoch besonders dringlich, da sie autonom agieren sowie APIs und Tool-Aktionen in Maschinengeschwindigkeit ausführen. Ohne Sandboxing wird der Ausfall einer Workload zum Ausfall sämtlicher Workloads auf demselben Rechner. Ein Agent, der in das Dateisystem schreiben oder Netzwerkverbindungen außerhalb seines Bereichs öffnen kann, stellt ein Risiko dar, das das Sicherheitsteam niemals für die Produktion genehmigen wird.

3. Tool-Governance

Tool-Governance ist eine Richtlinie auf Infrastrukturebene, die bestimmt, welche Tools ein Agent aufrufen kann. Sie wird auf Netzwerkebene durchgesetzt, damit sie nicht durch Prompt Injection (eine Technik, bei der ein Agent durch böswillige Eingaben zu unbeabsichtigten Aktionen verleitet wird) umgangen werden kann. Ich habe erlebt, wie Teams versuchen, den Zugriff auf Tools mithilfe von Prompt Engineering zu erzwingen, aber das hält nicht stand. Ein entschlossener Gegner – oder ein ausreichend kreatives Modell – umgeht die Beschränkungen auf Prompt-Ebene. Governance gehört in die Infrastruktur, nicht in den Prompt.

4. Observability und Tracing

Observability und Tracing umfassen vollständige Execution Traces (Ablaufverfolgung), die jeden Prompt, Tool-Aufruf und jedes Zwischenergebnis erfassen. Alle 3 Fehler beim Vorfall um 6.00 Uhr blieben unentdeckt, bis sie durch Kunden und Rechnungen sichtbar wurden. Mit vollständigen Execution Traces wäre jeder Fehler sichtbar gewesen, bevor ein Kunde ihn gemeldet hätte. Für Entwickelnde bedeutet das, eine mehrstufige Agenteninteraktion auf dieselbe Weise zu debuggen wie einen verteilten Microservice-Aufruf. Für Unternehmen bedeutet das Audit-Trails, die Compliance-Prüfende zufriedenstellen.

5. Kontinuierliche Evaluierung

Die kontinuierliche Evaluierung ermöglicht die Produktionsbewertung von Agentenausgaben anhand von Richtlinien und Grundwahrheiten, sodass Regressionen sichtbar werden, bevor Kunden sie melden. Die halluzinierte Rückerstattungsrichtlinie – bei der der Agent dem Kunden mitteilte, dass die Rückgabefrist 90 Tage statt der tatsächlichen 30 Tage betrage – erreichte einen Kunden, da keine Evaluierungsschicht die Ausgabe mit der tatsächlichen Richtlinie abglich. Statische Testsuiten erfassen das, was Sie erwartet haben; die kontinuierliche Evaluierung erfasst das, was Sie nicht erwartet haben.

6. Sicherheitsdurchsetzung

Die Sicherheitsdurchsetzung bietet Leitplanken an der Inferenzgrenze, die Ausgaben abfangen, bevor sie Kunden, Datenbanken oder nachgelagerte Agenten erreichen. In dem Beispiel, in dem ein Agent dreimal an einem Tag ausfiel, leitete das Framework die erfundene Antwort des Modells ohne jegliche Überprüfung direkt an den Kunden weiter. Die Sicherheitsdurchsetzung macht die Inferenzgrenze zu einem Kontrollpunkt statt zu einem einfachen Durchgang.

7. Lifecycle Management

Das Lifecycle-Management umfasst das Bereitstellen, Aktualisieren, Skalieren und Stilllegen von Agenten in einer Flotte mit einem konsistenten Betriebs- und Sicherheitsstatus. Ein Agent ist ein Projekt, aber 10 Agenten in 3 Teams sind eine operative Herausforderung. Ohne Lifecycle-Management entwickelt jedes Team seinen eigenen Bereitstellungsprozess, sein eigenes Sicherheitsmodell und seine eigene Update-Frequenz. Die Konsistenz geht verloren.

Wo Ihr Framework aufhört

Die Produktion erfordert Konsistenz zwischen diesen 7 Funktionen. Wo lassen Sie die Frameworks, die Sie bereits verwenden, also tatsächlich im Stich? LangChain und LangGraph bieten Ihnen Chains, Agenten, Tool-Aufrufe, strukturierte Ausgaben, graphbasierte Orchestrierung, Sitzungsspeicher und Retrieval-Integration. Die Kombinierbarkeit ist wirklich stark. CrewAI bietet Multi-Agenten-Koordination, rollenbasiertes Agentendesign, Aufgabendelegierung und Crew-Orchestrierung; die Multi-Agenten-Muster sind gut durchdacht. Google ADK ist eng in das Google-Ökosystem integriert. Claude Agents bieten eine hohe Argumentationstiefe. Strands (AWS) bietet eine AWS-native Workflow-Integration.

Jedes Framework ist hervorragend in der Agentenschleife – dem Zyklus aus Wahrnehmung, Argumentation und Handeln, der einen Agenten ausmacht. Keines davon bietet kryptografische Identität oder Execution Sandboxing. Tool Governance auf Netzwerkebene ist nicht vorhanden. Produktionsreifes Distributed Tracing, kontinuierliche Evaluierung, Sicherheitsdurchsetzung an der Inferenzgrenze und Flotten-Lifecycle-Management sind in keinem davon vorhanden.

Dies ist keine Kritik, sondern lediglich eine kategoriale Unterscheidung. Frameworks sind Tools auf Anwendungsebene, aber die 7 genannten Funktionen betreffen die Plattformebene. Zu erwarten, dass Ihr Framework diese mitliefert, ist so, als würde man von Django erwarten, dass es Kubernetes mitliefert – Container-Orchestrierung ist Infrastruktur, keine Anwendungslogik, und es wäre unangemessen, dies von einem Web-Framework zu verlangen. Dasselbe gilt auch hier. Die Schichten sind einfach unterschiedlich.

Wenn Sie versucht haben, einen LangChain-Agenten mit der richtigen Identität, Tracing und Governance bereitzustellen, haben Sie dies bereits gespürt. Am Ende schreiben Sie mehr Code für die Plattform-Integration als Agentencode. Der Agent war der einfache Teil.

3 Ansätze, die nicht skalierbar sind

Wenn der Agent der einfache Teil war, müssen die Teams immer noch den schwierigen Teil lösen. Jedes Team, mit dem ich spreche, hat mindestens einen dieser Ansätze ausprobiert, bevor es nach einer Plattformlösung suchte.

Die Eigenentwicklung. Teams schreiben ihre eigenen Skripte für Identity Injection, Tracing-Integration und Deployment. Für 1 Agenten funktioniert das. Es ist sogar zufriedenstellend, da man jedes Detail versteht. Bei 10 Agenten in 3 Teams hat jedes Team sein eigenes Sicherheitsmodell, sein eigenes Tracing-Format und seinen eigenen Bereitstellungsprozess. Es gibt keine Konsistenz und keine Governance, sondern nur einen wachsenden Wartungsaufwand, der erfahrene Engineers von den Agenten selbst abzieht. Ich habe erlebt, dass Teams mehr Zeit mit der Wartung ihrer eigenhändig erstellten Plattform-Verbindungen verbringen als mit der Entwicklung von Agentenfunktionen.

Gehostete Agent-Plattformen wie Salesforce Agentforce, AWS Bedrock Agents oder Azure AI Agent Service schließen die Produktionslücke, indem sie den gesamten Stack kontrollieren. Der Nachteil ist, dass sie auch die Kontrolle über den Datenpfad behalten. Jeder Prompt, jeder Tool-Aufruf und jedes Argumentationsartefakt wird über einen Drittanbieter-Dienst geleitet. In regulierten Branchen – in denen die Daten das Netzwerk nicht verlassen dürfen – ist dies ein Ausschlusskriterium. Und wenn die Plattform ihre Preise ändert oder eine Funktion einstellt, müssen sich Ihre Agenten daran anpassen.

Framework-spezifische Erweiterungen bieten produktionsorientierte Add-ons innerhalb eines einzelnen IT-Ökosystems – LangSmith für Tracing ist ein gutes Beispiel und wirklich nützlich. Aber ein Unternehmen, das LangChain, CrewAI und benutzerdefinierte Agenten einsetzt, benötigt nun 3 separate Produktionsstrategien. Das bedeutet 3 Tracing-Formate, 3 Sicherheitsmodelle und 3 Toolsets, die die Teams erlernen müssen. Die Produktionsinfrastruktur sollte Framework-unabhängig sein und nicht an das Ökosystem eines einzelnen Anbieters gebunden sein.

Jeder Ansatz löst einen Teil des Problems und führt gleichzeitig eine neue Einschränkung ein. Der erste Ansatz ist nicht skalierbar. Der zweite tauscht Souveränität gegen Bequemlichkeit ein. Der dritte fragmentiert die Produktionsstrategie über Framework-Grenzen hinweg.

Ihr Agent, die Plattform von Red Hat

Die Einschränkung, die alle Ansätze teilen, ist die Annahme, dass die Produktionsinfrastruktur von derselben Stelle stammen muss wie das Agenten-Framework – oder von Grund auf neu entwickelt werden muss. Ich halte diese Annahme für falsch. BYOA (Bring Your Own Agent) – der Ansatz von Red Hat AI, bei dem die Plattform eine Produktionsinfrastruktur für jedes Agenten-Framework ohne Codeänderungen bereitstellt – geht von der gegenteiligen Prämisse aus.

Red Hat tritt nicht auf der Framework-Ebene in den Wettbewerb. Unabhängig davon, ob Ihr Agent auf LangChain, CrewAI, Claude Agents, Google ADK, Strands oder benutzerdefiniertem Python basiert, Red Hat AI operationalisiert ihn. Der Agenten-Code, den Ihr Team in der Entwicklung geschrieben hat, ist derselbe Code, der in der Produktion ausgeführt wird. Identität, Sandboxing, Tool Governance, Tracing, Evaluierung und Lifecycle-Management werden von der Plattform bereitgestellt – nicht von den Agent-Entwickelnden geschrieben. Zudem ist die Produktionsinfrastruktur über jedes Framework im Unternehmen hinweg konsistent.

Für Entscheidungstragende bedeutet dies, dass die Investition des Unternehmens in das gewählte Framework nicht verloren ist. Teams müssen sich nicht zwischen ihrem bevorzugten Framework und einer Produktionsinfrastruktur entscheiden, die die Compliance mit regulatorischen Anforderungen unterstützt – sie erhalten beides. Die Plattform bringt die Produktionsinfrastruktur zum Framework, nicht umgekehrt.

BYOA markiert zudem den Übergang vom Mieten der KI-Infrastruktur hin zum Eigenbesitz. Red Hat identifiziert 4 Säulen der digitalen Souveränität: Datensouveränität, technologische Souveränität, operative Souveränität und Sicherheitssouveränität. Die BYOA-Plattform adressiert alle 4 Säulen, auf die wir in kommenden Blog-Artikeln näher eingehen werden.

Dieselbe Plattforminfrastruktur, die einen autonomen SRE-Agenten (Site Reliability Engineer) unterstützt, kann auch einen Onboarding-Assistenten der Personalabteilung, einen Workflow zur Genehmigung der Beschaffung oder einen Eskalations-Bot für den Kundenservice unterstützen – die Infrastruktur ist domänenunabhängig, auch wenn sich die Use Cases unterscheiden.

Red Hat liefert Starterkits für LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK und weitere mit bereits integrierter Plattformanbindung – Authentifizierung, MCP-Verbindung (Model Context Protocol) und Tracing-Initialisierung. Teams beginnen mit der Entwicklung an Day 0, nicht erst nach wochenlanger Integrationsarbeit.

Die Entscheidung, die Ihnen bereits bekannt ist

Day 0 statt Wochen – diese Formulierung sollte Ihnen bekannt vorkommen. Vor einem Jahrzehnt standen Unternehmen vor der gleichen Frage bei Containern: Jedes Team konnte einen Container erstellen, aber niemand konnte Container in der Produktion mit konsistenter Sicherheit, Vernetzung und Lifecycle-Management im gesamten Unternehmen betreiben. Die Antwort lautete nicht „Wählen Sie eine bessere Container-Runtime“, sondern Red Hat OpenShift – eine Plattform, die jede Container-Runtime mit der Infrastruktur operationalisierte, die die Runtimes nicht mitlieferten. Was wir hier besprechen, kommt Ihnen bekannt vor, da Red Hat AI darauf basiert.

Die Agentenlücke hat dieselbe Form. Die Frage lautet nicht: „Welches Framework sollte ich verwenden?“ Diese Entscheidung haben Sie bereits getroffen, und sie war wahrscheinlich richtig. Die Frage ist: „Wer stellt die Produktionsinfrastruktur bereit, die mein Framework nicht liefert?“ – und die erste zu schließende Lücke ist die, bei der die Distanz zwischen Entwicklung und Produktion am größten ist. Das ist die Sicherheit, und unser nächster Blog-Artikel setzt dort an.

Erste Schritte

Sind Sie bereit, die Produktionslücke für Ihre Agenten zu schließen?

• Testen Sie OpenShift AI kostenlos in der Developer Sandbox: Erstellen und testen Sie Agenten kostenlos in einer vorkonfigurierten Umgebung.
• Entdecken Sie die BYO Agent-Starterkits: Vorkonfigurierte Vorlagen für LangGraph, CrewAI, LlamaIndex, Langflow, Google ADK und mehr.
• Belegen Sie den kostenlosen Kurs Red Hat AI Foundations: Praxisorientierte Labs zu den Grundlagen der Entwicklung mit Red Hat AI.
• Mehr über Red Hat AI erfahren: Plattformüberblick und Funktionen der Produktionsinfrastruktur.
• Operationalisierung von BYOA auf Red Hat AI: Die OpenClaw-Edition: Sehen Sie sich BYOA in der Praxis mit einem echten Agenten-Deployment an.