State Machines: Isolated Salesforce, SAP, Zendesk Clones for Agent Evals

Every team building an agent that touches Salesforce, SAP, or a ticketing system runs into the same wall during evals: test against the real thing and risk corrupting production data (or paying for seats you only need for CI), or fake it with mocks that don't behave like the real API under multi-step state changes. State Machines, a new startup that launched September 8, 2026, is building infrastructure specifically for that gap — isolated, stateful clones of enterprise software that agents can act against as if they were production.

The pitch, from the company's own X announcement: "Introducing State Machines. The first infrastructure to spin up enterprise environments. Any enterprise app, recreated for agents. Run thousands of environments in parallel, each with its own state." It's a narrow, practitioner-facing idea, and it lands squarely in the same space explainx.ai has been tracking around agent sandbox isolation and AI coding agent evals all year.

TL;DR

Why "test against the real enterprise app" has been a hard problem

Anyone who has tried to eval an agent meant to work a CRM or a ticketing queue has hit one of two bad options:

1. Live seats. You provision real Salesforce or ServiceNow accounts for testing. It's realistic, but it's expensive to scale to hundreds of parallel eval runs, risky if an agent writes garbage data into a shared instance, and slow to reset between test cases — you can't cheaply spin up a thousand identical, isolated copies of a Salesforce org.
2. Mocks. You write a fake API that returns pre-scripted JSON. It's cheap and fast, but it doesn't hold real state across a multi-step interaction. An agent that creates a lead, updates the account, and then tries to close the deal needs the second and third calls to actually reflect the first — a static mock usually can't do that convincingly, and agents that pass against a mock frequently fail against the real API's edge cases.

This is the same tension explored in our coverage of agent sandbox isolation on Google Cloud and MCP sandboxing for agent context: isolation and realism trade off against each other, and most existing tooling picks one. State Machines is explicitly targeting the middle — stateful and isolated and parallel.

What State Machines actually offers, per its own site

Fetching usestatemachines.com directly (rather than relying on the launch tweet alone) confirms the following, in the company's own language:

• "Local, stateful APIs for development, testing, CI, or building environments" that simulate production enterprise applications.
• App coverage described as "every system your customers use" — with Salesforce, SAP HANA, Zendesk, Workday, ServiceNow, Slack, Jira, HubSpot, Stripe, Snowflake, and GitHub named explicitly on the homepage.
• Worked examples on the site walk through multi-step, state-dependent flows: "Create a Salesforce lead, update the account, close the deal," then "open a Zendesk ticket" and "post an SAP invoice."
• Parallelism is a headline feature: "Scale thousands of isolated instances of the apps your customers rely on. In parallel." — the site explicitly invites running the same scenario "a thousand times."
• The stated use case is agent evaluation specifically: "Test every scenario before production" using "real-life customer environments to score your agent against, the same every time" — i.e., reproducible eval scoring, not just ad hoc dev sandboxes.

What the site does not publish, as of this post: pricing tiers, team/founder names, investor information, or a public API reference/docs page (a /docs path returns a 404 at time of writing). The only contact route listed is hello@usestatemachines.com. We could not independently verify architecture details beyond what's stated on the marketing site — there's no public technical writeup of how the state persistence or isolation is implemented under the hood, so treat "how it works internally" as unconfirmed rather than assume a specific mechanism (containers, VMs, or something else).

Reading past the hype replies

The State Machines launch thread on X drew a wave of low-signal reactions ("the future of AI," "we're going hard") that add nothing concrete. The one reply worth citing is from Ashutosh Shrivastava, who described the product as "spinning up isolated stateful API replicas for parallel evals without paying for live enterprise seats." That's the clearest independent restatement of the mechanism, and it matches what the site itself shows — so treat it as corroboration, not as new information beyond the homepage.

Why this matters if you're building or evaluating enterprise agents

If you're shipping an agent that's meant to work inside Salesforce, a helpdesk queue, or an ERP system, the eval question isn't "does it write plausible-looking output" — it's "does it correctly navigate the actual state machine of that application across a multi-step task." That's a different bar than most coding-agent benchmarks test, which is why our AI coding agent evals guide and Terminal-Bench 2.0 coverage both emphasize environment fidelity over static test sets. An eval environment that resets to a known state, runs the same scenario a thousand times in parallel, and never touches a customer's actual account addresses a gap those general-purpose coding benchmarks don't cover: line-of-business software with domain-specific object models, permission structures, and workflow rules.

It's also a reminder of a pattern we flagged in Cursor's reward-hacking and eval-contamination coverage: eval infrastructure quality directly determines whether a benchmark result means anything. A stateful, resettable replica environment closes off one common failure mode — an agent "solving" a task against a mock that doesn't actually enforce the real system's rules.

Enterprise-facing agent deployment is also where the eval stakes are highest in dollar terms — see our coverage of the $600-a-day AI agent cost breakdown and the broader monthly cost of running agent workflows for what happens when an agent misfires against production systems rather than a disposable clone.

Open questions

Because State Machines just launched and has published no pricing, docs, or technical writeup, several practical questions are unanswered as of this post:

• How closely do the replicas track real API behavior — rate limits, validation errors, permission edge cases — versus just the happy path shown in the demo flows?
• How is "state" actually implemented — snapshotting, event replay, something else — and what does reset/teardown cost at scale?
• What does it cost to run, say, a thousand parallel instances for a CI suite?
• How does it stay current as Salesforce, SAP, and the rest of the named platforms ship their own API changes?

None of these are answerable from the public site today. If you're evaluating the product for your own eval pipeline, ask the State Machines team directly (hello@usestatemachines.com) rather than assuming answers.

Related on explainx.ai

• Google Cloud's 5 Agent Sandbox Truths: Cold Start, Isolation, Egress
• context-mode: MCP sandboxing and session memory for agent context windows
• AI Coding Agent Evals: How They Score on Real Repositories
• Terminal-Bench 2.0: The AI Agent Benchmark That Actually Matters
• Cursor: Reward Hacking Is Swamping SWE-bench Coding Gains
• numbat: Perplexity's Open-Source Observability Tool for AI Agents
• Garry Tan Ships GBrain Evals — But Who Grades the Grader?
• What a $600-a-Day AI Agent Workflow Looks Like

Primary source: usestatemachines.com · launch thread from @statemachineshq, September 8, 2026

Product details, app coverage, and site content reflect State Machines' public site as of September 9, 2026. This is a newly launched company with no published pricing, team information, or technical documentation — verify current details directly with the vendor before making a purchasing or architecture decision.