AgentTwin
One test cannot answer every question
An agent reads a request, chooses a tool and creates a record. If the result is wrong, the error might be in its decision, the tool's application code or a dependency interaction.
A test boundary names the part you are exercising and the parts you control around it. Clear boundaries make a failed test easier to explain. They also stop a passing result from sounding broader than the evidence.
The examples here are test designs, not results from newly executed runs.
Separate three questions
| Question | Evidence to collect |
|---|---|
| Did the agent choose an appropriate action? | Evaluation of the decision against reviewed criteria |
| Did the application execute the action correctly? | Required and forbidden final effects |
| Does the integration match the real provider? | Appropriate contract and real-service integration checks |
A workflow test can reveal that a retry created two records. That does not establish that the model should have chosen to create a record in the first place.
Likewise, correct behavior against a bounded synthetic API does not prove that every real provider edge case is covered.
Begin with an application entry point
For an outcome test, choose the callable action whose effects you want to inspect. Give it a reviewed input and known starting data. Identify which dependency operations it calls.
Keep a record of what sits outside the boundary. That may include model selection, vendor authentication, actual notification delivery or infrastructure scheduling.
Making those limits visible helps reviewers decide whether additional tests are needed. It is not a reason to discard a useful small test.
Use a twin for the behavior it models
AgentTwin runs supported Node.js workflows against synthetic services with declared conditions and recorded outcomes. Its value in this boundary is making a supported failure and the resulting state inspectable.
Check provider operations before choosing a dependency. The supported Stripe subset, for example, does not imply full refunds, subscriptions or webhook delivery simulation.
Keep real-service tests for the real behaviors that matter to you. The Testcontainers comparison explains why real dependency checks and synthetic workflow tests can serve different purposes.
Change one part at a time
First establish the expected outcome in a clean world. Then introduce one relevant supported condition. Keep the input, baseline and checks steady so the result has a clear explanation.
When repairing the application, preserve the business rule. A broader allowed result can hide the original defect. Record which source and scenario produced each outcome.
Make the boundary useful to your team
Write a short note beside the test: what it exercises, what a pass means and what remains untested. Another engineer should be able to decide where to look next without reading your conversation history.
Try the sample to see a bounded workflow. If you are planning your own, discuss the entry point and dependency boundary before estimating preparation or cost.