AgentTwinCompare the question each test answers
A valid response can still be followed by an unsafe retry. Start by deciding whether you need to verify an API agreement or the state left by a sequence of actions.
| Question | Pact | AgentTwin |
|---|---|---|
| What is the main check? | A consumer and provider agree on HTTP requests/responses or message contents. | A prepared Node workflow meets declared assertions against recorded service state. |
| What do you prepare? | Consumer interactions and provider verification, including required provider states. | Application files, a world specification, synthetic starting data and outcome checks. |
| How is state used? | Provider states establish the preconditions for individual interactions. | Fixtures establish the starting state for a run; assertions inspect supported effects. |
| What is the failure example here? | An API change violates a consumer's expectations. | A write succeeds, its response times out, and a retry creates a duplicate record. |
| What does a passing test establish? | The verified interactions satisfy the contract. | The exercised workflow satisfies its declared checks in that test world. |
The Pact column follows its introduction and consumer/provider verification model. AgentTwin's boundaries are described in its operation contracts and evidence guide. Neither result proves every production interaction will succeed.
When to pick each
Pick Pact when an API agreement is your main risk. It is particularly useful when consumer and provider teams can collaborate on verification. Pact's own selection guide explains why control over both sides and provider data matters. An integration with a third-party API still needs a plan for verifying that provider.
Pick AgentTwin when you can state a workflow outcome. For example: creating a support request must leave one ticket and one notification, including after a supported lost-response fault. You must supply a runnable Node entry point and supported service behavior; discovery does not create those guarantees automatically.
Use both when both risks matter. Verify the consumer/provider agreement with Pact, then exercise your application's retry behavior in a separately prepared workflow test. This is a testing strategy, not a built-in Pact-to-AgentTwin integration.
A runnable workflow example
The included AgentTwin example uses a synthetic HTTP ticket collection and a bounded Slack adapter. It runs locally without Docker or cloud credentials. Node.js 22.12 or newer is required; review the generated source before executing it because local execution retains host filesystem and network access.
npx agenttwin example --out ./agenttwin-example
npx agenttwin run --file ./agenttwin-example/agenttwin.world.json --runtime local --seed 00000000000000000000000000000001 --json
npx agenttwin run --file ./agenttwin-example/agenttwin.world.json --runtime local --fault timeout-after-write --seed 00000000000000000000000000000001 --json
On October 24, 2026, we ran the repository's CLI 0.3.14 using npx --no-install with a local source launcher. These are selected, unchanged fields from the faulted command's JSON output; other receipt fields are omitted:
{
"status": "failed",
"runtime": "local",
"assertions": [
{
"service": "crm",
"path": "/tickets",
"count": 1,
"actual": 2,
"passed": false
},
{
"service": "slack",
"path": "/messages",
"where": { "channel": "C_SUPPORT" },
"count": 1,
"actual": 1,
"passed": true
}
]
}
The clean run passed with one ticket and one message. The faulted run exited with code 1 because the retry produced two tickets. Setting const safe = true in the generated workflow.mjs enabled its stable idempotency key; rerunning the same fault passed with one ticket and one message. The specification digest stayed unchanged and the application-source digest changed. These observations cover this synthetic example, not a production integration or a Pact benchmark.
Boundaries to check before adopting
AgentTwin accepts timeout-after-write, blackhole, server-error and duplicate-write as fault types. Applicability depends on the selected operation, and an untriggered fault is not evidence of a successful failure test. Review the supported operation contract before preparing a workflow.
Local HTTP execution is the default. PostgreSQL and Redis worlds require a configured cloud runtime. Subscription pricing is not publicly listed; E2B usage is billed to the E2B account configured by you or your API operator. See access and costs.
Frequently asked questions
Does AgentTwin replace Pact?
Use the test that answers your question. AgentTwin's recorded workflow outcomes do not verify that a real provider satisfies a Pact contract.
Can Pact describe pre-existing provider state?
Yes. Provider states establish the data needed for an interaction. Pact's documentation treats interactions independently rather than assuming an earlier interaction already ran.
Does a passing contract check prove retries are safe?
A contract result alone does not establish your final record count. Add an explicit check for the business effect you need to preserve.
Does connecting a repository create a runnable AgentTwin test?
No. Discovery identifies clues and candidates; you still prepare the Node workflow, fixtures, supported operations and assertions.
What should I try first?
Follow the quickstart, then choose one outcome in your own workflow that you can check without production data.
Sources and next steps
Competitor documentation reviewed October 24, 2026: Pact introduction, how Pact works, and when to use Pact. This comparison uses documentation review; we did not run a head-to-head competitor benchmark.
Read the AgentTwin documentation and CLI reference, compare AgentTwin with Mockoon, or explore Keploy alternatives.