Email assistants, database agents, support workflows, and billing tools. Pick a task, see what breaks, then inspect the correction.
Six scripted simulations · Synthetic data · No API keys or sign-up
These are recorded SDK runs, regenerated and checked with each build. They demonstrate deliberately introduced bugs, not measured behavior of an AI model or a real service.
The script runs both versions and saves importable before/after reports in a new folder. The first failure is expected. This uses in-memory tools; it does not send emails, move money, or connect to a database.
The script runs both versions and saves importable before/after reports in a new folder. The first failure is expected. This uses in-memory tools; it does not send emails, move money, or connect to a database.
The script runs both versions and saves importable before/after reports in a new folder. The first failure is expected. This uses in-memory tools; it does not send emails, move money, or connect to a database.
The script runs both versions and saves importable before/after reports in a new folder. The first failure is expected. This uses in-memory tools; it does not send emails, move money, or connect to a database.
The script runs both versions and saves importable before/after reports in a new folder. The first failure is expected. This uses in-memory tools; it does not send emails, move money, or connect to a database.
The script runs both versions and saves importable before/after reports in a new folder. The first failure is expected. This uses in-memory tools; it does not send emails, move money, or connect to a database.
Our booking case study uses a model-backed agent against simulated tools. It includes an observed stale-read failure, the prompt change, and the recorded results. It is our own example with a small sample, not independent customer validation.
Replace the reference agent, define your simulated tools, and choose outcomes that matter for your application. A passing demo only establishes the behavior of that fixture.