A digital twin of an app is a working replica of an app category — its data, business rules, screens and tools — built so AI agents can practise real work safely. It resets to an exact state, can be seeded into variants, and lets a verifier inspect the database afterwards, so an agent can place an order or move money with no real side effects.
The term comes from engineering, where a digital twin mirrors a physical machine. For AI agents the idea is narrower and more practical: the twin is the place an agent learns and is graded, the way a flight simulator is where a pilot trains.
What does a digital twin of an app contain?
A useful twin copies how the app behaves, not how it looks. The table uses Coinpurse, Sandworld’s twin of a peer-to-peer payments wallet, as the example.
| Layer | What it is | In Coinpurse |
|---|---|---|
| Data | Realistic records the agent has to read and reason about | A balance, contacts with look-alike names, past payments, open money requests |
| Business rules | The logic that decides what is allowed | A real daily send limit, card disputes, subscriptions that can be paused or cancelled |
| Edge cases | The situations that trip agents up | A duplicate request, a scam request and a genuine double charge on the card |
| Tools | Typed functions an agent calls, the same ones the screens use | Send, request, split a bill, dispute a charge, look up a contact |
| Screens | A user interface for people and computer-use agents | A phone-sized wallet app with home, activity, requests and people tabs |
| Reset and seeds | A way back to an exact starting state, and controlled variation | Each seed rebuilds the same wallet; another seed changes the details |
Because the agent acts only through tools, every action is logged. That log, plus the final state, is what a verifier checks.
How is it different from an industrial digital twin?
An industrial digital twin is linked to a real asset — a turbine, a factory line — and updated from its sensors, so engineers can monitor and predict it. An app twin for AI agents has no live link to anything. It is a self-contained copy of how a category of software works, designed to be reset, varied and graded thousands of times. Its value is in being predictable, not in tracking the real thing.
Why train agents on twins instead of real apps?
- Real apps can’t be reset. Reinforcement learning needs the same starting state on every run; a live account drifts with every action.
- Real apps have real side effects. An agent that books the wrong flight in a live airline app has booked a flight.
- Real apps change without notice. A redesign silently breaks tasks and makes results incomparable over time.
- Real apps hide their state. A grader can only see what the screen shows; a twin’s verifier can read the database and prove what happened.
- Real apps rate-limit and block automation. Training needs thousands of parallel episodes.
What makes a twin good enough to train on?
Fidelity where it matters: the rules and edge cases agents get wrong, not pixel-perfect styling. Skyfare, Sandworld’s airline twin, models a ten-day schedule of 380 flights across eleven airports, fare rules for changes and refunds, the 24-hour rule and check-in windows, because those are where booking agents fail. Then the tasks built on the twin have to be gradeable: each needs a verifier that a reference solution passes on every seed and that agents doing nothing, acting at random or stopping early all fail. Sandworld publishes that check, its verifier QA, for every task.
How do you build a digital twin of an app?
- Start from how the app works. An OpenAPI description of the real app’s API gives the resources and operations; Sandworld’s scaffold turns one into a working twin to build on (see the environment spec).
- Write the business rules. Limits, windows, fees and permissions, with the edge cases a real user meets.
- Seed realistic data. Generated from a seed, so every run is reproducible and variants are cheap.
- Write tasks and verifiers together. A user request, the policy the agent must follow, and code that checks the outcome.
- Attack every verifier before it ships. Reference, do-nothing, random and early-stop agents, plus checks for changes nobody asked for.
To see one, open a world and play a task yourself, or read what an RL environment is for the reset-step-verify loop agents run inside it.