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 briefing" 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.

Automate, don't babysit

The point of the workflow builder is to take a repeatable, multi-step AI task off your plate and let it run on a schedule or a trigger, reliably, with a cost you can account for line by line. Build it, test it on your own data, schedule it, and let the run trace tell you exactly what happened on every execution. The same DAG runs identically whether you are on the hosted platform or a self-hosted deployment against your own models.