AgentTwin
A green response is only one observation
A support assistant returns “done.” A test checks that message and passes. But did the assistant save the right ticket? Did it notify the right channel? Did a retry create a second copy?
An assertion is a statement your test requires to be true. Good workflow assertions describe the effects you care about. They turn “it seemed to work” into a result another engineer can inspect.
This is a planning guide. The illustrative checks below are business rules, not copy-and-paste AgentTwin configuration.
Write the business rule first
Choose one action and finish this sentence: “After this request, the system must contain…” Keep it specific enough that two people would agree on pass or fail.
| Vague check | More useful rule |
|---|---|
| Ticket creation succeeded | Exactly one new ticket has this request identifier |
| Slack was called | One message reached the intended channel for that ticket |
| Nothing broke | The unrelated seeded ticket remains unchanged |
An expected count depends on the starting state. If the world already contains five tickets, a total of six may be correct. Distinguish total counts from records created by this action.
Check required and forbidden effects
Positive checks ask whether the intended work happened. Negative checks ask whether something that must not happen occurred.
For example: one requested ticket exists, one associated notification exists, and an unrelated customer record has not changed. These checks expose different bugs. None is a substitute for the others.
Avoid checking volatile details unless they matter to the rule. If exact timestamps affect the outcome, define clock assumptions. If they do not, do not confuse formatting differences with business failures.
Use the same rules when the dependency fails
Run a clean baseline first. Then change one declared condition, such as a supported write losing its response after commit. Keep the required outcomes fixed.
Some workflows intentionally stop or compensate after a failure. In that case, define that scenario's acceptable state in advance. Do not quietly weaken a check after seeing a red run.
AgentTwin's sample walkthrough uses one-ticket and one-notification checks to expose an unsafe retry. Start there to see a concrete result before preparing your own workflow.
Read the mismatch, not just the badge
When a test fails, inspect expected versus actual state, the invoked operation and whether the fault triggered. “Expected one, observed two” gives the engineer a place to investigate. A generic failure label does not.
When it passes, ask what was outside the test. A synthetic notification does not establish actual vendor delivery. A single scenario does not establish safety for every input.
Choose one expensive uncertainty
Start with the effect your team currently checks by hand. If that check can be stated clearly and uses supported operations, it is a useful evaluation candidate.
Discuss your workflow with the entry point, starting data and required result. You can begin with a description rather than customer data. Check runtime status and pricing information before planning adoption.