After studying this material, you should be able to:
Before learning the solution, you need to understand what makes this problem difficult.
Imagine you are building an AI agent that helps users shop online. You need to:
But real online stores create three major obstacles:
| Obstacle | Why It Matters |
|---|---|
| Constant change | Products go out of stock, prices update, layouts redesign — your test from yesterday may not run today |
| Bot detection | Stores block automated traffic, interrupting your agent mid-task |
| Limited hand-built stores | You can build a fake store manually, but it won't capture the full complexity of real shopping behavior |
Key Insight: You need an environment that is both controllable (like a fake store) and realistic (like a real store). ShopGym is built to solve exactly this tension.
ShopGym takes a live storefront and converts it into a self-contained sandbox — a frozen, resettable copy that agents can interact with repeatedly under identical conditions.
Think of it like this:
Live Store (messy, changing, blocks bots)
↓
ShopGym processes it
↓
Sandbox Store (stable, resettable, agent-friendly)
+
Shopping Tasks (grounded in that store's real products and policies)
ShopGym has two distinct frameworks:
Analogy: ShopArena builds the exam room. ShopGuru writes the exam questions.
ShopArena has two clearly separated phases. Understanding why they are separated is as important as knowing what each does.
ShopArena sends agents to explore the live storefront's key surfaces:
A planner agent divides this exploration into focused tasks. For each task, a fresh specification agent browses the store and writes an anonymized fragment.
These fragments collectively describe three things:
| Fragment Type | What It Captures |
|---|---|
| Design specification | Visual style, layout, overall look and feel |
| Structured attributes | Filters, navigation menus, pagination behavior |
| Catalog statistics | Number of products, price ranges, category distribution |
Critical detail — Anonymization: While writing fragments, agents deliberately omit:
This means the output is a structural description, not a copy of the store. No separate redaction step is needed later.
Finally, a consolidation step merges all fragments into one unified shop specification.
Why separate exploration from generation? The specification acts as the only interface between the two phases. This means generation never touches the original store — making the process cleaner, more auditable, and privacy-respecting.
The generation phase reads only the specification — never the original store data.
Step-by-step generation sequence:
1. Generate fictional product catalog
(collections, names, descriptions, images)
↓
2. Build site shell and homepage
↓
3. Build collection pages
↓
4. Build product pages
↓
5. Build cart functionality
↓
6. Build search and filtering
↓
7. Build policy pages
↓
8. Final integration pass
Each step follows the same execution-verification loop:
Fresh execution agent reads:
→ current code
→ relevant specification
→ catalog data
→ latest feedback report
↓
Agent edits code + runs lightweight checks
↓
Rule-based checks verify:
→ build success
→ required routes exist
→ output structure is correct
↓
Visual verification agent:
→ hosts the shop in a browser
→ inspects it visually
→ writes feedback for next iteration
Why start a fresh agent each iteration? Keeping the working context small prevents the agent from being overwhelmed by accumulated history. The code holds current state, the specification holds intent, and the report describes what to fix next.
Key benefit: If one feature fails, ShopArena repairs just that feature — it does not regenerate the entire shop.
Once the sandbox store exists, ShopGuru creates shopping tasks grounded in that specific store's actual products, navigation, filters, and policies.
Simple/Focused Tasks (rule-based generation):
Multi-step Journey Tasks (LLM-generated):
Task generated
↓
Automated checks verify:
→ Products referenced exist in the shop
→ Collections referenced exist
→ Filter options referenced exist
↓
If checks fail → LLM receives feedback → revises task
Why does grounding matter? A task that references a product that doesn't exist in the sandbox is useless. This verification loop ensures every task is actually solvable.
ShopGym tested quality in two ways across 224 tasks, 6 sandbox shops (3 synthetic, 3 real-data twins).
Researchers mapped both real and synthetic shops as graphs:
Findings:
| Property | Result |
|---|---|
| Number of distinct states | Similar between real and synthetic |
| Page complexity | Comparable |
| Connections between states | Fewer in synthetic (expected — no external links or marketing pages) |
Conclusion: Synthetic shops preserve the core navigational structure of real stores, with minor expected differences.
Two agent evaluation systems tested both live stores and their sandbox twins:
Key findings:
What this means: The twins are not perfect replicas, but they preserve meaningful difficulty signals — especially for complex tasks. An agent that performs well on the sandbox tends to perform well on the live store.
| Approach | Reproducible? | Realistic? |
|---|---|---|
| Live stores | ✗ | ✓ |
| Hand-built fake stores | ✓ | ✗ |
| ShopGym sandboxes | ✓ | ✓ (approximately) |
LIVE STOREFRONT
↓
[ShopArena - Exploration Phase]
Planner agent divides work
Specification agents explore + write anonymized fragments
Consolidation merges fragments into shop specification
↓
[ShopArena - Generation Phase]
Reads specification only (never original store)
Generates fictional catalog
Builds store in fixed sequence with execution-verification loops
↓
SANDBOX STORE
↓
[ShopGuru - Task Generation]
Rule-based generators → simple tasks
LLM → multi-step journey tasks
Automated checks verify task validity
↓
BENCHMARK TASKS
↓
[Evaluation]
Structural graph comparison
Agent behavioral testing on live vs. sandbox