BLOGAUG 28, 2026 · UPDATED SEP 21, 2026 · 3 MIN READ

Share an agent workflow across coding agents

Send a pinned Play URI and let each runner supply access

Share a Rote Play between Claude Code, Codex, or Cursor. Inspect its version, inputs, tools, and effects while keeping service credentials with each runner.

Modiqo

Share a reusable agent procedure by sending its pinned Play URI and the inputs the recipient should use. The recipient inspects the method and supplies their own access. A public procedure does not give another person access to your private accounts.

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.

Try a public handoff without a private account

The DNS propagation Play is a public example from Trending Plays. Its published contract accepts domain, record_type, expected, and resolvers. It declares no external writes or service credentials.

Set up Rote in both supported agents using the installation guide. The receiving machine also needs the commands and network access declared in the Play source.

In Claude Code, ask the agent to inspect this exact version and explain its requirements:

text
Inspect https://play.modiqo.ai/modiqo/[email protected].
Explain its inputs, dependencies, and declared effects.
Then check example.com with record_type=A if the requirements are met.

In Codex or Cursor, pass the same version with a different input:

text
Inspect https://play.modiqo.ai/modiqo/[email protected].
Explain its inputs, dependencies, and declared effects.
Then check modiqo.ai with record_type=MX if the requirements are met.

The equivalent CLI call makes the inputs explicit:

bash
rote play run https://play.modiqo.ai/modiqo/[email protected] domain=modiqo.ai record_type=MX

These instructions use the published contract. They describe a handoff you can reproduce, not a completed cross-agent benchmark. Compare the resolver results and verdict; the two domains need not produce identical answers.

Share the contract and keep credentials local

Share with the recipientThe recipient supplies
Pinned Play URI and authorPermission to access a private Play, if required
Inputs and expected result shapeTheir own parameter values and permitted data
Declared tools and effectsCompatible tools and approval for required effects
Service names and access requirementsTheir own service credentials

For an authenticated example, inspect the GitHub PR-stack Play. It uses a GitHub adapter. Repository access depends on the receiving runner's credentials and permissions.

Never put credentials in parameter examples, copied traces, or published source. Review the actual procedure and dependencies alongside its declarations before sharing.

A private Play also needs registry access

Public Plays are inspectable through the public registry. Private Plays require the receiving identity to have access. Sharing a URI alone does not grant membership or service permissions.

Follow How the Play travels for publishing, access, and versioning. Use Work with Plays to inspect and pin an existing method.

Handle differences before calling the handoff complete

If a required tool is missing, configure it on the receiving machine. If an API denies access, verify that runner's permissions. If inputs or a service have changed, inspect the error and update the method through a new version when needed.

A pinned version gives both people a common artifact to review. It does not guarantee identical live data or successful execution in every environment.

Start with a procedure your teammate can inspect

Send a Play URI, its version, your intended inputs, and any access requirements. The reuse guide shows what the second run preserves. The comparison guide explains when a skill or workflow also helps.

Use the inspection guide to review a pinned version, its access, and its expected result before running.