How rote turns successful agent runs into reusable Plays.

Deterministic flow crystallization is the process that turns a successful agent run into a reusable Play.

rote records the tools, inputs, checks, corrections, and order that produced the result. It removes failed paths and finds the reusable method.

The Play uses this method again with fresh inputs. The path stays the same, but the result can change.

Temporal runs application code reliably through failures. LangGraph runs long-lived, stateful agents and workflows.

Dagster orchestrates data work. Prefect turns Python functions into flows. Mastra lets developers define agent workflow steps.

These products start with code, a graph, a flow, or defined steps. rote starts with an agent run that already worked.

rote captures the successful method as a Play. A team can also use a Play inside an existing workflow system.

Run the task in a rote workspace. The workspace records each tool call and the data that moves between calls.

Review the successful execution trace. Then ask rote to crystallize the trace.

rote removes failed paths, changes fixed values into inputs, and creates a Play. The Play is the reusable workflow that came from the evidence.

Give the Play URI to a supported agent harness. The Play shows its required inputs before the run starts.

Supply the new values and approve the required access. rote then runs the same method against current systems and current data.

The Play does not return the old answer. It uses the old method to produce a new answer.

An agent harness is the application or command-line tool that runs an agent.

rote works with Claude Code, Codex, Cursor, Kimi, Hermes Agent, and Pi Coding Agent. Other harnesses can use rote through its command-line interface and tools.

The current guided setup supports Claude Code and Codex. The Play remains independent of the harness that first created it.

Yes. Inspection does not run the Play or change data.

The Play card shows the inputs, tools, required access, reads, declared writes, author, owner, and version. It also shows the source and step graph.

Some Plays only read data. Other Plays write data. rote shows the declared effects before you approve the run.

An agent skill gives instructions for a type of work. The agent must interpret those instructions during each run.

A rote Play contains a specific method that already worked. The agent can inspect and execute that method with new inputs.

A skill can help an agent select or create a Play. The Play performs the repeatable part of the work.

The Community plan costs $0. It includes a personal account and one organization for up to five members.

Team costs $99 each month for up to 15 members. Growth costs $299 each month. Business costs $799 each month.

Every public plan includes unlimited public and private Plays. rote does not charge per Play, run, token, or agent.

See the pricing page for annual prices, plan limits, and enterprise options.

The first agent uses reasoning to find a successful tool path. A repeat run does not need to find that path again.

The modiqo/hello test reduced reasoning tokens from 14,900 to 300. This result is 97.99 percent, which the site rounds to 98 percent.

This number comes from one measured example. The reduction for another Play depends on the task and the first run.

Yes. A team can publish a Play to the rote registry and share one Play URI.

Public Plays are available to everyone. Private Plays stay with their owner or organization, subject to member access and policy.

Paid plans add roles, approvals, audit export, identity controls, and longer recovery periods. Each new release keeps a version and an owner.

rote is a method layer for tool-using agents. It records successful work and turns the working method into a Play.

rote can record work across application programming interfaces, local commands, and websites. A Play can use all three types of work.

A Play is a successful method that an agent can inspect and run. It has declared inputs, steps, dependencies, access needs, and expected effects.

Each Play has an owner and a version. One URI lets a person or agent find the Play.

Agents often find useful methods during real work. The result can survive, but the method usually stays in one session.

The next agent must find the tools, order, checks, and corrections again. rote keeps this method for the next run.

A prompt describes what you want an agent to do. A Play contains the tool path that produced a successful result.

Prompts remain useful for goals and judgment. Plays handle repeatable inputs, tool calls, order, checks, effects, and failure rules.

rote saves the method. Each Play run uses new inputs and current tool responses.

The result can change because the input or outside system changed. The reusable method does not depend on the old answer.

No. A recording shows what happened in the past. A Play uses the successful method to produce a new result.

The original execution remains useful evidence. The Play contains the smaller path that another agent can run.

No. Deterministic means that the Play follows a declared tool path and declared checks.

The input and outside data can change. Thus, two runs can use the same method and produce different results.

rote records each real tool call, response, result, time, and dependency. It records the work, not the complete private conversation.

Each recorded item can refer to data from an earlier item. These references show how data moved through the successful run.

rote records three types of work:

• Calls to an application programming interface
• Local commands and file operations
• Browser work on real websites

One execution trace can contain all three types. One Play can also run all three types.

rote reads the successful execution trace. It removes failed paths and keeps the actions that caused the result.

rote changes fixed values into declared inputs. It also records step order, data dependencies, tool identity, effects, and output rules.

The result is a pending Play. The author tests this Play before the author releases a fixed version.

No. The execution trace keeps failed attempts for review. The Play normally excludes failed paths and actions that did not help the result.

rote can keep a failed action when that action is part of the required method. For example, a negative test can prove a safety rule.

No. You can start with a Play URI and inspect the Play card.

The trace format becomes useful when you need to create, repair, test, or review a Play.

rote finds the Play and shows its contract. Then rote checks the inputs, access, tools, and dependencies.

rote runs independent steps at the same time when this action is safe. It runs dependent steps in their required order.

The run ends with an output and a step report. The report shows success, failure, skipped work, and blocked work.

rote stops before the affected work starts. It identifies the missing or invalid input.

rote does not invent a value and continue. The user can supply a valid value and start the run again.

rote names the failed step and keeps its evidence. Steps that depend on the failed step get a blocked state.

Completed steps remain in the run record. A supported resume operation can continue from the incomplete part.

Yes, when the Play author defines that result. The report marks the run as degraded or partial.

An unexpected failure remains a failure. rote does not present a partial result as a complete result.

Yes. A versionless URI finds the latest released version:

https://play.modiqo.ai/[owner]/[name]

A versioned URI finds one fixed version:

https://play.modiqo.ai/[owner]/[name]@[version]

Use a fixed version when exact repeat behavior is important. Use the latest version when you want the owner's current repair and improvements.

Each executed step has a result and evidence. The trace shows the tool call, input, output, time, order, and dependencies.

The final report shows failed, blocked, skipped, and degraded work. It does not replace these states with a confident summary.

No. rote records execution evidence and data dependencies. It does not need a screen recording or a complete chat transcript.

The harness can have separate chat retention rules. Those rules do not change the Play contract.

A Play runs in the runner's environment. It uses the tools and access that the runner authorizes.

The registry stores shared product information, ownership, visibility, and versions. It does not need to proxy every tool call.

No. A Play declares the authentication that it needs. The runner supplies authorized credentials when the Play runs.

A shared Play contains the method. It does not contain another user's password, key, or access token.

The Play contract must declare writes. A risky action can require user approval or an organization policy before the step starts.

rote classifies local commands before execution. It can block a destructive command before the command starts.

Yes. A Play makes its contract and step graph available before execution.

The contract shows the inputs, tools, access, effects, owner, and version. The source shows the declared execution method.

The Play keeps the identity of its external tools. A meaningful change can cause a clear failure instead of a silent result change.

The owner can review the evidence, repair the failed step, test the Play, and release a new version.

Share the Play URI. A URI can travel in chat, documentation, an issue, a repository, or an agent prompt.

The receiver can inspect the Play and run it with different inputs. The receiver uses separate authorized credentials.

A Play handoff includes:

• Declared inputs
• Tool steps
• Step order and data dependencies
• Access requirements
• Declared reads and writes
• Versioned source
• A run report

The handoff carries the method. The receiver does not need a separate explanation of every step.

Yes. Public Plays support broad discovery and sharing. Private Plays stay with the owner or organization that controls access.

A visibility change cannot remove a copy that another user already downloaded. Do not put secrets in Play source.

The expert tests the change and releases a new fixed version. The old version remains available through its versioned URI.

A versionless URI can find the current release. A pinned URI continues to find the selected version.

An expert guides one successful run. rote keeps the choices, corrections, checks, and limits that produced the result.

The Play carries this method to other team members. Each member can use new inputs and separate credentials.

No. rote works with existing agent harnesses and models.

It gives the agent a stable way to reach tools, record execution evidence, and run known methods again.

rote does not require a person to draw the workflow before the work starts. rote first observes real work that succeeds.

Then rote creates the reusable Play from that evidence. A person can inspect and improve the Play before release.

No. rote uses a local-first execution model. The Play runs in the runner's environment and uses the runner's tools.

Teams use hosted services for discovery, ownership, visibility, policy, and retained evidence when they need those services.

Yes. One Play can combine API calls, local commands, file operations, and browser actions.

The Play keeps these actions in one step graph. It also shows the data that moves between the steps.

rote helps engineers, agent operators, service teams, and platform teams that run repeated work against real systems.

These teams need to preserve a working method, inspect agent actions, or give the method to another person.

Choose a useful task that repeats and has a clear result. Start with a task that only reads data when possible.

Good first Plays include:

• A service health check
• A daily operations report
• A usage and cost report
• Evidence collection from several systems
• A setup or environment check

rote can add little value when a task is truly unique. The same is true when the task uses no external tools.

Use rote when the task repeats, has operational effects, or needs a reliable handoff.

No. One person can use rote and the Community plan for free.

Paid controls become useful when a team needs more members, verified ownership, approvals, audit export, identity controls, or longer recovery.

Every public plan includes unlimited public and private Plays. Each plan also includes version history and a recovery period for deleted Plays.

The plan price does not increase because an agent runs more Plays or uses more tokens.

Paid plans add more organization members and more control. These controls can include roles, approvals, audit export, single sign-on, and longer recovery.

The Team plan starts at $99 each month. The pricing page gives all current prices and limits.

One organization is the billing unit. Each organization selects its own plan.

Joining a paid organization does not upgrade a user's other organizations. Personal Plays stay with the person. Organization Plays stay with the organization.

No. A consultant or service engineer can use rote for client work and keep the service revenue.

The client or service team pays only for the Modiqo plan that it selects.

Generated code starts from a description. A Play starts from an execution that reached the required result.

rote keeps the exact tools, values, corrections, checks, and dependencies from that execution. It also makes the method easy to find and inspect.

An agent can still generate code during discovery or repair. rote preserves the method after the agent proves that method.

A company can build it. The company must build more than one script.

The complete system must record work, find data dependencies, create inputs, test effects, manage versions, control access, and support discovery.

An internal system can be the correct choice when the company already needs to own and maintain that complete lifecycle.

The Play handles the known steps. The agent handles the goal, missing information, selection, interpretation, exceptions, and new work.

A stable scheduled task might not need an agent for each run. This result is useful because it removes unnecessary reasoning.

Model Context Protocol (MCP) tools give an agent access to individual operations. They do not automatically preserve the successful multi-step method.

rote can use MCP tools inside a Play. The Play keeps the order, inputs, checks, dependencies, and results that connect those tools.

Observability explains a past run. A rote trace also supports the creation of a method that can run again.

rote changes the successful path into declared inputs, steps, dependencies, effects, and output rules. The result is a versioned Play.

Some work must remain open-ended. Do not create a Play when no stable method exists.

Many specific jobs still contain repeated checks, data collection, or system operations. A team can preserve only those stable parts.

Better models improve discovery, judgment, and repair. They do not remove the need for ownership, versions, access rules, and execution evidence.

A stronger model should not spend reasoning to find a method that the team already proved.

Give this URI to a supported agent harness:

https://play.modiqo.ai/modiqo/hello

Inspect the Play card. Then supply the requested inputs and run the Play. Review the step report after the run.

1. Start a rote workspace.
2. Complete one real task with your agent.
3. Review the successful execution trace.
4. Crystallize the trace into a pending Play.
5. Test successful and failed input cases.
6. Release a fixed version.
7. Share the Play URI.

Read Create your first Play for the complete procedure.

• Read the documentation
• Browse public Plays
• Meet Play authors
• Review pricing
• Read the product story