Testing an agent against a live service changes the thing being tested. The first run creates a ticket, sends a message or updates an account. The second run starts from a different world. Teams can spend more time resetting test data and protecting real accounts than examining the behavior they wanted to improve.
Rystic builds stateful simulators for that work. Its public description centers on realistic service environments that an agent can use, change and reset. The intention is to make multi-step behavior repeatable without requiring the test to write into a live production service. [1]
A small team focused on simulation fidelity
Rystic joined YC’s Fall 2026 batch. Its public team page names founders Zachary Kiihne and Evan Whitehouse and describes measuring agreement between simulator behavior and live APIs through repeated probes. [2]
That focus is central to the product’s usefulness. A simulated service can make testing easier while still giving misleading results if it behaves differently in the places an agent relies on. A useful environment needs an explicit account of what is modeled, which differences remain and how a release changes that coverage.
Let actions change state, then reset it
Rystic’s product description emphasizes stateful calls and seeded worlds that can run in a development or testing environment. An agent can create an object and encounter the consequences in later calls, rather than receive a series of unrelated canned responses. [1]
The practical benefit is a consistent starting point for each attempt. A test can ask whether an agent found the right record, changed the intended field and avoided unrelated actions. Resetting the environment lets another model or prompt attempt the same task against the same initial conditions.
The company describes both API-focused environments and computer-use worlds. These serve related but distinct tests: one exercises calls and responses; the other exercises an agent interacting with websites and visible application state. [2]
A Slack workflow without a real workspace
The Slack simulator documentation describes a seeded synthetic workspace for testing actions such as reading threads, creating channels and replying. It provides API and MCP surfaces with their own documented coverage. Test identities and data belong to the simulated world, rather than a real Slack workspace. [3]
The same guide lists important limitations. Interactive callbacks are not modeled, rate limits are not enabled by default, and some response fields may differ where live examples are unavailable. It describes one workspace per process, with concurrent episodes needing separate processes or containers. [3]
A useful scenario is an agent asked to find a discussion, summarize a decision and post to the right channel. Reviewers can examine which thread it read and where the message appeared, then reset the workspace for another attempt. Passing that scenario would validate behavior within the simulator’s coverage, rather than every possible live Slack interaction.
Synthetic sites for computer-use agents
Rystic’s computer-use offering describes worlds with websites, inboxes, messages, multiple accounts and error states. The environments are designed to preserve changes across a sequence of actions and reset them between attempts. The product page describes sealed environments that do not send requests to the third-party services they represent. [4]
The company illustrates account and cross-site workflows using synthetic services. These are training and evaluation scenarios, not instructions to create or alter real accounts. Because the world records state, a test can examine whether the task’s intended change actually happened instead of relying only on an agent’s completion message. [4]
This is useful for a team developing a computer-use workflow that can fail several steps after its first click. Repeating the same initial state helps separate a model’s behavior from changes in the site or account. It also creates a place to exercise errors that would be inconvenient or risky to reproduce in a live workflow.
Where Rystic fits on SOTA2
A ranked comparison is not yet available for Rystic.
What we would look for in a pilot
We would choose a task whose outcome can be checked from the final state, then verify that the simulator supports every operation it needs. Test successful paths alongside missing data, conflicting records and service errors. Record coverage gaps as gaps in the test, rather than agent failures or successes.
Compare a small set of permitted live-service observations with the corresponding simulator behavior before relying on the suite for release decisions. Confirm how resets, concurrent episodes and any paid failure-injection features work for the chosen environment.
The SOTA2 view
Rystic is relevant to teams building agents that change state across tools or websites. Its useful proposition is a repeatable environment where those actions can be inspected and reset. Simulator fidelity and clear coverage boundaries determine how confidently the resulting tests can inform a live release.