AgentTwin
Start where a wrong action creates work for someone
Your assistant may read documents, call APIs and update records. Testing the entire assistant at once makes it hard to explain what failed.
Choose one action with a result you can inspect. A useful first candidate is a workflow that creates a ticket and sends a notification. You can say what should exist afterward and what must never happen twice.
This guide is a selection exercise. It does not claim that every agent framework or integration can run in AgentTwin.
Find the smallest complete business action
“Test customer support” is too broad. “Create one ticket for this request and notify this channel” has a beginning and an end.
Write down the input, the callable entry point, the dependency operations and the expected final state. Include a known starting state. Without it, a duplicate record might be leftover data rather than a new bug.
| Candidate | Why it helps or hurts |
|---|---|
| One supported write and one notification | Easy to inspect required effects |
| A read-only formatting function | Better suited to a small unit test |
| An entire production agent with many dependencies | Hard to bound and prepare as a first test |
Choose one failure that would change your decision
Ask which result would make you delay a release. Perhaps a lost response causes a duplicate ticket. Perhaps the workflow reports success without creating the required record.
Pick one condition first. A large list of possible failures is not evidence. A repeatable failure with an unchanged check can help an engineer verify a fix.
Do not invent support for that condition. Check the actual provider operation and fault behavior before investing in setup.
Check the runtime before preparing your source
AgentTwin's current runnable application path targets supported Node.js workflows. The guided own-project path involves reviewed preparation, a local coding agent and Docker. Discovery of a workflow is not proof that it is runnable.
Use provider operations, current status and project setup to assess fit. Unsupported vendor behavior may need another harness or a narrower test boundary.
For an initial product evaluation, the included sample avoids your own project preparation. The direct local sample needs no cloud account or Docker, and retains host filesystem and network access. Review its files before running it.
Define success for the evaluation
Require a clean run, a triggered relevant failure, an understandable mismatch and a repeatable repair check. Record how much preparation and maintenance the test takes.
Do not assume a time saving because the first demo passed. Compare the same task with the harness your team already uses.
Bring a workflow description to the next step
If you have a candidate, discuss its fit. Bring four things: the entry point, dependency operations, starting data shape and the result that must hold.
Ask what preparation is required and what the scope and costs are. If support is uncertain, resolve that uncertainty before sharing source or committing to a rollout.