Sechs KI-Agenten-Architekturen – und die Kontrollen, die sie jeweils benötigen

Am 20. Juli veröffentlichte CIO.com den Beitrag von Bernard Aceituno: Die 6 Arten von KI-Agenten-Architekturen, der drei Jahre Erfahrung aus hunderten Unternehmenseinsätzen in sechs Archetypen zusammenfasst, die ein CIO auf Anhieb erkennen sollte. Die Stärke dieser Taxonomie liegt darin, dass sie auf eine Hierarchie verzichtet: Keiner der sechs Archetypen steht über den anderen; die Kunst besteht darin, den Archetyp passgenau auf das jeweilige Problem abzustimmen. Der Artikel schließt mit einem Satz, der der Plattform-Welt eine klare Aufgabe stellt: „Einführung, Governance, Vertrauen – all das wird nur einfacher, wenn die Architektur die richtige Passform hat“ (das einzige Zitat aus der Quelle in diesem Beitrag). Jeder der sechs Archetypen passt auf unterschiedliche Weise – und die sechs teilen sich nicht dieselben Kontrollpunkte. Dieser Artikel ordnet den Modell- und Tool-Traffic hinter jedem Archetyp – nicht die vollständige Anwendungslaufzeit – den dokumentierten Funktionen in TrueFoundry AI Gateway, MCP Gateway und Agent Harness zu. Jeder Typ erhält einen eigenen Abschnitt: Was er ist und wo die dokumentierten Kontrollen ansetzen, inklusive der Konfigurationsvoraussetzungen. Eine Zusammenfassung in Tabellenform folgt auf die sechs Archetypen, und eine vierte diagnostische Frage rundet die Argumentation ab.

Typ 1: Der Konversations-Assistent

Was er ist

Der Chat-basierte Partner, den man öffnet, wenn man laut nachdenken möchte – der Archetyp, dem Unternehmen meist zuerst begegnen und in den sich die Nutzer laut dem Artikel verlieben, wenn er richtig umgesetzt ist: ständig aktualisierte Informationen, persistentes Gedächtnis auf Benutzerebene, Tools, die im Namen des Nutzers handeln, und Quellenangaben für jede faktische Behauptung. In Deloittes State of AI in the Enterprise -Umfrage berichten 38 % der Unternehmen von verbesserten Kundenbeziehungen als bereits erzieltem Nutzen ihrer KI-Initiativen. Die Beispiele im Artikel zeigen die Bandbreite: eine globale Anwaltskanzlei, deren Mitarbeiter ihre Recherche mit einer belegten Antwort auf Basis der gesammelten Präzedenzfälle der Kanzlei beginnen, statt eine Stunde im Dokumentenmanagement zu verbringen, und ein Vermögensverwalter, dessen Kunden auch sonntags fundierte Antworten zu ihrem Portfolio erhalten. Wenn das Unternehmen ein Gebäude ist, ist dies der Empfang: Er schläft nie, nennt seine Quellen und jeder in der Lobby spricht mit ihm – was genau der operative Zweck ist.

Wo TrueFoundry ansetzt

Das größte Risiko ist die Konversationsoberfläche selbst: Menschen fügen ein, was sie einfügen, Modelle antworten, was sie antworten, und das Volumen skaliert mit der Anzahl der Nutzer. Die verbindlichen Instrumente befinden sich an den beiden Enden des Anfragepfads. llm_input guardrails führen PII- und Geheimniserkennung im Mutate-Modus aus – die eingefügten Anmeldedaten werden geschwärzt und die Anfrage wird fortgesetzt, sodass der Schutz die Nutzer nicht dazu verleitet, den sanktionierten Pfad zu umgehen (das Argument unserer Gateway-vs-Anwendung PII-Analyse; beachten Sie, dass die von TrueFoundry verwaltete PII/PHI-Funktion für das von TrueFoundry gehostete Gateway dokumentiert ist – selbst gehostete und hybride Bereitstellungen konfigurieren eine Bring-Your-Own-Key- oder externe Anbieter-Alternative) – und LLM-Output-Prüfungen können die vollständige Antwort überprüfen – bei Nicht-Streaming-Pfaden. Die dokumentierte Grenze ist für diesen Archetyp besonders wichtig: Output-Guardrails benötigen die vollständige Antwort und werden daher übersprungen, wenn stream: true gesetzt ist, während Input-Guardrails unabhängig vom Streaming-Modus ausgeführt werden (Guardrail-Dokumentation). Konversationsassistenten gehören zu den Workloads, bei denen Streaming am wahrscheinlichsten ist. Daher benötigt ein Streaming-Assistent eine bewusst gewählte Strategie für die Output-Sicherheit: einen Nicht-Streaming-Pfad für sensible Anfragen; einen Client, der die gesamte gestreamte Antwort puffert, validiert und erst dann anzeigt – wobei in Kauf genommen wird, dass die tokenweise Darstellung entfällt; oder die Akzeptanz von reinen Input-Guardrails als Kompromiss, bei dem eine Validierung nach dem Stream als nachträgliche Erkennung verstanden wird. Das Ausführungsmodell ist ansonsten auf das Latenzbudget dieses Archetyps ausgelegt: Die Input-Validierung läuft parallel zum Modellaufruf. Wenn die Validierung fehlschlägt, während das Modell noch läuft, bricht das Gateway die laufende Anfrage ab, sodass Sie nicht für eine Antwort bezahlen, die Sie ohnehin verworfen hätten (siehe dieselbe Dokumentation). Zu den Hooks: teamweite Budgets zur Kontrolle der Lizenzkosten und semantisches Caching – der Datenverkehr von Assistenten enthält oft wiederholte oder semantisch ähnliche Fragen. Wo es die Anforderungen an Aktualität und Antwortvarianz erlauben, ist Caching daher eher ein Instrument zur Kostenoptimierung als zur Latenzverbesserung.

Typ 2: Der getriggerte Workflow

Was es ist

Das Muster, das im Hintergrund abläuft: Eine E-Mail geht ein, ein Ticket wird erstellt, eine Datei landet in einem Ordner, und der Agent führt einen Prozess aus, der logisches Denken mit deterministischen Schritten verbindet. Es ist keine Benutzerakzeptanz erforderlich, da kein Benutzer den Prozess sieht – der Versicherer wacht auf und findet einen Underwriting-Posteingang vor, der bereits klassifiziert ist und aus dem Risikofelder extrahiert wurden. Die Private-Equity-Firma findet jedes eingehende CIM gesichtet, als Memo entworfen und im Deal-Tracking erfasst, bevor überhaupt jemand die Datei öffnet. Es ist die modernisierte Poststelle des Unternehmens: Niemand besucht sie, jeder ist von ihr abhängig, und ihr Vorteil liegt darin, dass sie sich nahtlos in die Audit- und Change-Control-Prozesse einfügt, die die IT seit Jahrzehnten betreibt.

Wo TrueFoundry ansetzt

Der ruhige Ruf täuscht über ein anspruchsvolles Bedrohungsmodell hinweg: Dieser Archetyp arbeitet unbeaufsichtigt mit nicht vertrauenswürdigen Eingaben. Jede eingehende E-Mail, jeder Anhang und jede hochgeladene Datei ist eine potenzielle Prompt-Injection – Anweisungen, die sich genau in dem Inhalt verbergen, den der Workflow verarbeiten soll. Diese Angriffsart wird in unserem Leitfaden zur Gateway-Injection-Abwehr detailliert beschrieben. Verbindliche Instrumente: eingangsseitige Schutzmechanismen, die den Trigger-Payload prüfen, bevor das Modell ihn liest – entweder durch die integrierte, verwaltete Prompt-Injection im TrueFoundry-gehosteten Gateway oder durch eine dokumentierte Alternative für selbst gehostete und hybride Bereitstellungen –, Tool-Beschränkungen zur Minimierung der Schreibfläche des Workflows (MCP Gateway-Dokumentation) sowie Ratenbegrenzungen , damit aus einer E-Mail-Bombe keine tausend autonomen Ausführungen werden. Die Beobachtung zur Revisionssicherheit gilt auch hier, wobei die Mechanismen präzise definiert sind: Jede über das Gateway geleitete Anfrage protokolliert Trace-Metadaten – Kosten, Token-Verbrauch, Latenz und Anfrage-Metadaten –, unabhängig von den Logging-Einstellungen. Die Logging-Konfiguration steuert separat, ob Anfrage- und Antwort- inhalte gespeichert werden und welche sensiblen Werte in der gespeicherten Kopie gegebenenfalls geschwärzt werden. Teams sollten sowohl festlegen, welche Audit-Nachweise sie benötigen, als auch, welche Inhalte sie speichern dürfen.

Typ 3: Der autonome Agent – mit Sub-Agenten

Was es ist

Bei einer Aufgabe plant es seine Schritte selbst und ruft seine eigenen Sub-Agenten auf. Die Einsatzgebiete sind klar definiert – rechercheintensive Aufgaben aus mehreren Quellen, komplexe systemübergreifende Abfragen, tiefgehende Analysen: Prozesse, bei denen der Weg nicht im Voraus festgelegt ist, die Werkzeuge jedoch schon. Das Beispiel aus der Unternehmensberatung definiert den Umfang von Projekten in der Frühphase, indem es selbst entscheidet, welche Sub-Agenten es für proprietäre Datenbanken, Projektarchive, lizenzierte Marktdaten und öffentliche Unterlagen hinzuzieht, und erstellt dann ein strukturiertes Briefing inklusive Belegen und Begründungen. Das Beispiel aus dem Technologiebereich untersucht Produktionsvorfälle, indem es eine Hypothese aufstellt und diese anhand von Monitoring, Protokollen und Bereitstellungssystemen verfolgt, bis eine fundierte Zusammenfassung der Grundursache für einen Ingenieur vorliegt. Die treffende Analogie ist die eines Detektivs, nicht eines Kuriers: Sie geben den Fall und die Befugnisse vor, niemals den Weg.

Wo TrueFoundry seinen Platz hat

„Der Weg wird entdeckt“ ist eine Aussage über Kosten und Wirkungsbereich: Der Pfad ist nicht statisch durch eine Workflow-Definition begrenzt, daher sind Token-Anzahl und Werkzeugsequenzen weniger vorhersehbar – es sei denn, Kontrollmechanismen machen sie vorhersehbar. Verbindliche Instrumente: Budgets und Ratenbegrenzungen als harte Grenzen des Mandats; pro Sub-Agent Werkzeug-Scoping über das MCP-Register, wobei Cedar- und OPA-Richtlinien für eine fein abgestimmte „Default-Deny“-Kontrolle darüber sorgen, auf welche Werkzeuge jeder Sub-Agent zugreifen darf (Dokumentation zu Guardrails); sowie schrittweise Traces im Agent Harness – so wird aus einem entdeckten Pfad ein überprüfbarer. Eine Präzisierung, die wichtig ist: Es handelt sich um Ausführungs-Traces – Modellaufrufe, Interaktionen der Sub-Agenten, Werkzeugaufrufe, Zeitmessungen, Kosten und Ergebnisse – ein operativer Audit-Trail beobachtbarer Aktionen, kein Zugriff auf den verborgenen Gedankengang eines Modells. Ein dokumentiertes Detail ist hier von enormer Bedeutung: Guardrails bewerten jeden Werkzeugaufruf separat – ein Agent, der fünf Werkzeuge aufruft, durchläuft fünf unabhängige Prüfungen, sodass Autonomie niemals die Kontrolle übersteigt.

Typ 4: Das Multi-Agenten-Team

Was es ist

Mehrere spezialisierte Agenten, jeder mit eigener Rolle und eigenem Toolset, die über ein gemeinsames Protokoll koordinieren – laut dem Artikel der Bereich, aus dem die nächste Welle von Qualitätssteigerungen in Unternehmen kommen wird. Der Bericht State of AI Agents von Databricks misst ein Wachstum der Nutzung von Multi-Agenten-Systemen um 327 % in weniger als vier Monaten – basierend auf Plattform-Telemetriedaten von über 20.000 Unternehmen auf der Data Intelligence Platform, keine repräsentative Messung für die gesamte Branche. Die charakteristische Technik ist die Proposer-Critic-Schleife: Ein Modell erstellt einen Entwurf, ein zweites – mit einem anderen Prompt und oft von einem anderen Anbieter – bewertet diesen anhand expliziter Kriterien, ähnlich wie in einer Redaktion, in der Autoren und Lektoren zusammenarbeiten. Die Bank im Artikel betreibt Agenten für Entwurfserstellung, Markenkonformität und die Offenlegung rechtlicher Bestimmungen, deren Unstimmigkeiten einem Menschen mit markierten Klauseln vorgelegt werden; das Pharmaunternehmen setzt Retrieval-, Lese-, Kritiker- und Synthese-Agenten für medizinische Fachliteratur ein und schreibt dem Kritiker-Durchlauf zu, dass das Medical-Affairs-Team den Ergebnissen vertraut und entsprechend handelt.

Wo TrueFoundry ansetzt

Das Team vervielfacht alles, was ein einzelner Agent hatte – Identitäten, Tool-Zugriffe, Token-Flüsse – und fügt eine Schnittstelle hinzu, die der Artikel ohne Preisangabe hervorhebt: Dass der Kritiker ein Modell eines anderen Anbieters ist, bedeutet in einem maßgeschneiderten Stack eine zweite Integration, zweite Anmeldedaten und einen zweiten Logging-Pfad. Das Gateway eliminiert einen Großteil dieser anbieterspezifischen Verbindungs- und Anmelde-Infrastruktur: Die einheitliche, OpenAI-kompatible API stellt das Entwurfsmodell und das Kritikermodell hinter ein gemeinsames Schema (Gateway-Dokumentation). Was es nicht tut, ist die Implementierung der Schleife. Die Anwendung oder das Agent-Harness steuert weiterhin die Orchestrierung – die Abfolge der Schritte, die Erstellung der Bewertungskriterien für den Kritiker, die Verwaltung des Zustands zwischen den Rollen, den Umgang mit Unstimmigkeiten sowie die Entscheidung, wann überarbeitet, gestoppt oder eskaliert werden soll – und ein gemeinsames Anfrageschema macht Anbieter nicht semantisch austauschbar. Das vervielfachte Risiko liegt in der Zuordnung, und das dokumentierte Modell ist hierbei präzise: Die Zuordnung einzelner Agenten erfordert eine eindeutig registrierte Agenten-Identität für jede unabhängig verwaltete Rolle – das pro-Agent-Prinzip, das jeder Agent vorweisen muss, wenn er auf das MCP-Gateway oder das Agent-Gateway zugreift. Ein Virtuelles Kontohingegen repräsentiert einen Dienst oder eine Anwendung und ist dort sinnvoll, wo keine Identität auf Agentenebene erforderlich ist; weist man mehreren Agenten ein einziges virtuelles Konto zu, werden sie zu einem einzigen Gateway-Aufrufer zusammengefasst. Die Identität beantwortet wer der Agent ist; die zugehörige Agentenregistrierung und die bereichsspezifischen Gateway-Richtlinien definieren dann, wer den Agenten aufrufen darf, in wessen Namen er handeln kann und welche nachgelagerten Tools oder Dienste er erreichen darf (die Dokumentation weist darauf hin, dass einige Funktionen auf dieser Seite schrittweise eingeführt werden). Wenn die Rollen auf Agent-zu-Agent-Ebene in großem Maßstab koordiniert werden, ist die Governance auf Protokollebene das Thema unserer Multi-Agenten-A2A-Analyse. Tool-Aufrufe, die zwischen Rollen fließen, durchlaufen wie alle anderen die Pre- und Post-Invoke-Hooks: eine Inspektion bei jedem Hop.

Art 5: Der Human-in-the-Loop-Agent

Was es ist

Die Kolumne korrigiert den Diskurs über Autonomie deutlich: Das praktische Ziel ist selektive Automatisierung statt maximaler Autonomie. Der Agent übernimmt die mechanischen 80 %, während das menschliche Urteilsvermögen in den entscheidenden Momenten gefragt bleibt. In Moodys globaler Umfrage unter 600 Risiko- und Compliance-Expertengaben 42 % an, dass menschliche Aufsicht zwingend erforderlich ist. Das Beispiel aus dem Gesundheitssystem stellt klinische Nachweise zusammen und entwirft Vorabgenehmigungsschreiben, die ein Fallmanager (Pflegekraft) innerhalb des bestehenden Workflow-Tools in Sekunden genehmigt, bearbeitet oder ablehnt; der Agent eines Immobilienverwalters analysiert den HVAC-Notfall eines Mieters, wählt den passenden Dienstleister aus und erstellt den Arbeitsauftrag – eine Person genehmigt dies in Slack, bevor etwas versendet wird. Danach sendet der Agent eine E-Mail an den Dienstleister, beruhigt den Mieter und schließt den Vorgang ab. Nach Erfahrung der Kolumne ist dies der Archetyp, der skeptische Teams in begeisterte verwandelt.

Wo TrueFoundry sich einfügt

Dies ist der Archetyp mit dem direktesten Produkt-Primitiv: Agent Harness implementiert den zentralen HITL-Mechanismus – das Anhalten eines sensiblen Tool-Aufrufs, das Anzeigen des Tool-Namens und der Argumente sowie die Fortsetzung erst nach einer expliziten Genehmigung oder Ablehnung (Human-in-the-Loop-Dokumentation), konfiguriert für sensible Vorgänge und nur für diese. Die umgebende Überprüfungserfahrung – wer die Anfrage erhält, wo sie erscheint, wie lange sie warten darf, was nach einem Timeout passiert – bleibt Workflow-Design, und Genehmigungen ergänzen die Autorisierung, anstatt sie zu ersetzen. Das Designrisiko liegt in der Ergonomie – ein Gate, das Minuten dauert, wird umgangen; ein Gate für alles wird zum Rauschen – daher ist die Disziplin aufgabenorientierter Zugriff, bei dem Berechtigungen und Sperren nach dem Bedarf der Aufgabe vergeben werden, das Modell, das unsere TBAC-Analyse entwickelt. Der integrierte Katalog an Leitplanken liefert die mechanischen Filter für das Gate, sodass sich die menschliche Aufmerksamkeit auf das Urteilsvermögen konzentrieren kann: Wenn er an den Pre-Tool-Hook angehängt wird, ist das dokumentierte SQL-Sanitizer kann DROP-, TRUNCATE- und WHERE-lose DELETE-Befehle blockieren, bevor das nachgelagerte Tool sie ausführt, und der Code-Safety-Linter markiert gleichermaßen gefährliche Shell-Muster in den Hooks, für die er konfiguriert ist (Dokumentation zu Guardrails) – die bloße Existenz des Guardrails fängt noch nichts ab; erst die Hook-Anbindung bewirkt dies.

‍