14.01.2026 AI Engineering5 Minuten Lesezeit

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

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

Wenn das Gegensystem fehlt

Agentische Systeme handeln selten isoliert. Jede relevante Journey — 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 Kette nachweislich funktionieren. Das reale Gegensystem steht für diesen Nachweis jedoch selten bereit und nie verlässlich 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. So werden Journeys nur in Fragmenten statt Ende zu Ende getestet.

Daraus entsteht ein bekanntes Muster: Integrationscode wird gegen Dokumentation geschrieben und an einem Fragment geprüft; die erste vollständige Journey läuft erst in Produktion. Schon für deterministische Software war das riskant. Bei agentischen Systemen, die ihre Aktionen zur Laufzeit wählen, ist es nicht vertretbar — der Pfadraum ist größer, und nur tatsächlich ausgeführte Pfade sind getestet.

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 belastbare Reihenfolge, und jede erfüllt eine eigene Funktion: Die Simulation liefert Abdeckung und Wiederholbarkeit, die Sandbox Wahrheit auf Leitungsebene, der Pilot Betriebswahrheit. Keine Stufe ersetzt die nächste. Einen simulierten Erfolg als Go-live-Nachweis auszugeben ist daher kein Optimismus, sondern eine falsche Kennzeichnung — und sie wird meist zum ungünstigsten Zeitpunkt sichtbar.

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.

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