Seeded environment
A seeded environment is a test environment populated with fabricated data that keeps the shape of the real thing: the same schema, the same relationships, the same distributions and edge cases, with invented values. Nothing in it is a real customer record, so it can be shared, reset, and replayed against freely.
Last updated 2 August 2026
What “real shape” means in practice
- The schema exactly: same tables, fields, types, and constraints, so a query that works against production works here.
- Referential integrity: every order belongs to a customer who exists, every line item to an order.
- Formats that code parses: ids shaped like your ids, plus currencies, timezones, and address and phone formats.
- Cardinality that is not uniform: most customers with one order, a few with hundreds, because an agent that paginates has to meet a case that paginates.
- The awkward rows: the already-refunded order, the closed account, the duplicate email, the null nobody expected. Those are what an agent gets wrong.
What is deliberately not preserved is any value that identifies a person or a business. The name, the email, the amount, and the free-text note are invented.
Why not a copy of production
It is the obvious answer and usually the wrong one. A production dump carries real customer data into a place with weaker controls, which turns a test environment into an incident waiting to be reported and a question you now have to answer in every security review.
It is also large, expensive to reset, stale within a week, and, most importantly, limited to situations that have already happened. The case you most want to test is often the one that has not.
Why not random fake data either
The opposite failure is a generator that fills the columns with plausible nonsense. Rows exist, so the environment looks populated, but the joins do not line up and the filters return nothing. The agent asks for a customer’s recent orders, gets an empty list, and correctly reports that there are none. The test passes and has proved nothing.
Empty results are the single most common way a seeded environment lies to you, and they are invisible in a green build. When a replay suddenly gets much shorter, suspect the seed before you suspect the agent.
Seeding, anonymization, and synthetic data
| Approach | Where the data comes from | Main risk |
|---|---|---|
| Seeding | Generated from the schema and observed behavior; every value invented | Missing a real-world case nobody described |
| Anonymization or masking | Production rows with the identifiers replaced | Re-identification, and the rows are still personal data under most privacy regimes |
| Statistical synthetic data | A model fitted to production, then sampled | Fits the distribution and can still reproduce a memorized outlier |
| Fixtures | Written by hand for one specific test | Precise and tiny; nothing else in the system is populated |
The words are used loosely in the wild, and “synthetic” gets applied to all four. Ask which one someone means before agreeing that it is safe to share.
Determinism is the other half
A seed is only useful for replay if every run starts from the same state. If a run mutates the data, the next run begins somewhere else, and a comparison between the two measures the leftovers as much as the change. So a seed is a fixed starting point that can be restored, not a one-off load.
In Mirrors
Mirrors builds the seed from whatever you already have: traces, tool code, or docs. It reads the shape of the entities and how they relate, then fabricates the values. That is why a replay works on redacted traces, and why building an environment needs no production access.
Related terms
- Agent staging environment: A non-production copy of the systems an agent calls, so its actions land on fabricated data.
- Tool-call drift: The gap between the tool calls in a recording and the calls a replay makes after a change.