Skip to main content
reticle_session manages the boundary between the agent and the human watching: hand control back, end the session, narrate what you are doing, and drain the bugs they pinned on elements. reticle_feedback is how you tell the Reticle maintainers that Reticle itself got something wrong. Neither tool touches your app, and neither produces a verdict.

reticle_session

The presenter panel in your app shows a live transcript of what the agent is doing. It reads “live” until the agent says otherwise. So an agent that wanders off without a word leaves a panel claiming work is in progress forever.
review returns a real reading rather than a silent empty:
Reticle nudges you about all of this. Every response on a long-running session carries a reminder:
And each lease carries the rule in the payload itself:
yield when you are pausing and might come back. end when you are finished. Both revive on your next action, so neither is destructive. The difference is what the human watching the panel is told.

reticle_feedback

Reticle is built for agents, which creates an unusual problem: the primary user’s experience vanishes the moment its context does. If an agent hits a gap and works around it silently, nobody ever learns the gap existed.
experience is the only kind here that is not a complaint, and that is why it exists. Every other row grows the corpus into a defect list, which says nothing about which parts are worth protecting when we change them. File it unprompted, when you actually notice it, and name the concrete moment: which call, what it saved you, what you would have done instead. The rating is secondary to that text on purpose. A score produced because something asked for one is indistinguishable from a score that was earned, and once both sit in the same column neither means anything. The text is the part that can be acted on or quoted.

It will tell you when it cannot send

Feedback is not fire-and-forget, and it does not pretend to succeed:
redacted names anything stripped from your report before it left the machine, so you can see what was and was not sent. context is the environment attached automatically, which is why a useful report costs one call and no boilerplate. That is a real response, captured while writing these docs. The instruction in note is the important part: when the report cannot be delivered, say so in your answer to the human rather than letting the finding evaporate.

From the shell, when the tools are unreachable

The setup that failed to finish is exactly the setup that most needs reporting, and in that state the MCP tools do not exist:
Report defects in Reticle. A bug you find in the app under test is Reticle working correctly, and belongs in your answer to the user. Not in a bug report to us. We get a surprising number of those, and each one is quietly a compliment.
Last modified on September 18, 2026