Runs, gates, and workflows: the primitives, explained

Most of what people mean when they ask "how does this actually work" comes down to three words used precisely: workflow, run, and gate. This is what each one is, and how they fit together.

The workflow is the definition, not the execution

Key takeaway: A workflow is the template. It doesn't do anything by itself, it defines what happens when something triggers it.

A workflow in Upsun Dispatch™ is a defined sequence of steps, some carried out by an agent, some requiring a human decision. It's written once and applies to every future event that matches its trigger. Upsun Dispatch ships with PR Review as a first-party workflow at launch, an agent reads a pull request and posts a structured review before a human sees it, with no gate, the review itself is the output.

A workflow definition includes what triggers it, an event like a pull request opening, an issue mention, or a schedule, what steps an agent carries out, and where, if anywhere, the workflow requires a human decision before continuing. Changing the workflow definition changes how every future run behaves. It doesn't touch runs that already completed.

A run is one specific execution

Key takeaway: A run is a single instance of a workflow acting on a single piece of work. It's the thing that gets logged, and the thing you're actually looking at when you check on progress.

If a workflow is the recipe, a run is one specific instance of cooking it. A pull request opens, the PR Review workflow triggers, and that specific instance, this PR, this diff, this timestamp, is a run.

Every run carries its own record: what triggered it, what context the agent used, what it produced, and what it cost. That record is stored as immutable data, tied permanently to the run, not to the workflow definition. Two runs of the same workflow can have entirely different outcomes, one might complete cleanly with no human input required, another might hit a gate and wait.

This is the level at which cost is tracked, per run, attributed to the specific execution that spent it, not bundled into a single number for the whole workflow or the whole team.

A gate is a defined stop, not a notification

Key takeaway: A gate is a point in a workflow where the run pauses and waits for an explicit human decision. Nothing passes a gate on its own.

A gate is a point a workflow's designer chose deliberately, not something that happens by default. When a run reaches a gate, it stops. It doesn't continue until a person approves, rejects, or sends it back with feedback. That decision, and who made it, becomes part of the run's permanent record.

Gates route to whoever owns the decision. An engineering-scoped gate goes to an engineer. A gate that touches user-facing behavior can route to product. One that touches access or data can route to security. The workflow definition decides which gates exist and who they route to, not a fixed default that treats every decision the same way.

Not every workflow needs a gate. PR Review, as it ships today, has none, the structured review it produces is the deliverable, and a human reads it the way they'd read any other comment on the pull request. A workflow that writes code and opens a pull request typically does have at least one gate before anything merges.

How the three compose

Key takeaway: One workflow definition can produce many runs. One run passes through however many gates its workflow defines, zero, one, or several.

Put together, the model is: a workflow is written once, an event triggers a run of that workflow, and the run may pass through one or more gates before it completes. Nothing here is implicit. The workflow definition is inspectable. The run's record is inspectable, after the fact, by anyone with access. The gate, when the workflow includes one, is a real stop, not a soft checkpoint that can be skipped under load.

This is also the model that makes cost and audit make sense together. A run's cost is attributed to that specific execution. Its audit record includes the same run, the plan, the diff, who approved what at each gate, and when. Neither has to be reconstructed later, both are captured as the run happens.

What's true today, and what's coming

Key takeaway: Upsun Dispatch supports GitHub SaaS and self-hosted GitLab as trigger sources today. Model routing across tasks is planned, not yet available.

Upsun Dispatch is model-agnostic in the sense that you provide a model key during setup, and that key applies across your workflows. Automatic routing of different tasks to different models, based on cost or quality, isn't available yet. It's planned, but today a workflow runs on the model you've connected.

The trigger examples used throughout this piece, a pull request opening, an issue mention, work the same way whether your repo lives on GitHub SaaS or self-hosted GitLab, both are supported today as trigger sources.

Run your first workflow to see a run's record, and its gates, for yourself.

Frequently asked questions (FAQ)

Is a workflow the same thing as an agent? 
No. A workflow can involve an agent doing work at one or more steps, but the workflow is the defined sequence, the agent is one participant in it. Upsun Dispatch treats the workflow, not any single agent, as the unit that gets designed, versioned, and governed.

Can one workflow have more than one gate? 
Yes. A workflow can define as many gates as its steps require, none, one, or several, each one routed to whoever owns that specific decision.

If I change a workflow's definition, does it affect runs already in progress? 
No. A workflow change applies to future runs triggered after the change. A run already in progress continues under the definition that was active when it started.