How it works

Mirrors builds a mirror (also called a twin) of your agent’s production environment from its traces, then lets you replay real sessions against any version of the agent — safely, deterministically, and at CI speed.

​

From traces to a runnable world

A mirror is built in three parts from the traces the collector streams (or that you upload):

1. Schema — which entities exist in your agent’s world and how they connect, inferred from the tool calls and results in your traces.
2. Seed — a fabricated dataset that populates the schema. The mirror keeps only the skeleton of the data; every actual value is fabricated, so redacted or anonymized sessions work fine.
3. Tool bindings — each of your agent’s tools is bound to the mirror: database-backed tools hit the seeded database, external APIs are mocked or LLM-simulated, and every binding is scored against the real traces.

The result is an isolated, runnable environment. Your agent runs against it exactly as it would against production — same tools, same shapes of data — but nothing real is touched, so even destructive flows (refunds, deletes, sends) are safe to exercise.

​

Fidelity scoring

Every mirror is scored per tool against the recorded traces: for each tool, how often does the mirror return responses consistent with what production returned? Fidelity tells you which parts of the mirror you can trust and where to invest business context to lift it.

​

Deterministic seeding

The same seed and instructions produce a byte-identical world. That makes replays reproducible: you can rerun the exact session that paged you, on demand, and compare two versions of the agent knowing the environment didn’t move underneath them.

​

Business context and proposals

Traces don’t capture everything — pricing rules, eligibility logic, tone guidelines. You can attach business context (free text, from the dashboard, mirrors context add, or MCP) that the simulation honors, lifting fidelity. Mirrors can also generate proposals — agent-suggested changes to the mirror — which you review and accept to trigger a rebuild.

​

Replays and evals

• Replay — run a recorded session against a new version of the agent and diff the outcome against the baseline.
• Evals — named sets of test cases (auto-generated from your traces or authored by hand) that run against a mirror and score the agent’s behavior. Eval sets are what the CI gate runs on every pull request.
• Playground — an interactive console in the dashboard for querying and chatting with a mirror.

​

The surfaces

Everything above is reachable four ways, with full parity: