Ein Jahr ist in der Welt von Agentic AI eine geologische Ära. Vor zwölf Monaten stand in einem typischen Diagramm einer „AI-Agent-Plattform“ – wir betrachten hier eines aus der Mitte des Jahres 2025 – eine Vektordatenbank im Zentrum. Agenten wurden als Unterkomponente einer „AI Layer“ behandelt, jede Tool-Integration wurde individuell verdrahtet, Monitoring verteilte sich auf vier Dashboards für Kosten, Nutzung, Daten und LLMs, und Deployment folgte klassischem CI/CD – Prompts waren eher ein nachträglich ergänztes Artefakt.
Nichts davon war falsch. Aber vieles davon ist inzwischen überholt. Dieser Artikel zeigt, wie ein produktionsreifer AI-Agent Mitte 2026 aufgebaut ist, warum sich die Architektur verändert hat und – der Teil, den viele Architekturbeiträge auslassen – wie sich das Ganze tatsächlich in eine realistische digitale Banking-Plattform mit Batch Core, ESB und bestehenden Legacy-Komponenten einfügt.
Drei Entwicklungen erklären fast alles, was sich im Architekturmodell verändert hat.
Tool Access wurde standardisiert. Das von Anthropic im November 2024 eingeführte Model Context Protocol wurde zum De-facto-Standard für die Verbindung von Agenten mit Tools und Daten. Es wurde von OpenAI, Google, Microsoft und AWS übernommen, im Dezember 2025 an die „Agentic AI Foundation“ der Linux Foundation übergeben und verzeichnet monatlich rund 97 Millionen SDK-Downloads. Bis Mitte 2026 setzten laut Umfragen 78 % der Enterprise-AI-Teams MCP-gestützte Agenten in Produktion ein.
Die Spezifikationsrevision vom November 2025 ergänzte Funktionen, auf die Unternehmen gewartet hatten: asynchrone Long-Running Tasks, formale Server Identity und strukturierte Audit Trails. Die Konsequenz für die Architektur ist wesentlich: Integration ist nicht länger der Mittelpunkt des Diagramms. Statt massgeschneiderter Verbindungen zeichnet man ein standardisiertes Protokoll mit einer governed Tool Registry dahinter.
Für Multi-Agent Coordination übernimmt ein zweites Protokoll eine wichtige Rolle: Googles A2A, das inzwischen ebenfalls unter dem Dach der Linux Foundation steht. Der sich abzeichnende Architekturansatz ist ein Layered Stack: MCP gibt einem Agenten seine „Hände“, A2A ermöglicht die Koordination mehrerer Agenten.
Retrieval wurde – bewusst – zurückgestuft. Was 2025 noch das Zentrum vieler Architekturdiagramme war – Landing Zone → Chunking → Vectorization → Vector DB → Knowledge API – ist heute eines von mehreren Tools, die ein Agent aufrufen kann.
Produktionsagenten beantworten 2026 viele Fragen, indem sie governed Business APIs aufrufen oder direkt auf Datenplattformen zugreifen – unter denselben Access Controls, die auch für menschliche Nutzer gelten. Retrieval bleibt wichtig, ist aber nicht mehr die Architektur selbst.
Ein besonders deutliches Signal ist, wer heute Managed MCP Interfaces bereitstellt: die Datenplattformen selbst. Sie stellen governed Query Tools zur Verfügung, sodass Agenten die bestehenden ACLs der Plattform übernehmen, anstatt sie über exportierte Vektorkopien zu umgehen.
Identity und Governance sind Teil der Architektur geworden – nicht nur Teil von Policy-Dokumenten. Das ist der grösste kulturelle Wandel. Agenten authentifizieren sich, erhalten Credentials und führen Aktionen aus. Damit wird jeder Agent zu einer privilegierten Non-Human Identity.
Die Zahlen dazu sind bemerkenswert: Eine Umfrage der Cloud Security Alliance ergab, dass 68 % der Unternehmen AI-Agent-Aktivitäten nicht zuverlässig von menschlichen Aktivitäten unterscheiden können. Der Gravitee Agent Security Report 2026 stellte zudem fest, dass 45,6 % der Befragten Shared API Keys für die Authentifizierung von Agenten einsetzen.
Klassisches IAM wurde für deterministische Software mit vorhersehbaren Zugriffsmustern entwickelt. Agenten entscheiden jedoch zur Laufzeit, auf welche Ressourcen sie zugreifen. Deshalb lassen sich Berechtigungen nicht immer vollständig im Voraus festlegen.
Das Modell, auf das sich die Branche zunehmend zubewegt – häufig als Blended Identity bezeichnet –, gibt jeder Agenteninstanz eine eigene überprüfbare Identität, die mit dem Menschen verknüpft ist, für den sie handelt, aber von dessen Identität getrennt bleibt. Zur Laufzeit werden kurzlebige, task-spezifische Credentials ausgegeben und Least Privilege direkt am Zugriffspunkt durchgesetzt. Das NIST startete im Februar 2026 eine „AI Agent Standards Initiative“, die genau diesen Bereich von Identity und Authorization adressiert.
Wenn Ihre Agentenarchitektur noch immer einen Service Account zeigt, ist es ein Diagramm aus 2024 mit einem Titel aus 2026.
Im Zentrum des Diagramms steht eine persistente Agent Runtime: ein Reasoning Loop aus Plan → Act → Observe → Reflect mit begrenzten Schritten und Budget Limits, Context Assembly, Session- und Long-Term Memory sowie ein expliziter Task Lifecycle für Long-Running, resumable und idempotente Workflows. Optional können Aufgaben über A2A an Sub-Agents delegiert werden.
Darunter liegt ein Model Gateway: Frontier Models, kleinere oder lokale Modelle für Klassifikation und PII-sensitive Aufgaben sowie Embeddings – alles routbar und, entscheidend, austauschbar. Das Modell selbst ist eine der am leichtesten ersetzbaren Komponenten des Stacks. Runtime, Tools, Policies und Evidence sind die Teile, die langfristig Ihnen gehören.
Rechts davon befindet sich der Tool Plane: ein MCP Client mit einer agentenspezifischen Allowlist vor den governed Tools – Business APIs mit Read-, Propose- und Execute-Scopes, Retrieval, Datenplattformen, eine Code Sandbox ohne Production Credentials und geprüfte SaaS-Server.
Alle Tools werden über eine Private MCP Registry mit Schema Review, Security Scanning und Approval Workflow zugelassen. Diese Registry ist keine bürokratische Zusatzschicht. Unabhängige Scans zeigen, dass viele öffentliche MCP-Server ausnutzbare Risiken enthalten und nur ein kleiner Anteil standardmässig OAuth nutzt. In einem Unternehmen muss „Wir haben einen MCP-Server aus dem Internet installiert“ genauso undenkbar sein wie „Wir haben ein beliebiges npm-Paket direkt ins Core-Banking-System installiert“.
Um diese Komponenten herum liegen drei Ebenen, die im Architekturdiagramm von 2025 weitgehend fehlten:
Monitoring hat sich damit zu Evidence weiterentwickelt. Dashboards zeigen, was passiert ist. Ein Evidence Log erlaubt Ihnen, gegenüber einem Auditor nachzuweisen, warum und unter welchen Kontrollen es passiert ist. Unter den Erwartungen der FINMA-Mitteilung 08/2024 zu Inventarisierung, Dokumentation und Erklärbarkeit ist genau das ein wesentlicher Unterschied zwischen einem Pilot und einem produktiven System in einem Schweizer Finanzinstitut.
Referenzarchitekturen zeigen gerne die ideale Bank. Reale Plattformen sehen eher wie das obige Diagramm aus: Channels wie Mobile, E-Banking, Advisor Workplace und Callcenter laufen über BFFs und ein API Gateway. Dahinter liegt ein Digital Services Layer mit Komponenten aus unterschiedlichen Generationen – ein Payments Microservice aus 2022 neben einem Cards-Modul aus 2014 innerhalb eines Monolithen, daneben eine KYC-Suite eines externen Anbieters.
In der Integration Layer trägt der SOAP-ESB aus 2009 möglicherweise noch immer einen wesentlichen Teil der Last, während Kafka nur die neueren Flows transportiert. Dazu kommen Systems of Record mit einem batchorientierten Core der Avaloq-/Finnova-Klasse, nächtlichem General-Ledger-Close, Payment Rails, CRM, Screening Engines und Dokumentenarchiv.
Gleichzeitig existiert eine Datenlandschaft, in der das Legacy-DWH weiterhin Regulatory Reporting übernimmt, während ein Lakehouse daneben Analytics verarbeitet. Diese Koexistenz ist kein Fehlzustand. So sieht eine Organisation aus, die gleichzeitig eine Bank betreibt und ihre Plattform modernisiert – und genau in diesem Umfeld müssen AI-Agenten funktionieren.
Agenten werden an vier Stellen integriert:
Eine realistische Einschätzung ist wichtig – denn „alles für AI neu bauen“ ist Vendor-Rhetorik, keine Architekturstrategie.
Advisor Copilot – read-heavy und heute bereits realistisch. Ein Berater fragt im Kontext aktueller Richtlinien nach dem Portfolio eines Kunden. Der Agent ruft über MCP Retrieval-, CRM- und Portfolio-Tools im Namen der Identität des Beraters auf – und nichts erreicht den Kunden ohne Freigabe des Beraters. Dieses Szenario läuft weitgehend auf bereits vorhandener Infrastruktur. Die wesentlichen Anpassungen betreffen Identity Binding und das Output Gate. Deshalb sind Advisor Copilots 2026 deutlich verbreiteter als autonome Payment Agents.
Payment-Exception-Triage – propose, don't execute. Eine markierte oder fehlgeschlagene Zahlung landet auf dem Event Bus. Der Agent analysiert den Status über verschiedene Payment Rails hinweg, berücksichtigt Screening-Ergebnisse und Account Context und schreibt anschliessend einen Lösungsvorschlag mit Begründung in das Case Management System – wo Operations die eigentliche Aktion ausführt.
Write Access bleibt auf das Case Tool beschränkt und die Autonomie auf Propose. Was dieses Szenario heute häufig verhindert, ist nicht das Modell, sondern Workstream 2 – Simulation Endpoints und Scoped Writes – sowie ein Evidence Store, mit dem sich die Triage gegenüber einem Regulator nachvollziehbar erklären lässt.
Periodisches KYC-Review – long-running und evidence-critical. Zum geplanten Zeitpunkt sammelt der Agent Registerdaten, extrahiert Informationen aus Dokumenten im DMS, erstellt einen Entwurf für die Risk Reassessment und stellt ein Evidence Pack zusammen. Anschliessend prüft und unterzeichnet ein menschlicher Analyst das Ergebnis.
Dieses Szenario nutzt praktisch alle neuen Architekturbausteine gleichzeitig: einen asynchronen Task Lifecycle mit Checkpoints über mehrere Stunden, DMS Governance aus Workstream 6 und eine tamper-evident Evidence Chain, weil das Ergebnis selbst ein Compliance-Artefakt ist. Gleichzeitig ist hier der potenzielle Nutzen besonders hoch: Periodic Reviews sind volumenintensiv, stark prozessgetrieben und häufig von Backlogs betroffen.
Bauen Sie zuerst die gemeinsamen Plattformbausteine auf: Identity Broker, MCP Registry, HITL-Service und Evidence Store. Jeder weitere Agent profitiert davon.
Nutzen Sie Szenario 1, um den Mehrwert auf bestehender Infrastruktur zu zeigen. Szenario 2 zwingt die Organisation dazu, die notwendige API Semantics sauber umzusetzen. Szenario 3 wird sinnvoll, sobald die Evidence Chain belastbar ist.
Und genau dabei wird etwas Grundsätzliches sichtbar: Ein Grossteil dessen, was für „Agent Readiness“ benötigt wird – governed APIs über dem Core, Event Access, Data Governance und machine-consumable Interfaces – ist klassische Modernisierungsarbeit mit einem neuen Sponsor. Banken, die beide Themen als eine gemeinsame Roadmap behandeln, können mit einem Programm zwei Ziele erreichen.
In einer technischen Demo zeigen wir das Modernization Framework an einem realen System – einschliesslich der in diesem Artikel beschriebenen kontrollierten Zugriffspfade.
Technische Demo