Before running a reusable agent workflow, identify its exact version, inspect its source and requirements, and define an acceptable result. A published procedure gives you something to review. It does not establish that the procedure fits your access, data, or environment.
Rote by Modiqo turns successful AI agent work into reusable Plays. Inspect the steps, run them with new inputs, and share the method across supported agents.
Pin the procedure you intend to review
A versioned URI identifies the procedure you are reviewing. A versionless URI can resolve to a newer release, so use a pinned version when sharing a review or repeating an approved task.
The public DNS propagation Play provides a concrete example. Inspect its contract with this command:
rote play inspect https://play.modiqo.ai/modiqo/[email protected]Record the publisher and version alongside your task. Inspecting metadata is not an execution test. Review the source and dependencies described in Work with Plays before deciding to run it.
Match the inputs and access to your task
Version 1.1.2 of the DNS Play publishes six steps and four inputs. These are facts from its published contract, not results from an execution performed for this guide.
| Review item | Public DNS example | Decision before running |
|---|---|---|
| Inputs | domain, record_type, expected, and resolvers | Choose the domain and record type you intend to query. Supply expected values only when you know them. |
| Method | Input validation, authoritative discovery, three resolver queries, and a verdict | Check that the source implements the checks your task requires. |
| Network | Authoritative DNS plus Cloudflare, Google, and Quad9 resolvers | Confirm that these network requests are allowed in your environment. |
| Credentials | No service credentials declared | Check the source and local environment for any additional access. |
| Effects | No external writes declared | Review local process and file behavior too. An empty writes field is not proof of isolation. |
| Result | Resolver evidence and a verdict | Decide how unavailable sources or indeterminate answers affect your task. |
A different Play can require different tools even when its purpose sounds similar. The public website readiness Play accepts a URL, a redirect limit, and an optional Lighthouse check. Enabling that check requires the relevant CLI and browser setup. Review the chosen version's requirements rather than borrowing assumptions from the DNS example.
Review effects separately from credentials
Access to an account and permission to change it are separate decisions. Confirm which account the runner uses, what the procedure reads, and which changes the task authorizes.
For a Play that writes data, list the intended targets and changes before execution. Check the applicable approval controls at the point of the write. A declaration in a manifest does not itself prove that every tool or subprocess enforces the same restriction.
Keep secret values out of shared review notes. Record required service names and access scopes instead. Each runner supplies their own access; the sharing guide explains the handoff.
Define success and failure before the run
A completed process does not by itself prove that the task succeeded. Choose checks that inspect the result, including partial results and expected failures.
For DNS, distinguish a confirmed match, a mismatch, and an answer that could not be checked. Decide whether disagreement between resolvers blocks your next action. Missing evidence must remain visible in the result.
Try a bounded case in an environment you can inspect. If the task can change external state, establish how you will verify or reverse that change first. Record the inputs and observed output so another reviewer can understand what you tested.
Keep a review record when teams share a Play
A short review record connects a procedure to the decision to use it. The following fields are a suggested team practice; this table does not claim that Rote automatically maintains your approval process.
| Field | What the reviewer records |
|---|---|
| Procedure | Publisher, pinned URI, and source or revision reviewed |
| Purpose | Task, input boundaries, and permitted environment |
| Access | Required tools, service names, and access scopes; no secrets |
| Effects | Permitted targets and changes, plus applicable approval requirements |
| Validation | Expected result, failure cases, and evidence from the bounded test |
| Ownership | Reviewer, date, and person responsible for future changes |
| Recheck trigger | New Play version, changed permissions, dependency changes, or unexpected output |
A pinned version preserves the procedure's identity. It does not freeze external services or prevent the environment from changing. Recheck the affected assumptions when a dependency, permission, or result changes.
Start with one published procedure
Choose a task from Trending Plays, inspect its pinned contract and source, and write down what would count as success. Then follow Run your first Play with inputs and access you have reviewed.