When to use toryo
toryo is good at a particular shape of work and bad at others. Aiming it at the wrong thing is the most common way a first week goes badly, so this page is as much about what to avoid as what to reach for.
One thing to hold in mind while reading it. What follows describes the shape of the sequences we ship, which plan first, work in an isolated worktree, and arrive as a pull request. That is our process, not a property of toryo. If it is the wrong shape for your work, the answer may be a sequence of your own rather than a task queued somewhere else. See Writing your own sequences.
The shape it fits#
Work you can describe before it starts. A sequence plans first and asks you to approve that plan. If you can write down what "done" means, toryo can usually get there. If you are still working out what you want, you are designing, and that is a conversation rather than a job.
Work that outlives your attention. Everything runs as a durable job in its own tmux session. Close the laptop, come back, it is still going. That is the whole reason to queue something instead of sitting in a chat window.
Work you would rather review than write. Output arrives as a pull request. The economics only make sense when reading the result is genuinely cheaper than producing it.
Work that repeats. A codebase review, a dependency sweep, or a triage pass is worth scheduling once and forgetting. This is where toryo pulls furthest ahead of a chat window, because nobody has to remember to do it.
Good first tasks#
- A well-specified bug with a reproduction
- A mechanical refactor across many files: renaming a concept, changing a signature everywhere it is used
- Test coverage for a module that has none
- A dependency upgrade with a clear migration guide
- Reviewing a pull request you did not write
Each of these has a checkable finish line, which is what makes the plan gate worth answering.
What to avoid at first#
Anything you cannot review. If you would not catch a subtle mistake in the output, do not queue it yet. Start where your judgement is strongest.
Exploratory design. "Should we use X or Y" is a conversation. Have it in an agent session, then queue the work that comes out of it.
Work with no definition of done. "Make it faster" or "clean this up" gives the planner nothing to aim at, and you will spend more time at the gate than you would have spent doing it.
Anything touching production directly. toryo opens pull requests; it does not deploy. Keep it that way until you trust it.
A repository you cannot afford to have churned. Work happens in isolated worktrees and arrives as a PR, so your working tree is safe. Your CI minutes and your reviewers' patience are not.
When a chat session is the better tool#
Reach for a plain agent session, not a queued job, when:
- you want to understand something rather than change it
- the task is a two-minute edit you could do faster yourself
- you expect to change your mind halfway through
- you need to watch each step and steer
toryo is built to run work you have already decided on. Deciding is still interactive, and that is the right division.
How to tell it is working#
After a week or two the signal is not "the agent wrote code". It is:
- plans you approve without rewriting them
- pull requests you merge with minor comments rather than major ones
- the knowledge plane answering questions you would have had to re-explain
If the plans keep coming back wrong, the brief was underspecified more often than the model was. Say more in the brief before you conclude toryo cannot do the work.