Die beiden vorangegangenen Referenzstücke beschreiben, worauf ein sprachmodellbasierter Agent rechnet. Dieses beschreibt, was ihn zum handelnden System macht. Denn ein Sprachmodell allein handelt nicht: Es erzeugt Text. Erst eine Umgebung, die diesen Text in Werkzeugaufrufe übersetzt, Ergebnisse zurückspielt, Zwischenstände speichert und irgendwann abbricht, macht daraus ein handelndes System. Diese Umgebung ist die Orchestrierungsschicht.

Für Agenten ohne Sprachmodell – Regelmaschinen, Zustandsautomaten, Planungs- und Optimierungsverfahren, Reinforcement-Learning-Systeme – gilt derselbe Satz mit anderer Begründung: Auch dort steckt die Handlungsfähigkeit nicht im Entscheidungskern, sondern in der Schicht, die ihn an Daten, Werkzeuge und Freigaben anbindet. Der Unterschied ist, dass diese Schicht dort meist älter, formaler und besser dokumentiert ist.

In den Enzyklopädie-Einträgen dieses Dossiers steht sie unter „Orchestrierung“ und „Ausführungsschicht“. Die Kategorie ist kein technisches Beiwerk. Sie entscheidet darüber, ob sich im Nachhinein rekonstruieren lässt, warum ein Agent getan hat, was er getan hat – und ob jemand ihn hätte aufhalten können.

Befund 01Die Frameworkwahl ist keine Geschmacksfrage

Die verbreitete Darstellung sortiert die Werkzeuge nach Bequemlichkeit: das eine sei schneller im Prototyp, das andere mächtiger in der Produktion. Das stimmt, greift aber zu kurz. Für ein reguliertes Haus ist die relevante Unterscheidung eine andere: Welche Bauform erzeugt von sich aus einen prüfbaren Ablauf, und welche erzeugt eine Unterhaltung, die man hinterher interpretieren muss?

Der Markt bewegt sich sichtbar in Richtung der ersten Bauform. Graphbasierte Orchestrierung hat 2026 in der Verbreitung aufgeschlossen und teils überholt, und der Grund, den die Anwender nennen, ist selten Eleganz: Die Graphstruktur bildet ab, was Produktionsbetrieb ohnehin verlangt – definierte Zustände, Wiederaufsetzpunkte, Prüfstellen. Microsoft hat seine beiden Linien zusammengeführt und im April 2026 eine vereinheitlichte Fassung als allgemein verfügbar erklärt. Die Konsolidierung ist selbst ein Befund: Die Experimentierphase der Orchestrierungswerkzeuge geht zu Ende.

Befund 02Der Steckerstandard und seine Nebenwirkung

Die größere Verschiebung der vergangenen zwei Jahre ist nicht ein einzelnes Framework, sondern ein Protokoll. Mit dem Model Context Protocol hat sich eine gemeinsame Schnittstelle zwischen Modellen und Werkzeugen durchgesetzt: Datenbanken, Dokumentenspeicher, interne Dienste und externe Fachanwendungen melden sich über dasselbe Verfahren an, und jedes größere Framework unterstützt es inzwischen nativ oder über einen Adapter.

Der Nutzen ist erheblich. Werkzeuge werden austauschbar, Integrationen wandern zwischen Frameworks, der Aufwand für Anbindungen sinkt. Genau darin liegt jedoch die Nebenwirkung: Was austauschbar ist, wird auch angeschlossen, ohne dass jedes Mal jemand hinsieht.

Ein Werkzeug meldet sich bei einem Agenten mit einer Beschreibung an – Name, Zweck, Parameter, Hinweise zur Verwendung. Diese Beschreibung landet im Kontext des Modells und wirkt dort wie eine Anweisung. Damit ist eine Grenze verwischt, die in klassischen Systemen sorgfältig gezogen wird: die Grenze zwischen Programm und Eingabe. Die Werkzeugbeschreibung ist Eingabe von einem Dritten, wird aber mit der Autorität einer Systemanweisung gelesen.

Befund 03Werkzeugvergiftung als Standardangriff

Die Sicherheitsforschung hat daraus einen eigenen Angriffstyp gemacht. Bei der Werkzeugvergiftung werden Anweisungen in den Metadaten eines Werkzeugs versteckt – in Beschreibungstexten, Parameterhinweisen, Rückgabefeldern. Der Agent liest sie, hält sie für Teil seiner Aufgabenstellung und handelt entsprechend. Kein Systemzugriff, kein ausgenutzter Programmfehler, keine Signatur, auf die ein Sicherheitswerkzeug anspringt.

Eine 2026 veröffentlichte Bedrohungsmodellierung hat das Protokoll systematisch über fünf Komponenten hinweg untersucht – Client, Modell, Server, angebundene Datenspeicher und Autorisierungsdienst – und anschließend sieben verbreitete Clientprogramme daraufhin geprüft, wie sie Werkzeugbeschreibungen validieren. Ergebnis: Die Werkzeugvergiftung ist die häufigste und wirksamste Schwachstelle auf der Clientseite, und die Mehrzahl der geprüften Programme wies erhebliche Lücken auf, weil Beschreibungen kaum statisch geprüft und Parameter dem Nutzer nicht sichtbar gemacht werden.

Eine zweite Analyse benennt auf Protokollebene drei andere strukturelle Schwächen: Es fehlt eine Attestierung der tatsächlich angebotenen Fähigkeiten, die bidirektionale Modellabfrage kennt keine belastbare Herkunftsauthentifizierung, und in Konfigurationen mit mehreren Servern wird Vertrauen implizit weitergereicht. Die Sicherheitsgemeinschaft führt Werkzeugvergiftung inzwischen als eigenständige Angriffsklasse.

Befund 04Was die Schicht leisten muss, damit sie Kontrolle heißt

Die Orchestrierungsschicht wird in Präsentationen gern als „Governance-Layer“ bezeichnet. Der Begriff ist erst dann berechtigt, wenn sie fünf Dinge tatsächlich tut – und diese fünf Punkte kehren als Prüfraster in jedem Branchenartikel dieses Dossiers wieder.

Die rechte Spalte ist der Grund, warum zwei Häuser mit demselben Framework und demselben Modell unterschiedlich prüfbar sind. Ein technisches Ablaufprotokoll beantwortet, welche Funktion mit welchen Parametern aufgerufen wurde. Ein fachliches Entscheidungsprotokoll beantwortet, welche Belege zu welcher Bewertung geführt haben. Nur das zweite ist im Aufsichtsgespräch verwertbar, und kein Framework liefert es mit.

Watchdog-WinkelWarum das in der Geldwäschebekämpfung besonders zählt

Ein Agent in der Alert-Bearbeitung hat naturgemäß Zugriff auf das, was ein Angreifer sucht: Kundenstammdaten, Transaktionshistorien, Bewertungslogik, in Teilen den Bearbeitungsstand von Verdachtsfällen. Er ist zugleich ein System, dessen Eingaben zu einem erheblichen Teil aus Quellen stammen, die außerhalb der Kontrolle des Hauses liegen – Handelsregisterauszüge, Sanktions- und Medienrecherchen, Dokumente aus dem Onboarding.

Damit trifft die Werkzeugvergiftung auf einen zweiten, bereits beschriebenen Angriffsweg: die Manipulation der Belege, auf die sich ein Agent stützt. Beide Wege haben dieselbe Eigenschaft. Der Agent nutzt ausschließlich erlaubte Werkzeuge, protokolliert vollständig und entscheidet trotzdem falsch, weil seine Prämissen manipuliert wurden. Klassische Sicherheitsüberwachung sieht davon nichts, weil technisch nichts Unerlaubtes passiert.

Für die Enzyklopädie folgt daraus eine Festlegung: In den Branchenartikeln wird unter „Stack & Orchestrierung“ nicht nur genannt, welches Framework im Einsatz ist, sondern ob die Werkzeuganbindung einer Freigabe unterliegt. Wo diese Angabe fehlt oder nicht zu ermitteln ist, wird sie als Lücke ausgewiesen – nicht als Nebensache.

Die Orchestrierungsschicht ist damit der Ort, an dem sich entscheidet, ob ein Agent ein prüfbares System oder eine gut dokumentierte Blackbox ist. Sie ist auch der Ort, an dem die Zuständigkeit zwischen Fachbereich, IT und zweiter Verteidigungslinie am häufigsten ungeklärt bleibt. Wer die Haftungsfrage beantworten will, kommt an dieser Schicht nicht vorbei. Dasselbe gilt für die Budgetgrenze: Erst hier wird sie zur technisch wirksamen Abbruchbedingung.