KI-Agenten-Framework: Build vs. Buy im Kreuzfeuer

Die Landschaft der KI-Agenten-Frameworks hat sich in den letzten achtzehn Monaten vom Experiment zum Beschaffungsdruck verschoben. Teams, die Agentenorchestrierung als Prototyp-Frage betrachteten, stehen nun vor Produktionsvorfällen. Diese Analyse behandelt, was sich technisch geändert hat, welches Risiko jede Verschiebung mit sich bringt und welche Build-versus-Buy-Entscheidung sie erzwingt.

Die Protokollstandardisierung wird zum eigentlichen Burggraben

Auf der Governance-Seite ist der folgenreichste Schritt die Übertragung des A2A-Protokolls in die Obhut der Linux Foundation. Dass die Agent-zu-Agent-Kommunikation den Orbit eines einzelnen Anbieters verlässt, ist das richtige Signal.

Das Model Context Protocol (MCP) folgt derselben Bahn. Eine von einem neutralen Gremium verwaltete Spezifikation ist ein Standard zum Übernehmen, kein zu bewertendes Anbieterprodukt.

Meine feste Position: Die Standardisierung der Kommunikationsebene wird den Wettbewerbsvorteil in agentischen Systemen entscheiden – noch vor der reinen Modellleistung. Wer kontrolliert, wie Agenten kommunizieren, kontrolliert die Architektur. Die Modellqualität konvergiert über die Anbieter hinweg, während die Verbindungsebene Stacks über Jahre bindet.

Die Sicherheitslage hinkt der Infrastrukturreife um Jahre hinterher

Die veröffentlichten CVEs gegen Semantic Kernel sind das verräterische Zeichen. Für Führungskräfte lesen sie sich wie Anomalien, doch sie signalisieren ein Feld, das in Produktion geht, bevor seine Härtungspraktiken reif sind.

Das wiederholt ein dokumentiertes Muster. Webanwendungen durchliefen es in den 2000ern. APIs verarbeiteten dieselbe Lektion in den 2010ern.

Agenten-Frameworks befinden sich nun in derselben unreifen Phase. Für einen CTO ist die Implikation direkt: Jede Framework-Auswahl muss die Kadenz der Hinweise und die Patch-Disziplin des Anbieters ebenso stark gewichten wie den Funktionsumfang. Ein Framework, das schneller Funktionen als Korrekturen ausliefert, ist technische Schuld im Roadmap-Gewand.

Prompt Injection ist der am meisten unterschätzte Enterprise-Angriff

Prompt Injection bleibt die Angriffsfläche, die Enterprise-KI-Teams unterschätzen. Ein von einem Retrieval-System abgerufenes Dokument trägt dieselben Anmeldeinformationen wie der Nutzer, der die Abfrage ausgelöst hat.

Ein einziges abgerufenes Artefakt genügt, um das Verhalten eines Agenten umzulenken. Die meisten RAG-Architekturen in Produktion behandeln abgerufene Dokumente als vertrauenswürdige Eingabe. Diese Annahme ist falsch.

Der Mechanismus ist simpel. Das Modell liest im abgerufenen Text eingebettete Anweisungen und führt sie mit den Rechten des Aufrufers aus. Aktivierte Auto-Invocation mit lockeren Ausführungsgrenzen macht aus einem manipulierten Dokument einen Ausführungspfad.

Teams unter dem Head of Engineering sollten jedes abgerufene Artefakt als nicht vertrauenswürdige Eingabe behandeln, Tool-Aufrufe in einer Sandbox isolieren und die Herkunft jedes Dokuments protokollieren, das das Kontextfenster erreicht.

Multi-Agenten-Pipelines fallen ohne Circuit Breaker kaskadierend aus

Multi-Agenten-Systeme in Produktion ohne explizite Circuit Breaker werden kaskadierend ausfallen. Das ist Arithmetik, keine Prophezeiung.

Die in der Agenten-Zuverlässigkeitsforschung dokumentierte Halluzinationskaskade gilt für jede Pipeline, in der die Ausgabe eines Agenten zur Eingabe des nächsten wird, ohne unabhängige Validierung. Der Fehler kumuliert bei jedem Schritt.

Man betrachte eine dreistufige Pipeline. Eine moderate Fehlerrate pro Stufe multipliziert sich über die Stufen, und die aggregierte Zuverlässigkeit sinkt weit unter das, was jede Komponente isoliert meldet.

Die Design-Antwort ist langweilig und wirksam: unabhängige Validierung zwischen den Stufen, explizite Circuit Breaker und Fehlertoleranz, die auf Pipeline-Ebene statt pro Agent modelliert wird. Lesen Sie unsere Notizen zur Multi-Agenten-Zuverlässigkeit zu den Fehlermodi.

Halluzinationsraten setzen die Untergrenze der Zuverlässigkeit

Die Halluzinationsraten aktueller Modelle variieren stark je nach Aufgabe und Datensatz. Behandeln Sie veröffentlichte Einzelwertangaben mit Misstrauen; sie komprimieren eine Verteilung zu einer Marketingzahl.

Für eine Agenten-Pipeline ist die relevante Kennzahl der über die Schritte kumulierte Fehler, nicht ein Einzelmodell-Score. Ein Modell, das isoliert gut abschneidet, verschlechtert sich, sobald seine Ausgabe einen weiteren Agenten speist.

Deshalb zählt die Validierung zwischen den Stufen mehr als die Wahl des Modells mit dem höchsten Score. Zuverlässigkeit ist eine Systemeigenschaft. Sie entsteht aus der Architektur, nicht aus einer einzelnen Model Card.

Benchmarks verdienen Prüfung: Fordern Sie den Datensatz, das Testdatum und die Modellversion hinter jeder Zahl. Anbieter-Leistungsangaben ohne unabhängige Benchmarks haben null Gewicht in der Beschaffung.

Architektonisches Lock-in ist die Beschaffungsfalle

Die zentrale Frage, die ich an jeden Agenten-Stack stelle: Ist diese Architektur eine Falle oder ein Wettbewerbsvorteil? Lock-in versteckt sich in der Orchestrierungsebene.

Ein Framework, das Ihre Agentenlogik an proprietäre Primitive koppelt, erhöht die Wechselkosten schleichend. Zwei Jahre später wird die Migration zum Neuschreiben, und der Anbieter hält den Preishebel.

Frameworks, die auf der standardisierten Ebene (A2A, MCP) aufbauen, verringern diese Exposition. Die Portabilität von Agentendefinitionen über Runtimes hinweg ist die Eigenschaft, die ein Beschaffungsgremium schriftlich fordern sollte.

Für den CFO ist die Rechnung konkret. Eine an offene Protokolle angelehnte Infrastrukturinvestition trägt ein geringeres Umkehrrisiko. Eine Wette auf proprietäre Orchestrierung erhöht die Kosten jedes künftigen Ausstiegs.

Drei Fragen für Enterprise-KI-Teams

Prüfen Sie den Stack vor dem nächsten Planungszyklus anhand dreier operativer Fragen. Jede lässt sich einem Entscheidungsträger zuordnen.

1. Behandelt das Framework abgerufene Dokumente standardmäßig als nicht vertrauenswürdige Eingabe?
2. Sind Circuit Breaker und unabhängige Validierung zwischen den Agentenstufen vorhanden?
3. Veröffentlicht der Anbieter Sicherheitshinweise mit dokumentierter Patch-Kadenz?

Ein Framework, das an einem dieser Punkte scheitert, ist ein Produktionsrisiko – ungeachtet der Benchmark-Schlagzeilen. Unterscheiden Sie klar zwischen verfügbar, produktionsreif und Beta. Anbieter verwischen diese Kategorien in Verkaufszyklen.

Siehe unsere KI-Beschaffungs-Checkliste für die vollständige Bewertungsmatrix.

Entscheidungen für den nächsten Planungszyklus

Entscheidungen für CTO und Head of Engineering für den nächsten Planungszyklus: Frameworks priorisieren, die an von der Linux Foundation verwaltete Protokolle angelehnt sind, und anbietereigene Orchestrierung als Lock-in-Signal behandeln.

Das Sicherheitsbudget zugunsten der Prompt-Injection-Abwehr und der Retrieval-Herkunft umschichten. Diese Angriffsfläche ist in den meisten Enterprise-Teams heute unterfinanziert.

Für das Beschaffungsgremium: Jeden Vertrag neu verhandeln, der Sie an eine geschlossene Kommunikationsebene bindet. Der Standardisierungstrend verschafft Ihnen einen Hebel, der in den letzten zwölf Monaten entstanden ist.

Die Engineering-Haltung, die den Kontakt mit der Produktion übersteht, ist unglamourös: nicht vertrauenswürdige Eingaben, validierte Schritte, gepatchte Abhängigkeiten, portable Definitionen. Bauen Sie darauf, und die Framework-Wahl wird umkehrbar statt zu einer jahrzehntelangen Bindung.