Zendesk's own documentation describes its sandbox as a moment in time: a copy of the production account's settings and data that does not stay synchronized with production after it is created (About Zendesk sandbox environments). Tickets and user records inside it are never refreshed at all; the only way to update them, Zendesk says, is to recreate them by hand. So the sandbox an agent is tested in drifts away from the queue it will actually work, fills up with the leftovers of every previous run, and offers no way to break anything on purpose. The Zendesk world is a stateful Zendesk mock built for testing agents: the same URLs, the same errors and the same state machine as the real API, on your machine, fresh for every run, verified against the real system.
Zendesk sandbox vs production
The difference that matters for an agent is not features, it is time. Production moves; the sandbox does not. A support agent tested in March against a February snapshot has never seen the macro someone added in April or the SLA policy that changed in May, and the tickets it practiced on are the same tickets, in the same state, that every previous run left behind. A world turns that around. It is a pseudonymized copy of your own account, taken when you ask for it, and every run starts from the same bytes: the same tickets in the same states, the same requesters, the same groups. When the run ends the world is thrown away, and the next run gets a fresh one in milliseconds.
A stateful Zendesk mock: tickets, macros, SLAs, escalations
The world keeps tickets with their status, priority, group, assignee, tags and comments, public and internal; requesters and organizations; macros; SLA policies; the escalation paths the queue rules define. It keeps Zendesk's rules with them. A ticket moves from new to open to pending to solved and, after a while, to closed; a closed ticket cannot be reopened, only followed up with a new one, so an agent that tries gets the real refusal in the real words. A public comment reaches the requester and an internal note does not. A macro applies its actions in order. Every object the agent creates or changes stays in the world, so the second request sees what the first one did.
Test your AI agent against Zendesk
Point the agent's Zendesk client, or its plain HTTP calls, at the world. Nothing in the agent changes. The ticket arrives as JSON, the agent does what it does, and the world records every call. The path is three commands: the first copies the account and writes the worlds folder, the second turns your own help desk export into tasks, one per row, and the third runs the agent three times on fresh copies and writes the report. The three steps take about ten minutes; the GET ACCESS form on this page is where the Zendesk world starts.
Grade what the agent did, not what it said
A run starts from a mark, the world's state at that moment, and ends with a diff: every ticket whose status changed, every comment added and whether it was public, every assignment, every tag, every macro applied. The transcript says the agent escalated to the billing team; the diff shows an internal note and the same assignee. The transcript says the customer was told; the diff shows a private comment nobody outside the team can read. When the ticket asks for money to move, the diff says so in dollars, because the same run can act on a payments world beside this one. The report gives every task a verdict and a reason, and replays the worst run to the byte.
Break it on purpose
Zendesk rate limits its API, and an agent working a queue will meet the limit at the worst moment. In the world that moment is on your schedule: a 429 on every third call, an outage in the middle of a run, a slow API, an expired token, a webhook that arrives twice. Does the agent retry and post the same comment twice? Does it tell the customer the ticket is solved when the update never landed? Then move the clock, so pending tickets age past their SLA and the breach shows up in the diff.
Zendesk test environment for agents, in CI
The same command that runs on a laptop is the CI step the first command wrote. No server to host, no sandbox to share: the world starts fresh inside the job, the agent runs every task, the report is the artifact, and nothing leaves the machine. Every world in the catalog takes the same path; Intercom, Salesforce and Stripe are three more of them, and the docs are the path in full.