AgentTwin
A red test needs an explanation
You inject a timeout and the workflow fails. Did the timeout expose a retry bug? Or was the entry point wrong, the data missing or the notification check already broken?
A clean baseline runs the same workflow in the same starting world without the injected fault. It gives you a reference for interpreting the next result.
It does not prove production correctness. It establishes that this test setup can satisfy its checks before you change the condition.
Keep the first comparison small
Use one input, a declared starting state and a clear final-state rule. For a ticket workflow, that might mean one ticket and one notification for the request.
| Run | Condition | Question |
|---|---|---|
| Baseline | No injected fault | Can this setup meet the required outcome? |
| Fault trial | One supported failure | Does the outcome still hold when that failure occurs? |
| Repair trial | Same failure, changed application | Did the fix preserve the original requirement? |
Reset between trials. Otherwise the second run may observe the first run's records and fail for an unrelated reason.
Try the bounded example
AgentTwin's generated example includes a clean world and a named timeout-after-write preset. Use the sample walkthrough for the current commands and files.
The direct local sample needs Node.js 24.11 or newer. It does not need Docker or a cloud account. It executes with host filesystem and network access, so inspect the generated files first.
In the example, selecting none disables the injected fault. Selecting timeout-after-write uses the declared preset. The important comparison is the same application and checks with a different fault selection.
Confirm that the fault actually happened
A requested condition might never match an operation. If it did not trigger, a passing result does not demonstrate how the workflow behaves under that condition.
Inspect the receipt alongside the final state. Identify the operation, the triggered condition and the expected-versus-actual checks. If the baseline fails, fix the setup or application before attributing the failure to the injected condition.
Do not change multiple faults, fixtures and checks together. You may get a red result without learning which change caused it.
Preserve the requirement during repair
Suppose the fault trial creates two tickets. The repair should make the same trial satisfy the one-ticket rule. Allowing two tickets merely changes the test's definition of success.
Capture source and scenario identity for each run. Replay of an old run and execution of the current application answer different questions; use both deliberately.
Choose the next useful comparison
After one reliable trial, choose another supported condition based on a real workflow risk. More scenarios are useful when each adds an understandable question.
If preparing the first comparison is the hard part, discuss your workflow. Bring the entry point, required result and the failure you need to reproduce. Check runtime support and costs before planning a larger evaluation.