A successful AI agent run becomes a reusable procedure in five steps. A layer beneath the agent records the trace, extracts the steps that worked, packages them with typed inputs, validates the package, and versions it. Rote is that layer. Rote turns a successful agent run into an inspectable, repeatable Play that can travel across harnesses, models, machines, and teams.
The reason to care is cost. In one measured run, an agent needed about 15,000 tokens and 40 seconds to find a working path through an API. Replaying the Play built from that run took about 300 tokens and 2 seconds. The harness keeps none of the path, so without a procedure layer the next run pays the full price again.
What is a reusable agent procedure?
A reusable agent procedure is a recorded method that a different agent can execute with fresh inputs and get the same shape of result. A prompt does not qualify, because a model reads and re-interprets a prompt each time. A transcript does not qualify, because a transcript describes work and cannot do it.
In Rote the procedure is called a Play. A Play declares its inputs, the steps it runs, the services it touches, the writes it may perform, and the credentials it needs by name. A person can read all of that before anything runs.
A Play is a parameterized replay of a recorded step graph. It is not a generalization of the method. It runs the steps that ran, with new inputs, and stops where the world differs from the recording.
The five steps from run to procedure
Every procedure layer performs some version of the same five steps. The table shows each step and what it produces in Rote.
| Step | What happens | What Rote produces |
|---|---|---|
| Record | Every API call, browser step, and shell command lands in one workspace as a reference: @1, @2, @3. | A trace whose references form a dataflow graph, when every step ran through Rote |
| Extract | Failed attempts and dead ends drop out. Steps whose outputs fed later steps stay; the agent decides the rest. | The successful step graph |
| Package | Hardcoded values become typed parameters. Dependencies between steps are resolved. | A Play with declared inputs and effects |
| Validate | The Play runs against the live API contract. A fingerprint of that contract is embedded. | A run receipt and a drift detector |
| Version | The Play gets a URI. Later releases get new versions; older ones stay pinned. | https://play.modiqo.ai/<owner>/<name>@<version> |
The order matters: extraction before packaging means the parameters come from steps that worked, not from guesses. Validation before versioning means a version is a checked claim, not a label.
From inside your harness, the five steps are two commands
You do not run the five steps by hand. The Play sidekick runs them from inside Claude Code, Codex, Cursor, Kimi, Hermes, OpenCode, or DeepSeek Harness. Before work starts, ask for the outcome and let the sidekick search for an existing Play first:
$play explore pull last week's failed deploys and post a summaryIf no Play fits, the sidekick opens a Rote workspace and hands the work to the agent. Rote records every call the agent makes from that point. When the result is verified, close the loop with the handle the sidekick gave you before work started:
$play settle cap_7f3k9m2p4q8r1s6t deployed staging and posted the summaryThe sidekick checks the recorded trace, crystallizes it, and asks whether the Play stays private to your organization or goes public. In Claude Code the prefix is /play; in Kimi it is /skill:play.
Recording has to come first, and it has to be free
You cannot extract a procedure from work you did not record. Rote records at no extra cost because the agent reaches every API, browser page, and shell command through it. There is no instrumentation to add.
Rote stores each result outside the model's context window and addresses it by reference. The agent asks for the field it needs, for example rote @1 '.repos[0].id', instead of pasting the whole response into the conversation. A trace built from references is a graph of which output fed which input. That graph is the program.
Extraction is the hardest step, and success alone does not decide it
An agent's first run through a task includes wrong turns, and extraction removes them. It does not ask a model to describe what happened. It keeps the calls that succeeded and drops the ones that failed. That part is mechanical.
Success does not reveal three other things. It does not say which surviving calls were necessary. It does not say which literal values should become parameters. And it does not say what hidden state the run leaned on. That state might be a browser already logged in, a file from an earlier step, or a variable in the shell.
Rote answers the first with the reference edges, because a step nothing consumed is a candidate to drop. It answers the second with a hardcode detector that finds literals but cannot know which are inputs. The agent decides, and the test runs in the next step catch what it got wrong. Declared dependencies answer the third; anything undeclared is a run that will not reproduce.
The compile step itself is deterministic: the same trace with the same decisions produces the same Play. The trace is not. It is a record of one environment on one day, which is why validation and versioning exist.
Packaging adds parameters and a contract
A recorded run is specific: one repository, one month, one account. Packaging replaces those values with typed parameters so the next runner can supply their own. It also writes down the read/write contract: which services the Play reads, which it may write to, and which credentials it needs by name. The credentials themselves never enter the Play.
Validation happens before anyone else runs it
A Play carries a fingerprint of the API contract it was built against. When the API changes, the fingerprint no longer matches and the Play stops instead of guessing. The fingerprint covers APIs only. Browser steps and shell commands have no contract to hash. For those the Play records preconditions, such as a page reaching a ready state or a command being present, and checks them before running.
When a run stops, the harness examines the failure. The agent re-adapts to the changed environment, and the new working path is pushed as a new version of the same Play URI. Recall stops when reality moves; the repair is a version, not a patch to the old one.
Versioning is what makes the procedure shareable
A Play travels as a URI. Releasing and pushing are two commands, so nothing becomes public by accident:
rote play release failed-deploys-summary
rote registry play push ./failed-deploys-summary acmeAn unversioned URI resolves to the latest release, and @version pins one immutable release. A teammate can inspect it, run it with their own credentials, or schedule it. Because the runner supplies the credentials, publishing a method never publishes a secret.
The smallest example is the public Hello Play. Inspect it first, then run it:
rote play inspect https://play.modiqo.ai/modiqo/hello
rote play run https://play.modiqo.ai/modiqo/helloQuestions people ask
Do reusable procedures have to come from recorded runs?
In Rote, yes. Rote compiles a Play from a trace that ran. A hand-written procedure carries no evidence that it worked.
Is a reusable procedure the same as agent memory?
No. Memory stores facts that the agent recalls and then reasons about. A procedure executes. Recall from memory still pays the reasoning cost; running a Play does not.
What happens when the API behind a procedure changes?
The Play's fingerprint no longer matches the live contract. The run stops and reports why. The harness examines the failure, the agent explores a new path, and that path is pushed as the next version of the same URI. Anyone pinned to the old version keeps it.
Can a procedure discovered in one harness run in another?
Yes, while the contract holds. No model reasons during replay, so the model and harness that discovered the path do not matter for running it. When replay breaks, the harness of whoever is running it steps back in to repair. Rote supports Claude Code, Codex, Cursor, Kimi, Hermes, OpenCode, and DeepSeek Harness.
This essay is one of five on turning a run into a reusable procedure
This overview names the five steps, and each of the other four essays takes one question further:
- Agent skills, workflows, prompts, and Plays remember different things: which container to use for what must survive the next run.
- How to extract a reusable procedure from an agent trace: the five compile operations and the four conditions that block them.
- Agent procedure memory survives a model change only as a program: why a Play runs from any model and stops when the API drifts.
- Share an agent workflow with a teammate without sharing a credential: what travels with a Play URI and what stays on the runner's machine.
Install the Play sidekick and try this on your own agent
One command installs the Play sidekick, installs Rote when it is missing, and wires the skill into the agent apps it finds on your machine. It runs on macOS and Linux, and on Windows inside WSL2.
curl -fsSL https://getrote.dev/playoffs/install.sh | shRestart your agent app, type $play (or /play in Claude Code), and run the Hello Play. It uses public data, needs no credentials, and declares no writes.
The next procedure to keep is the one your agent solved this week
Pick the task your agent solved once and will be asked for again. Start it with $play explore, guide one successful pass, and settle it. The second time, execute the Play instead of paying for the discovery.