14.01.2026 AI Engineering 5 Minuten Lesezeit

Simulierte Gegensysteme: Journey-Tests gegen Systeme, die Sie nicht kontrollieren

Agentische Systeme beenden ihre Journeys an Systemen, die andere betreiben: Behörden, Banken, Partner-APIs. Wir definieren simulierte Gegensysteme hinter identischem Agentenvertrag, zeigen Ende-zu-Ende-Journey-Tests vor dem Go-live und begründen strikte Provenienz-Kennzeichnung: Ein simulierter Erfolg belegt Logik, nie Produktionsreife. Mit verifizierten Daten, klaren Grenzen und Beispielen aus MCP, A2A und PSD2.

Wenn das Gegensystem fehlt

Agentische Systeme handeln selten allein. Jede Journey, die zählt — ein Antrag bei einer Behörde, eine Zahlungsauslösung, eine Bestellung beim Partner — endet an einem System, das jemand anderes betreibt. Vor dem Go-live muss die gesamte Journey nachweislich funktionieren. Das reale Gegensystem steht dafür jedoch selten zur Verfügung, und nie nach Ihrem Zeitplan.

Sandboxes existieren, aber sie sind dünn. Unter PSD2 verpflichtet die Delegierte Verordnung (EU) 2018/389 in Artikel 30 Absatz 5 europäische Banken seit dem 14. März 2019 zu einer Testumgebung; sensible Daten sind dort ausdrücklich ausgeschlossen, und das Verhalten weicht oft von der Produktion ab. Behörden-Testumgebungen verlangen Registrierung und Termine. Viele Partner bieten gar nichts an. Journeys werden in Fragmenten getestet, nie Ende-zu-Ende.

Die Folge ist ein bekanntes Muster: Integrationscode entsteht gegen Dokumentation, wird gegen ein Fragment verifiziert, und die erste vollständige Journey läuft in Produktion. Für deterministische Software war das riskant. Für agentische Systeme, die Aktionen zur Laufzeit wählen, ist es untragbar — der Raum möglicher Pfade ist größer, und nur ausgeführte Pfade sind getestete Pfade.

Zwei Peers — jeder mit eigenem Zustand und privatem Graph. 1/4

Ein Vertrag und zwei Implementierungen

Ein simuliertes Gegensystem ist ein Stellvertreterdienst, der exakt den Vertrag des realen Systems implementiert: dieselben Operationen, dieselben Schemata, dieselben Fehlercodes. Der Unterschied liegt hinter dem Vertrag, nicht in ihm. Der getestete Agent kann beide nicht unterscheiden; zwischen den Umgebungen ändern sich nur Endpunkt und Credentials. Wir verwenden den Begriff Gegensystem bewusst breit: Er umfasst Behörden, Banken und kommerzielle Partner — jedes System auf der anderen Seite eines Vertrags, den Sie nicht kontrollieren.

Agentenprotokolle machen das praktikabel, weil sie den Vertrag explizit machen. Das Model Context Protocol, von Anthropic am 25. November 2024 veröffentlicht und aktuell in Spezifikationsrevision 2025-11-25, definiert Tools als benannte Operationen mit JSON-Schemata. A2A, von Google am 9. April 2025 angekündigt und seit dem 23. Juni 2025 bei der Linux Foundation, leistet dasselbe für den Austausch zwischen Agenten. Microcks 1.12.0 (Mai 2025) stellt OpenAPI-, gRPC- und GraphQL-Mocks bereits als MCP-Endpunkte bereit. Der Vertrag ist die Nahtstelle; die Simulation dockt an ihr an.

Verhalten ist mehr als Antworten

Eine vorgefertigte 200-Antwort ist ein Stub, kein Gegensystem. Reale Gegensysteme haben Zustand: Ein Antrag wandert von eingegangen über in Prüfung nach entschieden. Sie haben Zeit: Entscheidungen dauern Tage, nicht Millisekunden. Sie fallen aus: Timeouts, Wartungsfenster, mehrdeutige Fehlercodes. Eine brauchbare Simulation ist eine kleine Zustandsmaschine mit konfigurierbarer Latenz und injizierbaren Fehlern. Fault Injection muss pro Test skriptbar sein, nicht in globaler Konfiguration vergraben.

Determinismus ist nicht verhandelbar. Jeder Lauf startet mit definiertem Seed und definiertem Anfangszustand, damit ein fehlgeschlagener Journey-Test exakt reproduzierbar ist. Der Anspruch bleibt ehrlich begrenzt: Die Simulation implementiert den dokumentierten Vertrag plus die Fehlermodi, die Sie bewusst modelliert haben. Die undokumentierten Eigenheiten des realen Systems bildet sie nicht ab — und sollte es auch nicht vorgeben.

Journey-Tests vor dem Go-live

Ein Journey-Test treibt eine vollständige Geschäftstransaktion durch den Agenten und alle Gegensysteme: einreichen, Rückfrage erhalten, korrigieren, erneut einreichen, Entscheidung empfangen. Geprüft werden das Ergebnis der Journey und die Zwischenzustände, nicht einzelne Antworten. Gegen simulierte Gegensysteme läuft das in der CI bei jeder Änderung, in Minuten, ohne Termine und ohne Sandbox-Kontingente zu verbrauchen.

Der Wert liegt in den Unhappy Paths. Abgelaufene Mandate, doppelte Einreichungen, eine Ablehnung nach drei Tagen im Schwebezustand, ein Partnerausfall mitten in der Journey — die reale Welt erzeugt diese Fälle selten und nie auf Abruf. Die MCP-Revision 2025-11-25 ergänzt experimentelle Tasks für langlaufende Anfragen mit Polling; asynchrones Verhalten des Gegensystems, bei Behörden und Banken der Normalfall, wird damit im Vertrag selbst darstellbar.

Simulierte Erfolge ehrlich kennzeichnen

Ein grünes Dashboard aus simulierten Läufen belegt Logik, nicht Reife. Der Fehlermodus ist leise: Simulierte und reale Ergebnisse fließen in eine gemeinsame Pass-Rate, und das Label verschwindet. Unsere Regel ist Provenienz an jedem Ergebnis. Ein Testbericht nennt pro Journey, welche Gegensysteme real waren, welche Sandboxes und welche Simulationen. Dashboards führen dieselbe Trennung; ein simulierter Erfolg erhöht nie eine Produktionsreife-Metrik.

Die drei Klassen bilden eine Ordnung, und jede ist notwendig: Die Simulation liefert Abdeckung und Wiederholung, die Sandbox liefert Wahrheit auf Leitungsebene, der Pilot liefert Betriebswahrheit. Keine ersetzt die nächste. Einen simulierten Erfolg als Go-live-Nachweis zu berichten ist kein Optimismus, sondern Falschauszeichnung — und sie fällt zum ungünstigsten Zeitpunkt auf.

Label	Gegensystem	Ein Pass belegt
Simulated Pass	Simulation unter eigener Kontrolle	Journey-Logik und Vertragskonformität
Sandbox Pass	Testumgebung des Betreibers	Wire-Kompatibilität und Auth-Flüsse
Live-Verifikation	Produktivsystem im begrenzten Pilot	Betriebsreife

Was Simulation nicht beweist

Simulation beweist nicht die Performance des realen Gegensystems, nicht dessen undokumentierte Validierungsregeln, nicht seine Zertifikatsketten und nicht den organisatorischen Prozess dahinter. Unter PSD2 werden produktive eIDAS-Zertifikate nur an zugelassene Anbieter ausgegeben; der reale Authentifizierungspfad ist vor der Zulassung schlicht nicht testbar. Simulation beweist auch nicht, dass Ihr Modell des Gegensystems aktuell ist.

Die Treue driftet. Das reale System ändert sich, die Simulation hinkt nach. Die Gegenmaßnahmen sind mechanisch: die Simulation aus demselben Vertragsartefakt generieren, das auch der Client nutzt; eine kleine Konformitätssuite regelmäßig gegen die reale Sandbox laufen lassen; jede Abweichung zwischen Simulation und Sandbox als Defekt der Simulation behandeln — mit Verantwortlichem und Termin.

Ausblick im Januar 2026

Wir erwarten, dass Gegensystem-Simulation vom privaten Testgerüst zum Liefergegenstand wird. Explizite Verträge — MCP-Tool-Schemata, A2A Agent Cards — machen Simulationen weitgehend aus dem Artefakt generierbar. Wer 2026 eine Agentenschnittstelle veröffentlicht, kann ihre Simulation mitveröffentlichen, so wie PSD2 die Banken 2019 zu Testumgebungen verpflichtet hat. Der Aufwand sinkt entsprechend; das Argument dagegen verschwindet.

Zwei Prognosen. Erstens: Regulierte Branchen werden Journey-Nachweise mit ausgewiesener Provenienz — simuliert, Sandbox, live — verlangen, bevor agentische Systeme Behörden oder Zahlungen berühren. Zweitens: Teams, die die Simulation vor der Integration bauen, liefern schneller als Teams, die auf Zugang zum Gegensystem warten. Bei Blue IT Systems besetzen wir Projekte bereits in dieser Reihenfolge: Die erste Zeile Integrationscode entsteht, nachdem das simulierte Gegensystem seine eigene Konformitätssuite bestanden hat.