Neun architektonische Säulen für produktionstaugliche agierende KI-Systeme
Erlernen Sie ein neunteiliges Architekturkonzept – das Zero-Trust-Netzwerke, Datenschichten sowie beweissichere Mechanismen umfasst – zur Entwicklung von überprüfbaren, unternehmensreifen agierenden KI-Systemen.
Die Lücke zwischen Demo und Produktivbetrieb, über die niemand spricht
Ein Prototyp eines KI-Agenten an einem Wochenende zu erstellen, ist einfach.
Man verbindet ein LLM mit einer Schleife zur Aufrufung von Tools, anschließend mit einem Vektorlagersystem und fügt eine Chat-Schnittstelle hinzu – plötzlich hat man etwas, das in einer Demo beeindruckend aussieht. Die Führung ist begeistert, die Ingenieure motiviert. Jemand kritzelt „Q3 Pilot“ an eine Tafel.
Doch sobald das System in Betrieb geht, kehrt die Realität zurück. Fast jede Organisation stößt in irgendeiner Reihenfolge auf dieselben Probleme:
Der Agent erstattet den falschen Betrag — weil niemand eine klare Trennlinie zwischen dem, was die KI entscheidet, und dem festgelegten, ausführbaren Logikablauf gezogen hat. Eine Sicherheitsprüfung verhindert den Start — weil Kundendaten heimlich über eine externe Embedding-API weitergeleitet wurden. Jemand aus der Compliance fragt, warum das System vor Monaten eine bestimmte Antwort gegeben hat — und es gibt keine Möglichkeit, die Begründung wiederherzustellen. Das riesige Agenten-Skript wird unzugänglich — weil Prompt-Engineering, Geschäftsregeln und API-Integration alles in einer Datei miteinander verknüpft sind. Die Ausgabe ändert sich nach einer routinemäßigen Neindeckung — und niemand kann wiederholen, was der Assistent im Vormonat gesagt hat.
Die unangenehme Realität ist folgende:
Die Wahl eines Modells war nie der schwierige Teil – das Strukturieren des Systems um dieses Modell herum schon.
Ein agileres System ist nicht einfach nur eine dünne KI-Schicht, die zu Skripten hinzugefügt wird. Im Grunde handelt es sich dabei um ein deterministisches Unternehmenssystem, das zufälligerweise einen probabilistischen Reasoning-Kern enthält – und es erfordert dieselbe ingenieurwissenschaftliche Disziplin wie eine Zahlungsplattform oder eine Kernbankinfrastruktur.
In dieser Serie wird ein vollständiges architektonisches Konzept zur Erstellung solcher Systeme vorgestellt. Es ist um neun zentrale Designentscheidungen – neun Säulen – strukturiert, die jede produktionsreife agierende Plattform gleichzeitig richtig umsetzen muss, denn wenn eine versagt, neigen die anderen dazu, ebenfalls zu versagen.
Unser aktuelles Beispiel: Aurora Bank
Die in der Zusammenfassung besprochene Architektur bleibt selten bestehen. Deshalb verankern wir in dieser Serie jedes Konzept in einem konkreten, wenn auch fiktiven Szenario:
Aurora Bank ist eine mittelgroße Privatbank mit 4.000 Mitarbeitern. Sie setzt "Aurora Assistant" ein – eine Agentenplattform, die dazu dient: — Fragen des Personals zu Richtlinien und Compliance zu beantworten, — den Kreditverarbeitungsprozess zu unterstützen (Dokumente abrufen, Details überprüfen, Entscheidungen ausarbeiten), — sowie Aufgaben im Kundenservice zu verwalten wie Rückerstattungen, Kontenabfragen und Ticket-Verteilung.
Die Einschränkungen, unter denen Aurora arbeitet, spiegeln genau die Probleme wider, mit denen die meisten echten Unternehmen konfrontiert sind:
- Kundendaten dürfen die eigene Infrastruktur der Bank nicht verlassen.
- Jede automatisierte Entscheidung muss auf Anfrage einem Aufsichtsbehördenmitarbeiter erklärbar sein.
Behalten Sie diese fünf Einschränkungen im Hinterkopf, während Sie weiterlesen – jeder der neun Grundpfeiler existiert speziell, um solche Einschränkungen zu bewältigen.
Fünf Leitprinzipien
Bevor wir uns den Grundpfeilern selbst zuwenden, ist es hilfreich, die zugrundeliegende Philosophie zu verstehen:
- Betrachten Sie das Modell als einen von vielen Komponenten und nicht als die Architektur selbst. Modelle werden alle paar Monate ersetzt; Ihre Architektur muss diesem Wandel standhalten.
- Bleiben Sie innerlich probabilistisch in der Denkweise, machen Sie die Grenzen jedoch deterministisch. Das LLM kann frei denken, doch Aktionen müssen über feste Codeblöcke ablaufen.
- Sichern Sie sich daran, dass jede Aktion eine Aufzeichnung erzeugt. Wenn Sie eine Entscheidung nicht nachvollziehen können, können Sie sie später auch nicht verteidigen.
- Isolieren Sie Komponenten nach ihrem Vertrauensniveau und vermitteln Sie bei jedem Zugriffsantrag. Agenten sind fähig – genau deshalb stellen sie ein Risiko dar – kontrollieren Sie dieses Risiko bewusst.
- Bauen Sie so, als würde eine Prüfung stattfinden und als würden Sie mitten in der Nacht angerufen werden. Früh oder spät wird beides eintreten.
Nun gehen wir nacheinander auf jeden Pfeiler ein – was er bedeutet, warum diese spezielle Struktur die richtige ist, ein dazugehöriges Diagramm, ein konkretes Beispiel sowie die Folgen eines Auslassens.
Pfeiler 1 – Logische Architektur: Warum sechs Schichten richtig sind
Die Frage lässt sich einfach formulieren: Welche sind die grundlegenden Bausteine des Systems und welche Schicht übernimmt welche Verantwortung?
Eine agierende Plattform ist in sechs logische Schichten unterteilt.
Warum sechs und nicht drei oder neun?
Das traditionelle Dreischichtmodell – Präsentation, Logik, Daten – übersieht genau die Aspekte, die ein agierendes System auszeichnen: Orchestrierung, Modellauswahl, Tool-Integration sowie Vertrauensgrenzen. Andererseits führt eine Aufteilung in neun getrennte Bereiche dazu, dass Funktionalitäten, die eigentlich zusammenbleiben müssen, getrennt werden.
Sechs erweist sich als die minimale Anzahl an Schichten, bei der jede eine einzige Aufgabe hat, einen einzigen Verantwortlichen sowie einen einzigen Grund für Änderungen. Dies kann man überprüfen, indem man sich fragt: Könnte diese Schicht allein geändert werden, ohne dass jede andere Schicht mitverändert werden muss?
- Experience Layer (L1) ändert sich ständig – neue Benutzeroberflächen, neue Kanäle, neue Anforderungen an die Frontend-Technologie.
- Orchestration (L2) passt sich jedem neuen Anwendungsfall an, den Sie hinzufügen.
- Reasoning (L3) ändert sich jedes Mal, wenn ein leistungsstärkeres Modell verfügbar wird, weshalb es austauschbar sein muss, ohne etwas anderes zu beeinflussen.
- Integration (L4) ändert sich, sobald das Unternehmen ein neues System anschließt.
- Data (L5) ändert sich langsam von selbst, doch die dazugehörigen Governance-Regeln entwickeln sich mit den gesetzlichen Vorgaben weiter.
- Governance (L6) fungiert als durchgängiges Element neben den anderen Schichten statt als unterste Schicht, da Identitätsmanagement, Auditing, Bewertung, Sicherheitsmaßnahmen und Kostendurchblick in alle anderen Schichten reichen müssen, anstatt auf die Basis der Architektur beschränkt zu bleiben.
Ein nützliches mentales Modell ist eine Restaurantküche: Sie ist in verschiedene Arbeitsbereiche unterteilt – Grillen, Anbraten, Backen – sodass jeder Koch sich spezialisieren kann und der Chefkoch einen Bereich ersetzen kann, ohne die gesamte Küche auseinandernehmen zu müssen.
Aurora in der Praxis: Aufgrund des Souveränitätsanforderungs aus Pfeiler 2 muss Aurora Bank letztendlich ein externes LLM durch ein selbst gehostetes ersetzen. Da das Reasoning in seiner eigenen Schicht isoliert ist, handelt es sich dabei lediglich um eine Änderung der Routing-Konfiguration innerhalb von L3 – es werden keine Tool-Integrationen berührt, und keine Prompts müssen neu geschrieben werden.
Falls man diesen Schritt überspringt: Jeder neue Anwendungsfall führt dazu, dass ein überdimensioniertes, verworrenes Datei geändert werden muss. Das Wechseln der Modelle wird unpraktisch. Niemand kann mit Sicherheit sagen, wo die Prüflogik tatsächlich liegt.
Fazit: Schichten dienen dazu, anzuzeigen, wo Änderungen vorgenommen werden dürfen. Ihr guter Entwurf bedeutet den Entwurf der Schnittstellen des Systems und nicht nur seiner Komponenten.
Säule 2 – Physische Architektur: Warum eine souveräne Bereitstellung möglich ist
Die zu beantwortende Frage: Wo läuft das System physisch, und was – wenn überhaupt – darf Ihre eigenen Grenzen überschreiten?
"Souverän" bedeutet in diesem Kontext, dass Modelle, Daten, Embeddings sowie Ausführungsprotokolle vollständig innerhalb der von Ihnen kontrollierten Infrastruktur verbleiben, wobei ein einziger, protokollierter und gefilterter Gateway als einziger Weg in die Außenwelt dient.
Warum gibt es diese Option jetzt, obwohl sie vor einigen Jahren noch unrealistisch war?
- Open-Weight-Modelle haben die Lücke geschlossen. Modelle wie Llama 3.x, Qwen 2.5 und Mistral können nun selbst gehostet werden und liefern dennoch ergebnisorientierte Leistungen für Klassifizierung, Extraktion, Zusammenfassung sowie antwortbasierte Anwendungen auf Basis von RAG.
- Quantisierung macht sie erschwinglich. 4-Bit-Quantisierungstechniken ermöglichen es einer einzelnen 80GB-GPU, ein Modell der 70B-Parameter-Klasse zu betreiben, wobei kleinere Modelle noch weniger Hardware benötigen.
- Die Infrastruktur für Inferenz ist ausgereift. vLLM bietet kontinuierliches Batching sowie hohe Durchsatzraten für die Produktion, Ollama eignet sich hervorragend für Entwicklungsarbeiten, und Kubernetes kann den Laufzeitbetrieb genauso orchestrieren wie jeden anderen Dienst.
Eine wichtige Nuance: Die Priorisierung von eigenständigen Modellen bedeutet nicht, dass externe Modelle vollständig verboten werden. Es bedeutet vielmehr, dass jeder Aufruf, der die Grenzen verlässt, freiwillig erfolgt, auf eine bestimmte Datenklassifizierung beschränkt ist und über ein einziges Gateway geleitet wird – niemals durch eine stillschweigende Standardeinstellung ausgelöst. Genau deshalb wird das Ausgangsgateway als eine einzige Tür dargestellt: Eine einzige, gut geschützte Tür ist besser als zwanzig unverschlossene Fenster.
Aurora in der Praxis: Alles Sensible – Kundendokumente, Ausführungsprotokolle der Agenten sowie PII – bleibt innerhalb der Systemgrenzen. Der einzige zulässige Datenverkehr sind anonymisierte Abfragen zu Marktpreisen, und selbst diese müssen durch das Gateway gehen, welches jedes übertragenen Bytes protokolliert.
Falls Sie diesen Schritt überspringen: Eine Standardeinstellung in einigen SaaS-Embedding-Tools übermittelt heimlich Kundendaten an Drittanbieter. Ihre Observabilitätsplattform speichert schließlich datenschutzrelevante Informationen auf Servern außerhalb des Landes. Die Sicherheitsprüfung scheitert – und damit auch das Projekt.
Fazit: Die Festlegung der Systemgrenzen ist eine bewusste Entscheidung, die Sie treffen müssen. Wenn Sie dies nicht explizit tun, wird die Standardkonfiguration eines Anbieters diese Entscheidung für Sie treffen.
Pillar 3 – Das C4-Modell: Dokumentation richtig gestalten
Die Frage: Wie dokumentiert man ein System, damit jede Zielgruppe genau den gewünschten Detailgrad erhält?
Das von Simon Brown entwickelte C4-Modell bietet vier Zoomstufen – man kann sich das wie das Panieren und Vergrößern auf einer Karte vorstellen.
Warum passt C4 so gut zu agierenden Systemen?
- Agierende Systeme sind von Natur aus verwirrend. Die Frage „Wo befindet sich der Agent eigentlich?“ lässt sich nicht eindeutig beantworten. C4 zwingt dazu, präzise zu sein: Ein Agent ist nicht einfach ein einzelner Kasten in einem Diagramm – er besteht aus einer Reihe von Containern (dem Laufzeitumfeld, einem Gateway, verschiedenen Speichern), die miteinander Nachrichten austauschen. C4 bringt diese Austausche ans Licht, anstatt sie zu verbergen.
Aurora in der Praxis: Wenn eine Aufsichtsbehörde genau wissen will, welche Komponenten auf Kundendaten zugreifen dürfen, kann Aurora bereits am Nachmittag eine Antwort liefern. Das Team zeigt das Container-Diagramm mit den in Pilar 4 eingeführten Zone-Bezeichnungen sowie das Komponentendiagramm für den Agenten-Runtime – beides wird direkt aus dem aktuellen Repository-Zustand generiert und zusammen mit dem Code, der es erzeugt hat, versioniert.
Sonst ohne diese Disziplin: Neue Mitarbeiter müssen die Architektur aus dem Quellcode heraus rekonstruieren. Den Prüfern wird ein 60-seitiges Präsentationsmaterial überreicht, das bereits 14 Monate veraltet ist. Jeder architektonische Meinungsverschiedenheit entwickelt sich zu einer Debatte über Rechtecke an einer Tafel.
Fazit: Die Dokumentation dient als Schnittstelle zwischen Ihrer Architektur und allen Menschen, die ihr vertrauen müssen. C4 verwandelt diese Schnittstelle in etwas, das versioniert und überprüfbar ist – anstatt in ein statisches Dokument.
Säule 4 – Zero-Trust-Netzwerke: Warum ausgerechnet fünf Zonen?
Die Frage: Wenn etwas kompromittiert wird – und das wird früher oder später passieren – wie begrenzt man den Schaden?
Zero Trust bedeutet, überhaupt kein implizites Vertrauen irgendwo zuzugestehen: Jeder Aufruf wird über mTLS sowie die Identität der Arbeitslast authentifiziert, durch eine Richtlinienprüfung autorisiert und verschlüsselt – selbst für Verkehr, der Ihr eigenes Netzwerk nie verlässt. Für eine agierende Plattform führt die richtige Segmentierung zu fünf Zonen:
Warum genau fünf?
Denn jede Grenze muss einen wirklich unterschiedlichen Vertrauensgrad voneinander trennen – und die Agenten führen einen Vertrauensgrad ein, den traditionelle Architekturen einfach nie berücksichtigen mussten:
- Z1, die Peripherie – hier erreicht der unzuverlässige Verkehr zuerst an. Sie steht ständig unter Angriff, weshalb man davon ausgeht, dass sie bereits kompromittiert ist.
- Z2, die Anwendungs Schicht – sie bedient Endbenutzer direkt. Halbzurverlässig.
Weniger als fünf Zonen würden die Grenzen zwischen wirklich unterschiedlichen Vertrauensniveaus aufheben. Mehr als fünf würden lediglich zusätzliche Barrieren schaffen, ohne neue Vertrauensgrenzen einzuführen. Fünf ist die genau richtige Zahl.
Aurora in der Praxis: Ein Angreifer injiziert über eine kompromittierte Webseite einen Befehl, um den Forschungs-Sub-Agenten dazu zu bringen, Gehaltsdaten der Personalabteilung abzurufen. Die Zonenrichtlinie blockiert den Weg von Z3 zur Personalabteilung vollständig, da der Zuständigkeitsbereich dieses Bereichs einfach keine HR-Systeme umfasst. Der Hub protokolliert den Versuch, und der Angreifer erhält lediglich öffentliche Webdaten. Der Agent wurde manipuliert; die Daten der Bank blieben unberührt.
Ohne diese Segmentierung: Ein einziger durchgesickertes Connector-API-Schlüssel würde einem Angreifer – oder einem bösartigen Agenten – einen unbehinderten Zugang zu der gesamten Datenschicht ermöglichen.
Fazit: Agenten erhöhen das Risiko von seitlichen Bewegungen innerhalb eines Netzwerks erheblich. Eine ordnungsgemäße Zonierung verwandelt einen kompromittierten Agenten von einem Schlagzeilenthema wegen eines Sicherheitsbruchs in ein einzelnes protokolliertes Ereignis.
Pillar 5 – Hub-and-Spoke-Integration: Das richtige Muster für Agenten
Die Frage: Wie können Agenten mit mehr als 20 Unternehmenssystemen verbunden werden, ohne dass die Integrationsschicht unübersichtlich wird?
Die Antwort ist ein einziger Integrationshub, der von zertifizierten Spokes umgeben ist.
Warum ist das besonders für Agenten wichtig? Schauen Sie sich die Rechnung an. Wenn alles direkt verbunden wird, ergeben sich 10 Systeme mal 8 Agenten – also 80 separate Integrationen. Wenn hingegen alles über einen Hub geleitet wird, benötigen Sie nur 10 Spokes plus 8 Verbindungen zu den Agenten – insgesamt 18 Links.
Jeder direkte Punkt-zu-Punkt-Link ist ein Ort, an dem Zugangsdaten fest codiert werden, Protokollierung vernachlässigt wird und das Verhalten leise vom Rest des Systems abweicht. Multipliziert man das mit 80 Verbindungen, entstehen 80 Stellen, in die ein Prüfer nicht vollständig hineinschauen kann. Agenten verschlimmern die Situation, anstatt sie zu verbessern, denn jeder neue Agent möchte in der Regel Zugang zu allem haben.
Durch Zentralisierung über einen Hub gewinnen Sie die Kontrolle über vier äußerst wichtige Aspekte:
1. Authentifizierungsbrokerung – Der Hub speichert die tatsächlichen Salesforce-Anmeldedaten, während die Agenten nur einen eingeschränkten, widerrufbaren Hub-Token besitzen. Wird ein Token widerrufen, ist nur ein Agent betroffen, nichts weiter. 2. Schematische Übersetzung – Das Wort „Kunde“ kann je nachdem, ob es um SAP, das CRM oder den Support-Desk geht, drei verschiedene Bedeutungen haben. Der Hub klärt dies einmalig auf, anstatt acht separate Agenten-Codebasen dazu zwingen zu müssen. 3. Zuverlässigkeit – Durch Rate-Limiting und Circuit Breaker im Hub wird verhindert, dass ein instabiler Agent eine Kettenreaktion von Neuanläufen bei allen anderen Agenten auslöst. 4. Einheitlicher Prüfpunkt – Ein einheitliches Protokollformat sowie ein einziger Ort, um die Frage zu beantworten: „Welcher Agent hat welches Datensatz bearbeitet, wann und im Rahmen welcher Befugnisse?“
Ein weiterer Vorteil ist, dass MCP-basierte Tool-Server es ermöglichen, die „Spokes“ zu standardisierten, einsetzbaren Komponenten zu machen anstelle von einmaligen Integrationsskripten.
So funktioniert es bei Aurora: Die Inbetriebnahme von ServiceNow als System Nr. 21 bedeutet den Aufbau eines solchen „Spokes“. Ab dem nächsten Tag kann jeder Agent es unter dem gleichen Authentifizierungsmodell, denselben Rate-Limits sowie derselben Audit-Trail wie die anderen 20 Systeme nutzen. Eine punktuelle Integration hätte acht separate Integrationsvorhaben sowie acht getrennte Übertragungen von Zugangsdaten erfordert.
Sonst: Jeder Agent besitzt schließlich seine eigene Kopie des Salesforce-Passworts. Es ist nicht möglich nachzuvollziehen, welcher Agent ein bestimmtes Kundenkonto geändert hat. Der Einbau eines neuen Tools erfordert ein ganzes Quartal an Entwicklungsarbeit.
Fazit: Der Hub erfüllt für Tools die gleiche Funktion wie der Supervisor für Agenten – ein einziger, voll ausgestatteter Eingangspunkt.
Säule 6 – Datenarchitektur: Warum Sie unterschiedliche Ebenen benötigen
Die Frage: Wie sollten Daten strukturiert werden, damit Antworten reproduziert werden können, Einträge auf Wunsch gelöscht werden und der gesamte Prozess kontrollierbar bleibt?
Die Antwort sind fünf Ebenen, die als Prozessablauf angeordnet sind:
T0 – Quellsysteme. Dies sind die Datenspeichersysteme. Sie gehören Ihnen nicht, und sie ändern sich nach ihrem eigenen Zeitplan, ohne Vorankündigung. T1 – Rohdatenzone. Einmalige Kopien aller Daten in dem Zustand, in dem sie eingeholt werden. Dies ist der Ausgangspunkt für jede Wiederherstellung; sie werden niemals geändert oder gelöscht, es sei denn, es gilt eine ausdrückliche Aufbewahrungsrichtlinie. T2 – Aufbereitete Daten. Bereinigte, deduplizierte Daten, in Blöcke unterteilt, mit PII-Taggen versehen und mit Herkunftsidentifikatoren angereichert. T3 – Bereitstellungsstufe. Vektorindizes, Wissensgraphen, semantische Caches – alles wiederherstellbare Artefakte, die bei Bedarf aus T2 erneut generiert werden können. T4 – Von Agenten erzeugte Daten. Gesprächsprotokolle, Erinnerungen, Spuren sowie erzeugte Ausgaben. Diese Ebene ist nur für Nachträge geeignet, wird selten im Voraus geplant und enthält oft das sensibelste Material im gesamten System.
Warum ausgerechnet fünf Ebenen?
Falls dies der bekannten Medaillons-Architektur – Bronze, Silber, Gold – ähnelt, ist das beabsichtigt; die Ebenen T1 bis T3 folgen genau diesem etablierten Muster. Was der agierende Kontext hinzufügt, sind die beiden Ebenen an den Enden: eine klare Grenze am Eingang (T0, da die Aufnahmeverträge genau definiert werden müssen) sowie eine Ebene für die Ausgabe der Agenten (T4, da auch das von Agenten erzeugte Material als Daten gilt und eigene Anforderungen hinsichtlich Aufbewahrung, Privatsphäre und Prüfung mit sich bringt).
Durch die Strukturierung der Daten in Ebenen werden zwei sonst schwierige Probleme zu routinemäßigen Aufgaben:
1. Reproduzierbarkeit. Anstatt dass „Wir haben die Chunking-Strategie geändert und jetzt sind die Antworten anders“ zu einer Krise wird, bauen Sie einfach über Nacht T3 aus T2 neu auf. Wenn ein Modell beschädigt wird, regenerieren Sie T2 aus T1. Es ist nie notwendig, die ursprünglichen Quellsysteme erneut abzusuchen.
2. Löschung. Wenn ein Kunde sein Recht auf Löschung gemäß GDPR in Anspruch nimmt, bedeutet eine klare Abfolge, dass der Löschantrag über die Identifikatoren deterministisch durch T1, T2, T3 und T4 weitergeleitet wird – ohne manuelles Nachforschen.
Die zugrunde liegende Regel für all das: Ein Vektorindex ist ein Cache, niemals eine Quelle der Wahrheit.
Wie sich dies bei Aurora zeigt: Die Qualitätskontrolle stellte fest, dass die Aufteilungslogik heimlich Zeilen aus Tabellen entfernte. Aurora integriert über Nacht zwei Millionen Dokumente aus T2 mithilfe des korrigierten Aufteilungswerkzeugs wieder ein, ohne dass ein erneutes Durchscannen eines Quellsystems notwendig ist und ohne Sorgen wegen fehlender Historie. Ein Monat später kann das Team nachvollziehen und vergleichen, wie eine bestimmte Frage vor und nach der Korrektur beantwortet worden wäre.
Sonst ohne Hierarchisierung: Der Vektor-Speicher wird zur einzigen vorhandenen Kopie der Daten. Löschungen im Quellsystem werden niemals weitergeleitet. Eine Frage wie „Was hat der Assistent diesem Kunden im März gesagt?“ kann einfach nicht beantwortet werden.
Fazit: Entwerfen Sie Ihre Datenarchitektur unter Berücksichtigung des Neuaufbaus, den Sie letztendlich benötigen werden, sowie der Löschungen, die Sie gesetzlich verpflichtet sind durchzuführen.
Säule 7 – Aggressives Design: Warum ein Supervisor mit Unter-Agenten einem Monolithen überlegen ist
Die Frage hier lautet: Wie sollten Sie die „Gesellschaft“ der Agenten strukturieren, aus denen Ihr System besteht?
Das in der Praxis bewährte Muster ist Orchestrator-Arbeiter: Ein einziger Supervisor verfolgt das übergeordnete Ziel, während eine Gruppe von Unter-Agenten jeweils eine spezifische, begrenzte Aufgabe übernimmt.
Warum ist die Aufteilung der Verantwortlichkeiten besser als das Erstellen eines riesigen Agenten mit fünfzig angehängten Tools?
1. Der Kontext verflüchtigt sich schnell. Wenn ein Agent mit fünfzig Werkzeugen und einem offenen Ziel umgehen muss, sinkt seine Leistung messbar – falsche Werkzeugauswahl, vergessene Einschränkungen, Verlust des Überblicks über die Aufgabe. Ein Spezialist mit fünf Werkzeugen und einem eng definierten Aufgabenbereich ist weitaus zuverlässiger. 2. Man kann es tatsächlich testen. Es gibt keine sinnvolle Methode, einen umfangreichen Mega-Prompt unitgetestet zu prüfen. Doch man kann für jeden Unteragenten eine eigene Bewertungssuite erstellen – beispielsweise 200 Testfälle für einen Forscher und 50 für einen Schreiber. Dadurch wird das Regressionstesten der Agenten zu etwas Realem und wiederholbaren. 3. Es gibt einen einzigen Kontrollpunkt. Der Supervisor ist der Ort, an dem man Budgets durchsetzt (ein Limit von 12 Schritten oder 0,40 Euro pro Aufgabe), Wiederholversuche verwalten, eine Eskalation an Menschen auslösen sowie jede Übergabe durch Sicherheitsmaßnahmen begleiten kann. 4. Die Arbeit läuft parallel ab und die Komponenten sind austauschbar.
Sub-Agenten können gleichzeitig ausgeführt werden, und jeder von ihnen kann durch ein anderes ersetzt werden – sei es ein leistungsstärkerer LLM, ein günstigererer oder ein vollständig deterministischer Abrufmechanismus – ohne die Reste des Systems zu stören.
Es ist wichtig zu betonen, dass „Sub-Agent“ nicht gleichbedeutend mit „LLM bis ins kleinste Detail“ ist. In Auroras Konfiguration enthält der Sub-Agent für den Kostenschätzer überhaupt keinen LLM – es handelt sich dabei um deterministischen Code, der mit einer agentenähnlichen Benutzeroberfläche verpackt ist. Dies weist bereits auf Pillar 8 voraus.
Aurora in der Praxis: Der Prozess zur Kreditunterstützung ist in eine Rolle des Forschers (der Policy-Dokumente abruft), einer Prüferrolle (die die Dokumente überprüft), einer Rechenrolle (die mithilfe einfacher Code die Zahlungsfähigkeit berechnet) sowie einer Schreibrolle (die den an den Kunden gerichteten Brief entwirft) unterteilt. Jede dieser Rollen wird separat bewertet, versioniert und verwaltet. Sinkt der Tonfall der Schreibrolle nach einem Wechsel des Modells, wird dieser spezielle Experte korrigiert, anstatt ein monolithisches System zu bearbeiten.
Falls Sie diesen Ansatz überspringen: Sie landen schließlich mit einem siebzig-Tools umfassenden Mega-Agenten, der aus Gründen, die niemand genau benennen kann, gelegentlich zweimal auf die Rückerstattungs-API zugreift – und alle haben zu große Angst, daran herumzufummeln.
Fazit: Die Aufteilung der Arbeit dient nicht nur der Effizienz. In agilen Systemen ist sie die eigentliche Quelle für Zuverlässigkeit.
Pillar 8 – Determinismus gegenüber Reasoning: Die wichtigste Entscheidung
Die Frage: Genau an welcher Stelle im System überlassen Sie die Entscheidungsfindung durch probabilistische KI und wo wird das Verhalten weiterhin durch Code und Richtlinien festgelegt?
Dies ist der zentrale Pfeiler – alle anderen existieren, um die hier gegebene Antwort zu unterstützen oder durchzusetzen.
Das Leitprinzip ist einfach:
LLMs schlagen vor. Deterministische Systeme entscheiden.
Nutzen Sie die LLMs für das, wofür sie hervorragend geeignet sind: Klassifizierung, Extraktion, Erstellung von Entwürfen, Planung. Nutzen Sie deterministischen Code für das, was Vorschriften und solide Ingenieurspraxis erfordern: Validierung, Übertragung von Geldern, Änderung des Zustands, Durchsetzung der Konformität.
In der Praxis bedeutet das, Ihre Workflows als Zustandsmaschinen zu betrachten, bei denen die LLMs nur an spezifischen, aufgelisteten Entscheidungspunkten ein Votum abgeben und reiner Code sich um alles Weitere kümmert.
Warum gilt dies als die wichtigste Gestaltungsoption überhaupt? Weil es alles andere, was danach folgt, prägt:
1. Zuverlässigkeit – die mit Geld zu tun habenden Abläufe dürfen keinerlei unerwartetes Verhalten aufweisen.
2. Prüfbarkeit – da die Entscheidungspunkte aufzählbar sind, können Sie jeden einzelnen Punkt aufzeigen, an dem ein Urteil gefällt wurde.
3. Kosteneinsparung – Sie vermeiden es, Token für Aufgaben auszugeben, die bereits durch eine einfache if-Anweisung kostenlos abgewickelt werden können.
4. Architektonische Kohärenz – der Supervisor aus Pfeiler 7 ist der Ort, an dem Sie diese Grenze einfügen, der Hub aus Pfeiler 5 setzt sie auf der Tool-Ebene durch, die Zonen aus Pfeiler 4 beinhalten alle Fehler, und der Evidence Store aus Pfeiler 9 beweist im Nachhinein, was tatsächlich geschehen ist.
Aurora in der Praxis – der Rückerstattungsablauf:
- LLM innerhalb der Reasoning-Zone: Es liest die E-Mail des Kunden und extrahiert strukturierte Felder –
betrag: €145,Ursache: beschädigte Waren,Stimmung: frustriert. Dieser Schritt ist probabilistisch, was akzeptabel ist, da er lediglich ein Formular ausfüllt. - Deterministischer Policy-Engine: Beträge bis €200 werden automatisch genehmigt; Beträge zwischen €200 und €1.000 lösen regelbasierte Überprüfungen aus; alles über €1.000 erfordert eine menschliche Freigabe. Das LLM hat niemals die Befugnis, Geld zu überweisen – es kann nur einen Betrag vorschlagen, und allein der Code entscheidet darüber, was damit geschieht.
Sowohl die extremen Ansätze als auch der Mittelweg sind gefährlich, weshalb man den Mittelweg einhalten muss:
Das Eingreifen eines LLM bei allen Entscheidungen („Lassen Sie einfach den Agenten damit umgehen“) führt dazu, dass per E-Mail eine Genehmigung für einen Rückerstattungsbetrag von 50.000 Euro erteilt wird, die durch einen Prompt eingefügt wurde. Wenn Regeln alles bestimmen, bedeutet das ein System, das nicht einmal eine gewöhnliche E-Mail korrekt verarbeiten kann – im Grunde ein Rückfall in das Jahr 1995.
Fazit: Vollständige Autonomie durch LLMs ist nur ein Demonstrationstrick; vollkommene starre Regelbasierte Systeme gehören der Vergangenheit an. Produktivsysteme erfordern eine bewusst erstellte, dokumentierte Übersicht darüber, wo genau jede Regel anwendbar ist – und die richtige Erstellung dieser Übersicht ist die entscheidendste Wahl bei der Gestaltung des gesamten Systems.
Pillar 9 – Belegverknüpfung/Zitierung: Warum dies prüfbar ist
Die Frage: Wie kann man sicherstellen, dass jede Ausgabe auch Monate oder sogar Jahre später noch für einen Prüfer, der aktiv nach Schwachstellen sucht, nachvollziehbar ist?
Jeder faktische Behauptung muss mit dem zugrundeliegenden Beweismittel verknüpft werden, und der gesamte Entscheidungsverlauf muss nach der Aufzeichnung unverändert bleiben:
Warum hält das einer Prüfung stand? Weil es Ihnen gleichzeitig drei Garantien bietet:
1. Halluzinationssperre. Ohne Quellenangabe gibt es keine Veröffentlichung. Wenn der Antwortgenerierungsprozess keine gültige Quelle zuordnen kann, wird die Ausgabe markiert oder unterdrückt. Dadurch wird „Vertrauen einfach auf das Modell“ zu einer durchsetzbaren, mechanischen Regel.
2. Vollständige Wiedergabemöglichkeit. Wenn jemand fragt: „Warum hat das System am 3. März so reagiert?“, können Sie die genaue Abfolge rekonstruieren – die ursprüngliche Frage, die abgerufenen Passagen, die Version der Anfrage, die Version des Modells, die erzeugte Antwort sowie deren Quellenangaben. Anstelle von „Wir glauben“ liefern Sie die tatsächlichen Aufzeichnungen.
3. Klarheit bezüglich der Ursache. Wenn eine Ausgabe falsch ist, können Sie sofort den Fehlertyp feststellen: Handelte es sich um einen Abruffehler (falsche Beweise wurden herangezogen) oder um einen Schlussfolgerungsfehler (richtige Beweise wurden herangezogen, aber falsch interpretiert)? Dafür sind völlig unterschiedliche Lösungen erforderlich, und ohne bindende Beweise lässt sich der Unterschied nicht erkennen.
Aurora in der Praxis: Der Assistent beantwortet eine Frage zu den Strafkonditionen, indem er auf credit_policy_v12.pdf, Seite 14, sha256:9f2c… verweist. Später, wenn Version 13 der Richtlinie veröffentlicht wird, spiegelt diese frühere Antwort weiterhin genau das wider, was zum Zeitpunkt der Erstellung zutraf, da die zitierte Quelle durch einen Hash fixiert und nicht dynamisch neu abgerufen wird. Der Compliance-Prüfer kann sie daher genehmigen, da die gesamte Kette nachvollziehbar, manipulationsfest und korrekt mit Zeitstempeln versehen ist.
Vermeiden Sie das, und: Ihre einzige Verteidigung bei einem Vorfall oder einer Prüfung wird „das Modell hat es gesagt“ sein. Sie verlieren die Fähigkeit, ein Problem der Datenqualität von einem Fehler in der Argumentation zu unterscheiden. Die Aufsichtsbehörden werden das System als Schwarzkiste einstufen – und Schwarzkisten werden stillgelegt.
Fazit: Wenn das System keine Quelle angeben kann, wird es nicht veröffentlicht.
Wie die Neun Säulen miteinander verbunden sind
Diese neun Elemente bilden keine Liste von getrennten Aspekten – sie ergeben eine zusammenhängende Struktur mit einem Kern:
Nehmen Sie eine einzige Säule weg, und der Rest beginnt zu bröckeln. Entfernen Sie die zentrale Struktur (5), kann der Determinismus (8) nicht mehr auf der Ebene der Tool-Aufrufe durchgesetzt werden. Entfernen Sie die Datentierung (6), hat die Beweisbindung (9) nichts Verlässliches mehr, worauf sie sich beziehen kann. Entfernen Sie die C4-Dokumentation (3), verlieren Sie sogar die Fähigkeit, die verbleibende Architektur bei einer Prüfung zu erklären. Sie funktionieren nur als Ganzes – entweder halten alle neun stand, oder das Ganze bricht zusammen.
Was kommt in dieser Serie
Jeder folgende Beitrag wird eine umfassende Analyse sein: das Leitprinzip, ein dazugehöriges Diagramm, ein konkretes Beispiel aus dem Aurora Bank-Szenario, spezifische Technologieentscheidungen, häufige Anti-Muster, die vermieden werden sollten, sowie eine praktische Checkliste für den Aufbau.
Letzter Gedanke
Bis 2026 ist der Zugang zu einem leistungsstarken Modell nicht mehr ein Wettbewerbsvorteil – eine API-Schlüssel kann jeder erhalten.
Die Architektur ist es, die tatsächlich die Systeme unterscheidet, die langfristig bestehen bleiben. Die Teams, denen es gelingt, agierende Systeme in regulierte, hochriskante Umgebungen zu bringen, sind jene, die die wahre Natur der Aufgabe verstanden haben: das Erstellen eines deterministischen Unternehmenssystems, in dem zufällig ein probabilistischer Reasoning-Engine integriert ist.
Nine Säulen. Neun Entscheidungen. Alle müssen richtig getroffen werden – gemeinsam.
Nächste Folge: Teil 1 – Logische Architektur, in der der sechsschichtige Stack Schicht für Schicht aufgebaut wird, der Vertrag zwischen jedem Paar von Schichten explizit definiert wird und die Anti-Muster, die Agenten-Codebasen in unverwaltbare Chaoslandschaften verwandeln, detailliert untersucht werden.