An agent makes the same mistake for the third time. The team can see the problem in its traces, but adding another paragraph to the global prompt may change every conversation, including ones that were working. The useful fix may be a small piece of guidance that belongs in one particular situation.
Mirrors is building a way to deliver that guidance when its conditions match. Teams inspect recorded sessions, write a correction and preview where it will apply before activation. Once the integration is deployed, eligible context changes can reach later agent turns without an application redeploy. [1]
A product focused on the next recurring mistake
Mirrors joined YC’s Fall 2026 batch. Its public YC profile lists Aryan Singhal as co-founder and CEO and describes a product for improving agent behavior using experience from previous interactions. [2]
The important unit of work is a recurring situation. A team needs to connect an observed failure with a change it understands, then find out whether that change helps future sessions. That is a more specific task than collecting additional logs or continually expanding a general instruction.
The application keeps control of the agent
The documentation describes capturing conversation traces in the background, investigating failures and retrieving relevant context at each user turn. The application appends that context before its normal model call. It continues to own tools, streaming, cancellation and the model interaction. [3]
When optional context is unavailable, or no correction matches, the SDK returns empty context so the application can use its original prompt. The docs distinguish active delivery from shadow and off modes. This lets a team evaluate the integration before enabling its effect on live conversations. [3]
That division matters operationally. The team still owns what its agent does. Mirrors supplies a mechanism for reviewing and delivering guidance, while the application decides how that guidance enters the conversation. A successful delivery is therefore one part of the evidence, rather than proof that the task succeeded.
Preview the situations a correction will reach
Mirrors’s correction guide starts with a concrete failure and asks the author to specify both the guidance and the situation in which it belongs. The team saves a draft, previews matches against recorded runs and examines exclusions and conflicts before activation. Editing the draft invalidates its earlier preview. [4]
The guide uses a missing field in a tool response as an example: an agent may need a particular interpretation when the field is absent, but the same instruction should not alter conversations where the field is present. Nearby cases are therefore useful evidence when deciding how narrowly to scope the correction. [4]
The distinction between a preview and an outcome test is important. A preview establishes where a trigger matches stored evidence. It does not establish that the model will produce a better answer after receiving the guidance. That requires examining actual behavior on representative cases. [4]
A missed check in a policy workflow
The public product demonstration shows a policy agent adding a driver and changing coverage while missing a license check. The session view brings the recorded actions together with the team’s checks, making the missed step visible. It is an illustrative product example, not an insurer’s reported customer incident. [1]
A focused correction in a workflow like this could remind the agent of the required check at the point where the situation arises. The team would still need to test cases where the check has already happened, where it cannot be completed and where the user requested something different. Those distinctions protect a narrow fix from becoming a new general mistake.
That is also the useful operating rhythm for a support or service team: identify a repeatable problem, examine the surrounding cases, publish reviewed guidance and compare the outcomes. The work remains specific enough for an owner to explain what changed and why.
Where Mirrors fits on SOTA2
A ranked comparison is not yet available for Mirrors.
What we would look for in a pilot
We would select one recurring mistake and establish a baseline from reviewed sessions. Preview the proposed correction against both affected and neighboring cases, then use limited delivery to compare task outcomes. Measure successful context delivery, whether the application used it, and whether the agent completed the task separately.
Check added turn latency, behavior when context is unavailable and the process for deactivating a correction. Give someone responsibility for reviewing overlapping guidance as the library grows.
The SOTA2 view
Mirrors is relevant to teams that understand a recurring agent problem but need a controlled way to apply the lesson. Its useful idea is situational guidance backed by session evidence and a review step. The test is whether a narrow correction improves future work without disturbing the cases around it.