Failure testing · free engine + paid engineering
Ship the workflow.
Keep the proof.
Delegate failure-test setup and CI integration for one customer-facing workflow. Get a repeatable suite your team owns, with readable evidence for release reviews and client handover—not another testing tool to integrate yourself.
Your team delivers.
The checks stay with you.
For teams shipping customer-facing agents, integrations and backend workflows: delegate this bounded engineering task instead of adding test-harness work to your delivery backlog.
Delegate the setup
I wire one agreed workflow to synthetic dependency fixtures and CI, with five failure cases selected together.
Check actual outcomes
Independent checks inspect your isolated application or destination state—not just a successful tool response or simulator counter.
Keep release evidence
Your team gets editable tests, readable results and maintenance instructions to rerun through client handover and later changes.
The refund happened.
The response didn’t.
One lost response. Two very different outcomes.
- 1Refund requestedThe agent calls the refund tool.
- 2Refund committedThe simulated effect is recorded.
- 3Response lostThe agent cannot tell if it worked.
- 4Agent retriesIt issues the refund again without verification.
- 5Duplicate refund detectedThe assertion fails the test.
Illustrative scenario, not a live execution. Recorded fixture results from 23 August 2026; these are simulated effects, not real refunds. Inspect the evidence.
Check the consequence.
Then gate the release.
A success message—or a clean-looking log—cannot prove that a side effect happened only once. The fixture checks the simulator’s observed effects independently of what the application prints.
What failed
The tool committed the refund, then its response was lost. Retrying without checking committed state can produce a second refund.
What the test checks
exactly_once_effect checks that the declared refund committed once. A separate assertion checks verification before an ambiguous retry.
What blocks CI
InfernoSIM returns a non-zero exit when an assertion fails, replay diverges, the application fails, or the selected fault is not reached. JUnit, SARIF and HTML reports explain the result.
For this published fixture, corrected behavior verifies the committed refund and avoids a duplicate. It passed 20 / 20 response-lost runs. This demonstrates the fixture and reference loop, not universal agent safety. Read the assertions.
Three ways to turn
failure into a test.
Reproduce a backend incident
Bring the dependency behavior that triggered an incident into an isolated test environment.
Capture and sanitize traffic. Replay recorded responses. Inject dependency latency, timeouts, resets and status failures against an isolated application.
Follow the incident-to-test guideCatch API and integration regressions
Keep a useful regression test as requests and integrations evolve.
Use semantic matching and stateful scenarios, check OpenAPI contract drift, and generate editable Testcontainers, Compose or GitHub Actions harnesses with CI reports.
Explore contract checksTest agent reliability
Check tool consequences under ambiguous outcomes and defective monitors.
Exercise duplicate side effects, approval checks, monitor faults, recovery and explicit parallel-call schedules. Replay recorded model and tool protocols to make the configured cases repeatable.
Explore safety and recoveryStart with the engine.
Operate it where you need.
The open-source engine is free and useful on its own. Azure editions add operation and governance inside your organization’s AKS cluster.
Open source
Capture, replay, simulate dependencies, test contracts and agent behavior, and generate CI evidence locally. MIT licensed.
Start locallyInfernoSIM Azure
Run one-off and scheduled jobs with customer-owned identity, inputs and evidence. Add Enterprise governance when your deployment needs it.
Compare Azure plansMarketplace certification in progress.