A twin is a stateful copy of a real tool, built for testing agents. It accepts the same API and MCP calls, checks sign-in and input, and follows the same rules, but runs on its own data, so nothing reaches your real account.
Mailboxes, threads, send and search.
Events, free/busy, invites and 36 tools.
Projects, issues, transitions and JQL.
Channels, threads, users and mentions.
Calls, transcripts and deal context.
Accounts, opportunities and validation.
Teams, issues, states and cycles.
Files, folders, sharing and search.
Contacts, deals, tickets and pipelines.
Repos, issues, pull requests and reviews.
Don’t see the tool your agent uses?
Request a twinPoint your agent’s MCP config at the twin instead of the live tool. Nothing else in your agent changes.
A twin is a stateful copy of a real tool, built for testing agents. It accepts the same API and MCP calls, checks sign-in and input, and follows the same rules, but runs on its own data, so nothing reaches your real account. One call resets it to a known starting point.
Twins of every tool a team uses, filled with the same people, customers and history and connected to each other. A customer in Salesforce also has email threads, Slack messages, Linear issues and Gong calls, so an agent has to work across tools the way it would at work.
A mock returns canned responses with no state or rules. A vendor sandbox is the real product, but it is shared, rate-limited, often needs a paid org per tool, and is slow to reset between runs. A twin behaves like the real tool, is private to your team, and resets in one call.
A report for every scenario: the pass rate against your success criteria, and the full history of every run, with each call, each response and what it changed. The report is yours, so you can fix the agent, compare models or use the runs to train, however you like.
Gmail, Google Calendar, Google Drive, Salesforce, HubSpot, Slack, Jira, Linear, GitHub and Gong. Ask us about the tools only you run.