# Mirrors > Mirrors rebuilds the systems your agents call, then replays real sessions to catch regressions before your users do. ## How it works 1. **Drop in your traces.** A trace export, agent code, tool code, or docs. Or stream sessions straight from production with the collector. 2. **Mirrors builds the environment.** Schema, seed data, and tool behavior mined into a runnable copy of the systems your agent calls, including the internal tools nobody will give you a test instance of. Ready in minutes. 3. **Test every change against it.** Replay past sessions on every pull request. A bad refund or a wrong ticket fails in the environment instead of in front of a customer. ## Questions ### How close is the environment to my real systems? You check it against your own traffic. The Replay screen diffs each recorded production call against its counterpart in the environment, so you can see where the two agree and where they drift before you trust it with a merge gate. Tools rebuilt from real code behave exactly like the real thing; the ones inferred from traces are the ones to read closely. ### Does my production data leave my infrastructure? The environment runs on invented data. Mirrors learns the shape and behavior of your systems from your traces, then fabricates the values it runs against. Replays hit plausible fake records, so a risky prompt or a shared report never exposes a real customer. ### Which frameworks and languages do you support? The collector is two lines of code and instruments LangChain, LangGraph, and the OpenAI and Anthropic SDKs automatically. It ships for Python, TypeScript, and Go, and anything else logs traces through one manual call, or you upload a trace export in the formats agent frameworks and tracing tools write. ### How is this different from LangSmith or Braintrust? They watch and score what your agent already did, in production. Mirrors gives your agent somewhere else to do it: a runnable copy of the systems it calls, including the internal ones nobody will hand you a test instance of. They tell you a refund went wrong. Mirrors is where the wrong refund happens instead. Most teams run both. ### My agent talks to internal systems that have no test environment. Does that work? That is the case Mirrors is built for. It learns each tool from whatever you have (traces, code, or docs), then rebuilds it as a runnable service with its own schema and seed data. No vendor test instance, no staging licence, no ticket to another team, and no production traces required to start. Your agent calls it exactly the way it calls the real thing. ## Pages - [Mirrors | Staging Environments for AI Agents](https://www.runmirrors.com/): Mirrors builds a runnable twin of the systems your AI agents call from their traces, then replays real sessions against every prompt, tool or model change. - [Request Access | Mirrors](https://www.runmirrors.com/request-access): Mirrors is not self-serve: tell us what you are building and what your agent needs to test, and a founder enables your account. - [AI Agent Testing Pricing | Mirrors](https://www.runmirrors.com/pricing): Plans for testing AI agents against twins of their backends: start free, pay as you go, a monthly plan with a replay allowance, or a quoted commitment. - [Contact Mirrors | AI Agent Testing](https://www.runmirrors.com/contact): Talk with a Mirrors founder about safely testing your AI agent against a runnable twin of the systems it calls. - [Privacy & Cookies | Mirrors](https://www.runmirrors.com/privacy): How Mirrors handles your data: what we collect on this site, what happens to the traces and files you send us, who else processes them, and for how long. - [Terms of Service | Mirrors](https://www.runmirrors.com/terms): The agreement for using Mirrors: what the service does, what your content and our fees are, how either side ends it, and the limits on what we promise. - [Glossary | Mirrors](https://www.runmirrors.com/glossary): The words the product uses, one page each, with how each is measured or built. - [Mirror | Mirrors](https://www.runmirrors.com/glossary/mirror): A mirror is a runnable twin of the backend an AI agent talks to, built from its production traces. - [Twin | Mirrors](https://www.runmirrors.com/glossary/twin): The twin is the running process that answers an agent's tool calls the way the recorded backend did. - [Trace conformance | Mirrors](https://www.runmirrors.com/glossary/trace-conformance): The headline fidelity number: the share of replayed conversations the twin answered as production did. - [Binding rung | Mirrors](https://www.runmirrors.com/glossary/binding-rung): The rung is where a tool's answers come from: provided, custom, workspace, sink, world, synthesized, or simulated. - [Drift | Mirrors](https://www.runmirrors.com/glossary/drift): Drift is a tool whose answers moved away from what production recorded, named by kind and paired with the lever that fixes it. - [Comparisons | Mirrors](https://www.runmirrors.com/vs): How a mirror compares with the other ways to test an agent. - [Mirrors vs mirrord | Mirrors](https://www.runmirrors.com/vs/mirrord-comparison): mirrord routes a local process into a live cluster; a mirror replaces the backend with a twin built from traces. - [Mirrors vs hand-written mocks | Mirrors](https://www.runmirrors.com/vs/hand-written-mocks): Mocks are written by people and go stale; a mirror is rebuilt from the traces the agent keeps producing. - [Mirrors vs record and replay | Mirrors](https://www.runmirrors.com/vs/record-and-replay): Replay returns the recorded answer to the recorded call; a mirror answers new calls from a world model. - [Mirrors vs staging environments | Mirrors](https://www.runmirrors.com/vs/staging-environments): Staging is shared, slow to reset and expensive to keep close to production; a twin starts in seconds and is seeded per session. - [Mirrors vs prompted simulators | Mirrors](https://www.runmirrors.com/vs/llm-simulators): A prompted simulator invents plausible answers; a mirror binds each tool as high on the evidence ladder as it can and simulates only what is left. - [Mirrors vs contract tests | Mirrors](https://www.runmirrors.com/vs/contract-tests): Contract tests check shapes; a mirror checks behaviour across a whole conversation. - [Alternatives | Mirrors](https://www.runmirrors.com/alternatives): The options teams weigh when they need a backend an agent can act on, laid out plainly. - [Alternatives for testing agents | Mirrors](https://www.runmirrors.com/alternatives/agent-testing-tools): The ways teams test agents against their backends, and where a mirror fits. - [Alternatives for sandbox backends | Mirrors](https://www.runmirrors.com/alternatives/sandbox-backends): How to give an agent a backend it can act on without touching production. - [Use cases | Mirrors](https://www.runmirrors.com/use-cases): What people build mirrors for: checks before a merge, prompt changes, new tools, demos. - [Pre-merge checks for agents | Mirrors](https://www.runmirrors.com/use-cases/pre-merge-checks): Run an agent's recorded conversations against a twin before a prompt or tool change merges. - [Trying prompt changes safely | Mirrors](https://www.runmirrors.com/use-cases/prompt-changes): Compare an agent's decisions before and after a prompt change on the same seeded world. - [Adding a tool | Mirrors](https://www.runmirrors.com/use-cases/new-tools): Give a new tool a twin-side implementation before the real backend exists. - [Demo environments | Mirrors](https://www.runmirrors.com/use-cases/demo-environments): A twin seeded with a scenario is a demo backend that never runs out of state. - [Tracking regressions over time | Mirrors](https://www.runmirrors.com/use-cases/regression-tracking): Each build reports drift per tool; the builds screen shows what changed between two builds. ## Documentation - [Docs](https://www.runmirrors.com/docs): quickstart, collectors, the MCP server, the CLI and the API reference. - [llms-full.txt](https://www.runmirrors.com/llms-full.txt): the reference pages in full.