Quelle auf.

Ich stelle ChatGPT Fragen, bei denen ich selbst nicht weiß, ob meine Ausgangsannahme stimmt. Statt einer schnellen Antwort soll ChatGPT recherchieren, Quellen prüfen und offenlegen, worauf die Antwort beruht.

Warum ich diesmal frage: Meine Vergangenheit in der Webentwicklung ist stark von Wiederverwendung geprägt. Wenn etwas mehrfach gebraucht wird, liegt der Gedanke nahe, daraus ein Framework, eine Bibliothek oder einen anderen Baustein zu machen. Bei KI-Systemen meldet sich derselbe Reflex: Warum Modellzugang, Retrieval, Tools, Rechte, Logging, Evaluation und Provider immer wieder neu zusammensetzen? Gleichzeitig frage ich mich, ob wir damit bereits Lösungen abstrahieren, bevor wir die eigentlichen Anwendungsformen gut genug verstanden haben.

Meine Frage: Ist es heute schon sinnvoll, einen allgemeinen Baukasten für KI-Anwendungen zu entwickeln – und wenn ja, was ist bereits stabil genug, um darin standardisiert zu werden?

Hier ist die Antwort von ChatGPT:

Der sinnvolle KI-Baukasten ist kein neues Universal-Framework

Die kurze Antwort lautet: Als allgemeine Zielarchitektur: nein. Als dünne, organisationsspezifische Werkbank auf vorhandenen Standards und Frameworks: ja. Nicht ausreichend begründet ist ein eigener allgemeiner Baukasten, der Agenten, Retrieval, Memory und Provider noch einmal zu einer gemeinsamen Anwendungsform erklärt.

Mit Baseline ist dabei der verbindliche Mindestbestand gemeint, den produktive Projekte für Sicherheit, Prüfung und Betrieb mitbringen sollen. Nicht die Anwendung wird vereinheitlicht, sondern das, was die Organisation bei jeder Anwendung zuverlässig wissen und beherrschen muss.

Der Unterschied liegt nicht nur zwischen groß und klein. Er liegt zwischen zwei Arten von Wiederverwendung.

Die erste standardisiert Probleme, die fast jedes produktive System ohnehin lösen muss: Wer darf welches Werkzeug aufrufen? Wo liegen Secrets? Was kostet ein Lauf? Was ist passiert? Wie wird eine Änderung getestet, freigegeben und im Fehlerfall gestoppt?

Die zweite standardisiert eine Vorstellung davon, wie eine KI-Anwendung grundsätzlich auszusehen hat: Chat vorne, Retrieval in der Mitte, Agentenschleife darum, Memory daneben, mehrere Provider darunter. Genau dort wird der Baukasten leicht vom Werkzeug zur Vorgabe.

Das Web ist keine Reifeuhr

Der Vergleich mit der Webentwicklung legt eine einfache Geschichte nahe. Websites, Shops und CMS wiederholten sich lange genug, irgendwann entstanden daraus Frameworks und Standardsoftware. Generative KI sei dagegen noch jung. Also müssten wir nur warten, bis ihre Anwendungsformen ähnlich klar sind.

So einfach ist es nicht.

Auch Webframeworks waren frühe, begrenzte Wetten auf bestimmte wiederkehrende Probleme. Sie mussten nicht erst das gesamte Web verstehen. Entscheidend war, dass ihre jeweilige Grenze tragfähig genug war.

David Parnas beschrieb Modularität schon 1972 nicht als möglichst vollständige Sammlung gemeinsamer Funktionen. Eine gute Zerlegung versteckt Entwurfsentscheidungen, begrenzt das Wissen zwischen Modulen und erlaubt, Teile auszutauschen, ohne das ganze System neu zusammenzusetzen. Das ist für KI die nützlichere Lehre aus der Webentwicklung.¹

Die Frage lautet deshalb nicht: Ist GenAI alt genug für Frameworks?

Sie lautet: Welche konkrete Verantwortung wiederholt sich häufig genug, lässt sich prüfen und austauschen – und welche Abstraktion macht nur ihre heutige Form zur Vorschrift?

„Baukasten“ nennt mindestens fünf verschiedene Arten der Wiederverwendung

Wer von einem KI-Baukasten spricht, kann sehr verschiedene Dinge meinen. Mit Runtime ist hier die Laufzeitschicht gemeint, die Modellaufrufe, Tools und Workflows tatsächlich ausführt. Ein Golden Path ist ein kuratierter, empfohlener Weg zum Projektstart. Die Recherche ergibt für diese Arten der Wiederverwendung nicht dieselbe Antwort.

Diese Trennung ist die wichtigste Antwort der Recherche. Das Ökosystem ist nicht leer. Es standardisiert längst verschiedene Arten von Dingen.

Dapr kapselt beispielsweise alte verteilte Systemprobleme wie State, Pub/Sub, Workflows, Secrets und Konfiguration. Haystack standardisiert Komponenten und ihre Ausführung als verzweigte oder zyklische Pipeline. Backstage Software Templates standardisieren, wie ein kuratierter Projektstart erzeugt wird. Keiner dieser Ansätze entscheidet allein, welche KI-Anwendung fachlich richtig ist.

Diese Unterscheidung ist nicht akademisch. Sie entscheidet, ob der Baukasten hilft oder behindert. Das klingt nach einer Wortklauberei, bis man den falschen Baukasten warten muss.

Anschlüsse werden stabiler als Anwendungen

MCP ist inzwischen eine ernstzunehmende Protokollgrenze zwischen Anwendungen und Tools oder Kontextquellen. Die Spezifikation definiert Hosts, Clients, Server, Ressourcen, Prompts, Tools und das Aushandeln unterstützter Fähigkeiten. Sie sagt zugleich ausdrücklich, dass sie Zustimmung, Berechtigung und Datenschutz nicht erzwingen kann. Das muss die umgebende Anwendung tun.²

Damit ist der Anschluss eines Tools standardisierbar. Die Erlaubnis, dass dieses Tool eine Rechnung storniert, einen Datensatz versendet oder eine Datei überschreibt, ist es nicht auf dieselbe Weise.

A2A verschiebt die Grenze noch ein Stück weiter. Die im März 2026 veröffentlichte Version 1.0 beschreibt Discovery, Nachrichten, Tasks und Ergebnisübermittlung zwischen eigenständigen Agentensystemen. Die erste Recherche hatte Multi-Agent-Systeme deshalb zu pauschal auf die instabile Seite sortiert. Die Kommunikation zwischen Agenten kann bereits standardisiert werden.³

Was A2A nicht beantwortet: Braucht die Anwendung überhaupt mehrere Agenten? Wer darf delegieren? Welcher Agent kennt welchen Zustand? Wann muss ein Mensch zustimmen? Was geschieht, wenn zwei Systeme widersprüchliche Ergebnisse liefern?

Das Protokoll ist stabiler als die Organisation, die es verbindet. In dieser Hinsicht hat HTTP schließlich auch nicht festgelegt, welche Website gebaut werden sollte.

Selbst Runtimes sind nicht mehr bloß Experiment

Ein zweiter Einwand gegen die vorsichtige Ausgangsthese ist ebenfalls berechtigt: Einige Agenten-Projekte erklären ihre Runtime-Kerne inzwischen für stabil.

Microsoft veröffentlichte im April 2026 sein Agent Framework 1.0 für .NET und Python mit stabil erklärten APIs und langfristigem Support. Pydantic AI v2 beschreibt den einfachen Agentenloop – Modell aufrufen, Tool ausführen, Ergebnis zurückgeben – als gesetzten Kern.⁴

Die Details dieser Quellen sind fast interessanter als das 1.0-Schild. Microsoft trennt stabile Kernfunktionen von weiter als Preview geführten Fähigkeiten. Pydantic hält den Core bewusst klein und verschiebt Memory, Guardrails, Dateisystemzugriff und weitere Fähigkeiten in einen schneller beweglichen Harness. Das minimale Fenster bis zu einer neuen Major-Version verkürzte das Projekt auf drei Monate, ausdrücklich weil sich das Feld schnell verändert.

Das ist kein Widerspruch. Ein kleiner Kern kann stabil sein, während sein Rand in Bewegung bleibt.

Für einen eigenen Baukasten ist das allerdings eher ein Kill-Kriterium als eine Einladung. Wer Modellzugang, Provider, Agentenloop, Tools und Workflow noch einmal kapselt, baut wahrscheinlich etwas nach, das bereits existiert. Ein Eigenbau braucht einen Zweck, den diese Frameworks nicht liefern.

Ein solcher Zweck könnte sein:

• die Zugriffsentscheidung mit dem eigenen Rollenmodell zu verbinden;
• Datenklassifikation und zulässige Provider durchzusetzen;
• Modell- und Toolaufrufe gemeinsam zu auditieren;
• Kostenbudgets und Zeitlimits zentral zu erzwingen;
• Evaluationen in Release-Gates einzubauen;
• einen geprüften Projektstart mit Dokumentations- und Incident-Pflichten zu erzeugen.

„Bei uns gibt es nur eine API“ ist noch kein Zweck. Manchmal bedeutet es nur, dass alle Unterschiede nun hinter derselben Tür stehen.

Eine zusätzliche interne Schicht kann trotzdem gerade deshalb sinnvoll sein, weil sie eine volatile Framework- oder Providerentscheidung verbirgt. Das wäre eine Informationsgrenze im Sinne von Parnas. Der Kill-Test ist daher nicht bloß, ob etwas doppelt implementiert wird. Er lautet: Versteckt die Schicht eine wechselhafte Entscheidung hinter einem kleinen, prüfbaren und nachweislich nützlichen Vertrag – oder versteckt sie nur Unterschiede?

Der wertvollste gemeinsame Baustein kann absichtlich unvollständig sein

Nehmen wir Evaluation. Ein gemeinsamer Eval-Harness, also ein Testrahmen, kann Fälle versionieren, Konfigurationen ausführen, Ergebnisse archivieren, Baselines vergleichen und einen Release blockieren. Das ist gut wiederverwendbar.

Der Harness kann aber nicht allgemein bestimmen, was ein guter Fall ist. Bei einer Dokumentensuche kann ein falsches Zitat entscheidend sein. Bei einer Formulierungshilfe vielleicht Ton und Auslassung. Bei einer Agentenaktion geht es zusätzlich darum, ob eine Wirkung erlaubt, reversibel und korrekt protokolliert war.

Das freiwillige NIST GenAI Profile beschreibt genau diese Rückbindung an Task und Einsatzkontext: empirisch testen, Grenzen dokumentieren, unter realitätsnahen Bedingungen prüfen, im Betrieb beobachten, Feedback und Incidents behandeln. Es liefert keine universelle Punktzahl und keinen Testsatz für alle Anwendungen.⁵

Die wiederverwendbare Form lautet also nicht evaluate(prompt). Sie lautet eher:

Hier ist der gemeinsame Runner. Dieses Team muss die fachlichen Fälle, Fehlertypen, Grenzwerte, Freigaberollen und Eskalationswege liefern.

Evaluation und Telemetrie folgen damit demselben Muster: Die gemeinsame Mechanik ist wiederverwendbar, ihre fachliche Bedeutung bleibt kontextspezifisch. Dauer und Tokenverbrauch wiederholen sich. Fachliche Qualität nicht. OpenTelemetry hat dafür bereits GenAI-Konventionen, bezeichnet sie aber noch als aktiv entwickelt. Das ist ein guter Grund für zentrale Beobachtbarkeit und zugleich für eine Versionsgrenze um die konkrete Semantik.⁶

Die falsche Abstraktion erkennt man an ihren Sonderfällen

Sandi Metz beschreibt ein bekanntes Muster: Zwei Fälle sehen gleich aus und werden abstrahiert. Der dritte passt beinahe. Also bekommt die Abstraktion einen Parameter und einen bedingten Pfad. Nach einigen Runden verhält sich die ehemals gemeinsame Idee je nach Fall anders.⁷

Bei einem KI-Baukasten sind die Warnzeichen leicht zu erkennen:

• ein universelles Agent-Objekt, dessen Flags Toolwahl, Memory, Streaming, Freigaben und Multi-Agent-Verhalten steuern;
• provider == ...-Zweige in der fachlichen Kernabstraktion;
• eine gemeinsame RAG-Pipeline, obwohl Chunking, Aktualität, Ranking und Zitierpflicht je Anwendung anders sind;
• generische Evals ohne benannten fachlichen Fehler;
• ein Chatfenster als Standardoberfläche, obwohl der Arbeitsprozess einen Diff, eine Vorschau, eine Queue oder nur einen einmaligen Vorschlag braucht;
• optionale Fähigkeiten, die fast niemand verwendet, aber jedes Team verstehen, aktualisieren und absichern muss.

Dann droht der Baukasten, Komplexität nicht mehr zu reduzieren, sondern sie an einer Stelle zu sammeln, an der sie schlechter zu sehen ist.

Die bessere Gegenprobe ist praktisch: Kann eine Komponente ersetzt werden? Gibt es einen dokumentierten Ausgang? Können Teams eine neue Providerfunktion verwenden, bevor die zentrale Abstraktion sie übersetzt hat? Wird der gemeinsame Kern mit jeder Anwendung kleiner und klarer – oder größer und bedingter?

Nicht zu standardisieren hat ebenfalls einen Preis

Das stärkste Gegenargument gegen Zurückhaltung lautet: Warten erzeugt Doppelarbeit.

Ohne gemeinsamen Pfad integriert jedes Team Provider, Telemetrie, Berechtigungen und Evaluation selbst. Änderungen an Protokollen und APIs müssen mehrfach nachvollzogen werden. Manche Anwendungen protokollieren Toolaufrufe, andere nur Modellantworten. Manche haben ein Kostenlimit, andere entdecken es auf der Rechnung. Ein unfertiger gemeinsamer Standard kann dann besser sein als fünf unverbundene Einzellösungen.

Dabei sind nicht alle Kosten gleich. Eine Providerintegration kann einmalig sein; die Pflege von Berechtigungen, Telemetrie und Migrationen bleibt dauerhaft. Eine gemeinsame Schicht verursacht ihrerseits laufende Wartung. Sie lohnt sich nur, wenn die vermiedene Doppelarbeit und die gemeinsam durchgesetzten Regeln diese Kosten überwiegen.

Das Gegenargument trägt.

Deshalb wäre die Forderung falsch, erst nach Jahren und vielen identischen Anwendungen zu standardisieren. Ein „gut genug“ entworfener Golden Path kann heute vernünftig sein, wenn mindestens diese Bedingungen gelten:

1. Er benennt, welches wiederkehrende Problem er zentral löst.
2. Seine Verantwortung, sein prüfbarer Vertrag und seine Fehlerwirkung sind benannt.
3. Er trennt stabilen Kern und beweglichen Rand.
4. Er versioniert Abhängigkeiten und rechnet mit Migration.
5. Er erlaubt begründete Abweichung, ohne dass ein Team die gesamte Baseline verliert.

Stabilität bedeutet dann nicht Unveränderlichkeit. Sie bedeutet, dass Änderung beherrschbar ist.

Ein Baukasten kann den Blick verengen – bewiesen ist das nicht

Ein kuratierter Katalog kann verändern, was leicht erreichbar ist. Wenn dort Chatbot, RAG Assistant und Multi-Agent Workflow stehen, erscheinen diese Formen normal. Eine andere Arbeitsoberfläche kann dann mit mehr Rechtfertigungsaufwand beginnen.

Das macht einen Baukasten zu einer stillen Ontologie: Er sagt Teams nicht nur, wie sie etwas bauen können, sondern auch, aus welchen Dingen eine KI-Anwendung angeblich besteht.

Die Recherche hat allerdings keine Studie gefunden, die zeigt, dass KI-Golden-Paths dadurch tatsächlich Innovation verhindern. Die Transformationsgefahr bleibt eine plausible Warnung, kein Befund.

Gegen eine pauschale Abwertung inkrementeller Anwendungen sprechen zudem reale Ergebnisse. In einer Feldstudie mit 5.172 Beschäftigten im Kundensupport stieg die Zahl gelöster Fälle pro Stunde mit einem KI-Assistenten im Mittel um rund 15 Prozent. Weniger erfahrene beziehungsweise niedriger qualifizierte Beschäftigte profitierten stärker. Die Autoren beschränken das Ergebnis ausdrücklich auf eine Firma, einen Beruf und ein relativ stabiles Produkt- und Fragenset.⁸

Ein BCG/HBS-Experiment mit 758 Beratern zeigte gleichzeitig eine unregelmäßige Leistungsgrenze: Bei bestimmten Aufgaben waren Teilnehmende mit KI schneller und besser bewertet; bei scheinbar ähnlichen Aufgaben außerhalb dieser Grenze konnte die Leistung sinken.⁹

Die vernünftige Folgerung ist nicht, bekannte Prozesse entweder zu automatisieren oder auf die große neue Arbeitsform zu warten. Organisationen können beides tun:

• Wiederholte, messbare Anwendungen bekommen einen Produktionspfad mit stärkeren Standards.
• Exploration bekommt einen leichteren Pfad mit weniger Architekturannahmen und einem frühen Test der tatsächlichen Wirkung.

Ein erfolgreicher Versuch wird nicht deshalb zum Framework, weil er erfolgreich war. Erst Wiederholung zeigt, was an ihm wirklich gemeinsam ist.

Was heute in das gemeinsame Repository gehört

Die folgende Trennung ist meine Synthese aus den Quellen, kein veröffentlichter Industriestandard.

Technisch oder protokollarisch bereits stabilisierbar sind:

• bestehende Infrastruktur für Identität, Secrets, State, Workflows, Messaging, Timeouts und Deployment;
• schmale, versionierte Protokollgrenzen für Tools, Kontext und Agentenkommunikation;
• Zugriffsentscheidungen außerhalb des Modells und explizite Freigaben für folgenreiche Aktionen;
• Audit-, Telemetrie-, Kosten- und Zeitlimit-Mechanik.

Organisatorisch sinnvoll zu vereinheitlichen sind:

• ein Testrahmen für versionierte Fälle, Vergleiche und Release-Gates – nicht die fachlichen Fälle und Grenzwerte selbst;
• Projektgeneratoren und Schnittstellen zur Durchsetzung eigener Regeln;
• Monitoring, Feedback, menschliche Übersteuerung und Incident-Prozesse;
• ein Entscheidungsprotokoll vom Problem über Wirkung und Risiko zur ausgewählten Komposition.

Noch nicht als allgemeine Zielarchitektur belegt sind:

• Chat als Standardoberfläche;
• ein universelles Memory-Modell;
• eine feste RAG-Pipeline mit allgemeinen Defaults;
• ein gemeinsamer Autonomiegrad;
• eine Multi-Agent-Topologie – im Unterschied zum bereits standardisierbaren Kommunikationsprotokoll;
• domänenübergreifende Qualitätsmetriken und Freigabeschwellen;
• ein vollständiges gemeinsames Objektmodell, das angeblich jede Providerfähigkeit ohne Sonderfälle abbildet.

Damit fällt die Entscheidung kleiner aus als der ursprüngliche Entwicklerreflex.

Wenn ihr einen Baukasten baut, lasst ihn eine Werkbank sein, keinen Bauplan. In die Werkbank gehören Anschlüsse, Schutzvorrichtungen, Messmittel und ein ordentlicher Platz für Nachweise. Welche Anwendung darauf entsteht, sollte erst dann zum Standard werden, wenn reale Anwendungen ihre gemeinsame Form oft genug gezeigt haben.