What a workflow actually is here

Most "workflow" tools in the AI space are prompt chains with a thin wrapper. ToRun's builder is a directed acyclic graph (DAG) of typed steps: you connect model invocations, tool calls, conditional branches, loops, and sub-workflows into a graph, and the runtime executes them in dependency order, in parallel where the graph permits.

Each step is a first-class entity with its own configuration: the step type (LLM call, web search, code execution, image generation, retrieval, transform, etc.), its input schema, its error policy (fail fast, retry with backoff, skip to fallback), a per-step execution budget cap, and a timeout. Secrets are stored in encrypted workflow vaults — your API keys never appear in the graph definition.

The model routing inside each LLM step runs through the same capability pipeline as everything else on ToRun. You declare what you need — structured output, vision, tool use, reasoning, a context window of at least N tokens — and the runner resolves the best-fitting model from whatever providers are available at execution time. If your first-choice provider returns a 5xx, the fallback chain takes over automatically.

Quality-first runners and what that means in practice

When you run a workflow manually or on a schedule, the runner deliberately picks quality-tier models rather than the cheapest option. There are two reasons: automations produce artifacts (reports, generated content, code) that a human does not immediately review, so quality errors compound silently; and the cost difference at modest volume is smaller than the cost of a bad output that needs a re-run or a manual correction.

In practice this means a "summarize research and draft a blog post" workflow will prefer a capable reasoning model for the summarization step and a high-quality text model for the draft step, rather than racing to the floor on price. You can override this per step if you know a lightweight model is sufficient for that part of the graph.

Billing is the same as everywhere on ToRun: every model invocation inside a workflow writes exactly one billing record with a frozen price snapshot. A run that calls three different models across five steps produces five billing records. You can audit the exact cost of every execution, broken down by step, after the fact — even months later after provider prices have moved.

Debugging a run

Every workflow execution produces a structured run trace. The trace shows the DAG with each node annotated: start time, finish time, model resolved, token counts in and out, tool calls made, and the error (if any). For LLM steps you can expand the exact prompt sent and the raw response received.

If a step fails, the trace tells you whether the error came from the model call itself (provider error, context overflow, content policy rejection), from a downstream tool (network timeout, schema validation failure), or from your own conditional logic. You do not have to add logging — it is captured at the infrastructure level for every run.

Runs can be replayed with a pinned model (bypassing auto-routing) and a snapshot of the input, which makes it straightforward to reproduce a failure or compare outputs across models on the same input.

A small example: a weekly competitive-intelligence workflow

Consider a workflow that runs every Monday morning:

1. Web search step — searches for recent coverage of a set of competitor keywords, returns a list of URLs and snippets.
2. Retrieval step — pulls the last four reports from a knowledge base to establish baseline context.
3. Summarize step (LLM) — distills the search results into structured findings: new features, pricing changes, notable announcements.
4. Draft step (LLM) — writes a short internal briefing in a consistent house style, grounded in the summarized findings.
5. Deliver step — posts the briefing to a configured webhook endpoint.

The graph has a natural dependency: step 3 depends on steps 1 and 2 (which can run in parallel), step 4 depends on step 3, step 5 depends on step 4. The runner executes it that way without any explicit parallelism configuration — it reads the edges.

Publishing to the marketplace

Workflows you build can be published to the ToRun marketplace. A published listing has a description, a set of required configuration parameters the buyer fills in (their own API keys, their webhook URL, the keyword list), and a price — one-time or subscription.

Creator revenue share scales with your plan: 55% on Pro, up to 75% on Partner. ToRun handles the payment processing and distribution. Buyers get a copy they can inspect and customize; sellers can issue updates that buyers can choose to adopt.

Disclosure and quality review are required before a listing goes live. A workflow that silently burns a buyer's budget or produces confidently wrong outputs does not pass review — this is not a race to the bottom on quality.

If you have a workflow that solves a real problem and runs reliably, the marketplace is a straightforward path to recurring revenue from it. Build it, test it on your own data, publish it.