14 Jan 2026 AI Engineering 5 min read

Simulated Counterparts: Journey Testing Against Systems You Do Not Control

Agentic systems end their journeys at systems other people operate: authorities, banks, partner APIs. We define simulated counterparts that implement the identical agent contract, show how end-to-end journey tests run against them before go-live, and argue for strict provenance labeling — a simulated pass proves logic, never production readiness. Verified dates, honest limits included.

The counterpart you cannot call

Agentic systems rarely act alone. A journey that matters — filing a submission with an authority, initiating a payment, ordering from a partner — ends at a system someone else operates. Before go-live, the whole journey must be shown to work. The real counterpart, however, is rarely available for testing, and never on your schedule.

Sandboxes exist, but they are thin. Under PSD2, Delegated Regulation (EU) 2018/389 Article 30(5) has obliged European banks to offer a testing facility since 14 March 2019; sensitive data is explicitly excluded there, and behavior often diverges from production. Authority test environments require registration and appointments. Many partners offer nothing at all. Journeys end up tested in fragments, never end to end.

The consequence is a familiar pattern: integration code is written against documentation, verified against a fragment, and the first complete journey runs in production. For deterministic software this was risky. For agentic systems, which choose actions at runtime, it is untenable — the space of paths through a journey is larger, and only executed paths are tested paths.

Two peers — each with its own state and private graph. 1/4

One contract two implementations

A simulated counterpart is a stand-in service that implements exactly the contract of the real system: the same operations, the same schemas, the same error codes. The difference is behind the contract, not in it. The agent under test cannot tell the two apart; only an endpoint and a credential change between environments. We use the term counterpart deliberately: it covers authorities, banks, and commercial partners alike — any system on the other side of a contract you do not control.

Agent protocols make this practical because they make the contract explicit. The Model Context Protocol, released by Anthropic on 25 November 2024 and now at specification revision 2025-11-25, defines tools as named operations with JSON schemas. A2A, announced by Google on 9 April 2025 and hosted by the Linux Foundation since 23 June 2025, does the same for agent-to-agent exchanges. Microcks 1.12.0 (May 2025) already serves OpenAPI, gRPC, and GraphQL mocks as MCP endpoints. The contract is the seam; the simulation plugs into it.

Simulate behavior not just responses

A canned 200 response is a stub, not a counterpart. Real counterparts have state: an application moves from received to in-review to decided. They have time: decisions take days, not milliseconds. They fail: timeouts, maintenance windows, ambiguous error codes. A useful simulation is a small state machine with configurable latency and injectable faults. Fault injection must be scriptable per test, not buried in global configuration.

Determinism is non-negotiable. Every run starts from a defined seed and a defined initial state, so a failing journey test replays exactly. Scope the simulation honestly: it implements the documented contract plus the failure modes you deliberately modeled. It does not reproduce the undocumented quirks of the real system, and it should not pretend to.

Journey tests before go-live

A journey test drives one complete business transaction through the agent and every counterpart: submit, receive a query, correct, resubmit, get the decision. The test asserts on the journey outcome and on the intermediate states, not on single responses. Against simulated counterparts, this runs in CI on every change, in minutes, without appointments and without burning sandbox quotas.

The value is in the unhappy paths. Expired mandates, duplicate submissions, a rejection after three days in a pending state, a partner outage mid-journey — the real world produces these cases rarely and never on demand. The MCP 2025-11-25 revision adds experimental tasks for long-running requests with polling; asynchronous counterpart behavior, the normal case with authorities and banks, is becoming representable in the contract itself.

Label simulated success as simulated

A green dashboard fed by simulated runs is evidence of logic, not of readiness. The failure mode is silent: simulated and real results aggregate into one pass rate, and the label disappears. Our rule is provenance on every result. A test report states, per journey, which counterparts were real, which were sandboxes, and which were simulations. Dashboards carry the same split; a simulated pass never increments a production-readiness metric.

The three classes form an order, and each is necessary: simulation gives coverage and repetition, the sandbox gives wire-level truth, the pilot gives operational truth. None replaces the one after it. Reporting a simulated pass as go-live evidence is not optimism; it is mislabeling, and it will be discovered at the worst possible time.

Label	Counterpart	A pass proves
Simulated pass	Simulation under your own control	Journey logic and contract conformance
Sandbox pass	Test environment run by the operator	Wire-level compatibility and auth flows
Live verification	Production counterpart in a limited pilot	Operational readiness

What simulation does not prove

Simulation does not prove the performance of the real counterpart, its undocumented validation rules, its certificate chains, or the organizational process behind it. Under PSD2, production eIDAS certificates are issued only to authorised providers; the real authentication path is untestable before authorisation exists. Simulation also does not prove that your model of the counterpart is current.

Fidelity drifts. The real system changes; the simulation lags. The countermeasures are mechanical: generate the simulation from the same contract artifact the client uses, run a small conformance suite against the real sandbox on a schedule, and treat any divergence between simulation and sandbox as a defect in the simulation — with an owner and a deadline.

Outlook from January 2026

We expect counterpart simulation to become a deliverable rather than private test scaffolding. Explicit contracts — MCP tool schemas, A2A agent cards — make simulations largely generatable from the artifact itself. Whoever publishes an agent interface in 2026 can publish its simulation with it, the way PSD2 forced banks to publish testing facilities in 2019. The cost is falling; the argument against it is disappearing.

Two predictions. First, regulated sectors will begin to require journey evidence with labeled provenance — simulated, sandbox, live — before agentic systems touch authorities or payments. Second, teams that build the simulation before the integration will ship faster than teams that wait for counterpart access. At Blue IT Systems we already staff projects in that order: the first line of integration code comes after the simulated counterpart passes its own conformance suite.