Skip to main content
A prompt is a blank box. It assumes you know what to ask, how to ask it, and what good looks like when it comes back. That is fine for a one-off. It is exhausting as a way to run a practice. TorchRunner ships the work pre-built instead, and the unit of pre-built work has a name: a Runner. A Runner is an opinionated piece of work the system already understands: a renewal review, a monthly close summary, a QBR prep, a status report. It knows its own steps, its own inputs, and what finished looks like. You do not assemble it from scratch every time. You direct it and you correct it.

​
Why this matters for an operator

You already manage this way. When you delegate to a person, you do not write them a paragraph of instructions for a task they have done forty times. You say “run the monthly review for Acme,” you read what comes back, and you correct the parts that are off. Runners map onto that exact muscle. The skill you bring is judgment and direction, the same skill that makes you good at the job. This is the opposite of the blank-slate trap, where a flexible tool quietly transfers all the design work onto you. TorchRunner makes the design decisions in advance, on purpose, for your kind of work.

​
What a Runner contains

A defined outcome

Each Runner knows what it is producing and what done means.

Its own inputs

It pulls from the engagement record, not from your memory.

Steerable steps

You can redirect at any point. A Runner is not a black box.

A correction surface

Your fixes are captured, not discarded.

​
The trade you are making

You give up infinite configurability. In return you stop paying the blank-page tax on every task. For a portfolio of engagements running the same shapes of work over and over, that trade pays for itself in the first week.
Runners also have a home surface in the product, where every one of them shows its owner, its trigger, and its live health. See the Runners module.