Skip to main content
reticle_act_sequence is not advertised. The default surface is the merged nine, so an agent does not see this name. Call reticle_act { steps: [...] } instead: the same call, routed on the steps array. Everything below describes what that call does; only the spelling changed. A call to the old name is answered with the new one, but an allowedTools allowlist or an MCP permission rule naming it refuses before Reticle is asked.
reticle_act_sequence runs several actions in order in a single round trip. Reach for it whenever a journey needs more than one step, such as fill, fill, submit, and then prove the outcome once with reticle_act_and_wait, because a sequence itself produces no verdict. A login is three actions. Driving it one call at a time costs three round trips and three turns of context. reticle_act_sequence does it in one. This tool exists because of a measured problem: agents were driving forms one call at a time, over and over. Those repeats were not retries. The calls succeeded and got repeated, because the batching tool was not advertised and so nobody knew it was there.

​
Example

Steps may also name a target instead of a ref, the same locator reticle_act takes. The sequence resolves each one before dispatch, so a login does not need a query round trip per field:
Real response. Each effects[] entry also carries targetMatched, visible, enabled, defaultPrevented, occluded, occludedBy and scrolledIntoView, and each steps[] entry also carries dispatched, settled, settleReason, component, role and name. Those are trimmed here for length:

​
Read that response again

ok: true. count: 3. Every step dispatched. And the login failed, look at appeared:
That password was wrong. The app rejected it. And this tool still reported ok: true, correctly, because ok means the three actions were dispatched, which they were.
This is the whole reason act and act_sequence do not produce verdicts. ok: true is a statement about the input, not about the outcome. Follow a sequence with reticle_act_and_wait on the final step, or with an reticle_assert, or you have proved nothing.
The honest pattern is: batch the setup, prove the outcome.
then
which returns the verdict the sequence could not:
Two calls instead of four, and the last one returns a verdict. Note grade: "signal", the strongest Reticle awards, because the app said so itself.

​
What each step reports

Every step comes back with the same effect fields as reticle_act: valueChanged, focusMoved, domMutatedWithin, occluded. Plus its testid, component and source. When a sequence goes wrong, that per-step detail tells you which step, and which line of which file.
Steps run in order and do not stop on a soft failure, because “the field rejected the value” is not an exception. It’s a result you need to see. Read effects[] rather than assuming ok: true means all three did what you wanted.
Last modified on September 18, 2026