A stateful mock for business systems, and why test modes fail agents
A stateful mock for business systems is a copy of a system an agent acts on that keeps what the agent does to it: the same URLs, errors and state machine as the real API, on your machine. It exists because vendor test modes were built for developers checking a request, not for agents that take dozens of actions and have to be graded on what changed.
What an agent needs from a test environment
A developer needs one thing: a request that answers the way production would. An agent needs five. State, because its second call depends on its first. A reset, so every run starts from the same place. Faults on demand, because the retry that double refunds only shows under a 429. A clock, because renewals and expirations take weeks in real time. And a record of every object that changed, read from the system rather than from the agent. The native test modes fail at least one of the five, usually three.
A stateful Stripe mock, and the one Stripe ships
Stripe's official mock server, stripe-mock, is stateless on purpose: its README says POST data is validated and then ignored, and that Stripe is not planning to add statefulness. Stripe test mode keeps state, but it is one account shared by the whole team: no reset between runs, no faults, and a clock that moves only by hand. A stateful Stripe mock keeps customers, charges, refunds, invoices and subscriptions under Stripe's rules, resets in milliseconds, injects faults, advances the clock and hands back a diff. The one on this site is verified against real Stripe: every claimed behavior is a probe run against test mode, dated and published.
Zendesk sandbox vs production
Zendesk's documentation describes its sandbox as a moment in time: a copy of production that does not stay synchronized after it is created, with tickets and users that can only be updated by hand. It drifts from the queue the agent will work, and every run leaves leftovers for the next. A stateful mock of Zendesk is a pseudonymized copy of your own account, fresh for every run, with the ticket lifecycle enforced: a closed ticket cannot be reopened, an internal note never reaches the requester.
Shopify test environment limits
Shopify's development stores cannot process real transactions and cannot become production stores, and a live store with payments in test mode cannot take live orders. An agent that handles orders, refunds and fulfillment is tested either on a store with none of your customers or on the real store with checkout off, and neither resets. A stateful mock of Shopify keeps products, orders, fulfillments and refunds under Shopify's rules and shows every refund in the diff, in dollars.
Salesforce sandbox limits
Salesforce publishes a refresh interval per sandbox type: daily for a Developer sandbox, every five days for a Partial Copy, every twenty nine days for a Full sandbox, the only kind with all of production's data (Salesforce sandbox types). A refresh is the reset button, and for the sandbox with the data it can be pressed once a month. A test suite needs it before every run. A stateful mock of Salesforce is a copy of your org that resets in milliseconds, with validation rules, lead conversion and stage transitions enforced.
The pattern behind the four
The vendors are not wrong. A sandbox copied once, a mock that keeps nothing, a store that cannot take money: each is the right tool for a developer checking a request. Agents changed the job. An agent takes many actions in an order nobody scripted, and the question is what the system looks like afterwards. That needs a system that can be put back, broken, aged and read. HubSpot, Intercom, Twilio, QuickBooks, NetSuite, Workday, Okta and Gmail fail the same five requirements in their own ways; the catalog has a page per system with the vendor's documentation cited.
The test mode alternative in practice
A world is the stateful mock with the five requirements built in. Created from a seed, the same bytes every time. A mark records its state before the agent starts. The agent acts through its stock SDK with no code change. A diff reads back every object that changed, and where money moved. A scenario injects rate limits, outages, a slow API, an expired key and dropped webhooks. The clock advances and the world settles as the real system would. The same world starts fresh inside a CI job. Three commands get there in about ten minutes; testing agents before production is the shape of the first run.