Multiply the work. Keep the judgment.

You have already assembled most of this. A coding agent does the work. A pack of skills and a rules file tell it how you build. Something gives you more than one session at a time and keeps them out of each other's way. Each piece is good, and none of them knows the others exist.

toryo is the rig around all of it. It drives the agent you already installed, reads the rules you already wrote, and runs as many sessions as you have capacity for. Nothing gets replaced.

What it adds is the part that only exists once something is holding the whole stack together. Work becomes durable jobs rather than windows you are keeping open. Runs stop at gates you set and recover from failures on their own. A scheduler puts recurring work on a lane of its own. And everything any run learns lands in a knowledge plane the next run reads from, so the tenth task starts better informed than the first.

The pieces you already have make a single agent session better. This is the layer that makes all of them yours.

A sequence runs on its own until it reaches something you should see. It proposes a plan and waits. It holds at the merge gate. When it needs an answer it messages you and stops, rather than guessing and carrying on. Everything between those points runs whether you are watching or not.

A gate can wait, because the run is not a conversation. It is a row in a database with a worktree attached. Close the laptop at a plan gate and answer it tomorrow, and the run picks up where it stopped.

The gates are yours to move. Fewer of them on work you trust, more of them on work you do not.

We are not going to tell you how to build software. The three above are how we work, and they are there so a new install is useful on day one. They are defaults, not doctrine.

When your process differs, encode yours. A sequence is a YAML file that lives in your own repository, under .toryo/sequences/. There is no fork, no plugin to register, nothing compiled into toryo, and no code unless a step needs it. Give one the same name as a sequence we ship and yours is the one that runs.

You are describing your own process: the steps, what each one hands the next, which ones run an agent, and where the run should stop and ask a person. Whatever your team argues about in review, whatever the runbook says, whatever the senior engineer does from memory. That becomes something the machine runs the same way every time.

There are four ways in, and none of them is a text editor unless you want it to be. Describe what you want to an agent and let it draft the file. Fill in a form in the console. Write the YAML yourself. Or import one somebody else published, which lands behind a review gate so you read it before it runs.

And because it is a file in your repository, it ships in git like anything else. Fork it, review it in a pull request, and hand a new hire a working definition of how your team builds instead of a wiki page about it.

A run that goes sideways usually teaches you something you then forget. toryo files it instead.

The reflect step writes findings to an idea registry rather than editing config that dies with the worktree. The session debugger mines your transcripts for wasted behavior and files there too. A review finding with no matching rule becomes a rule gap. Repeat findings increment a counter instead of piling up, so the things that keep happening rise on their own.

You still decide. The system does the noticing.

Every app in toryo is a CLI, and that surface is frozen in a machine-readable contract that per-app tests pin against.

We know it holds because the first thing built on it was not built by the platform team. Pull request review started life as a separate app on top of toryo, with its own sequence, its own database, and its own interface. Building it outside produced a richer tool than folding it in ever did, which is why it lives on as the worked example rather than as a feature. Clone it, read it, and you have the shape of anything else you want to put on the contract.