# How Workflows Run
{{< tier level="sovereign" note="Durable runs keep multi-agent work understandable across waits, restarts, reviews, and recovery." >}}

Valdr Workflows turn multi-agent work into a process you can run, inspect, and recover with confidence. Each run follows the exact versions of the workflows it uses, records its progress and evidence, and remains understandable across agent sessions, reviews, approvals, waits, and restarts.

A workflow definition is the saved recipe. A run is one execution of that recipe. Active work stays predictable because later edits do not change the version already in progress.

## From launch to completion

{{< thumbcard src="/images/workflows/how-workflows-run.svg" fit="contain" alt="Workflow run moving from launch through ready steps, recorded attempts, durable waits, and declared results" caption="Valdr records each step's status, attempts, outcome, and available evidence before advancing dependent work." >}}

Valdr advances only steps whose dependencies are satisfied. A `when` condition can skip a step, and an Outcome route can evaluate a result for later branching. A **step** is one authored unit of work; an **attempt** is one execution of that step. A retry creates a new attempt without erasing the earlier one.

For example, an implementation step can launch an agent, a review step can wait for its verdict, and an Outcome route can return requested changes to implementation for another bounded pass.

## Agent and review work

Session steps can launch an agent for a task, launch a prompt-only agent, or continue an existing agent session. Review steps can inspect the task and the branch or worktree used by the implementation session.

The run inspector links this work back to the step that launched it, so you can move between the workflow, agent session, task, and review without reconstructing the handoff yourself.

## Waits

Some work completes immediately; other work needs time or authority. A workflow can pause while it waits for:

- An agent session to finish.
- Review evidence and a review verdict.
- A child workflow to finish.
- A human approval or rejection.

While waiting, the run remains available in Valdr UI and can resume after a restart when the expected work, evidence, or decision arrives. Long-running processes survive routine interruptions instead of forcing you to rebuild their coordination state.

## Outcome routes and bounded loops

Outcome routes compare declared values. Downstream `when` checks choose each branch independently, so multiple branches may run. Without an explicit failure policy, a mismatch is recorded and the route completes; `block` or `fail` stops the run instead. A bounded loop can return requested changes to an earlier step, such as implementation, and then repeat review.

The workflow definition sets the maximum number of passes, keeping iteration controlled instead of allowing an agent-review cycle to continue indefinitely. If the limit is reached, the run **blocks by default** or fails when the author explicitly chooses that policy. Operational failures do not advance the loop-pass counter.

## Results and evidence

**Declared results** are the outputs the workflow author selected to summarize the run, not every internal value produced along the way. **Evidence** is the supporting record attached to or required by a step, such as an agent session outcome, a published review verdict, or a human approval.

The run inspector shows:

- Workflow inputs and declared results.
- Every step and attempt.
- Related agent sessions, reviews, tasks, and child workflows.
- Accepted review or approval evidence.
- Clear error information and available recovery actions.

This local history makes agent work explainable: you can understand what ran, why it advanced, what supported the decision, and where intervention is required.

A **failed** run has reached an unsuccessful terminal state. A **blocked** run has stopped at a problem that needs intervention and is recoverable only when Valdr offers an applicable action, such as **Retry step**.

## Retry, run again, cancel, or delete

Recovery actions let you address a specific problem without discarding every successful step and starting the process over.

- Use **Retry step** when Valdr offers it for the selected blocked or failed attempt. Earlier attempts remain visible.
- Use **Run again** to create a separate run from the same workflow versions. Choose a newer workflow version explicitly when you want changed behavior.
- Use **Cancel run** to stop workflow orchestration. See [cancellation scope](/valdr/docs/workflows/reliability-and-recovery/#cancellation) for how this affects related work.
- Use **Delete run** only after a run is failed, completed, cancelled, or blocked. Deletion permanently removes its workflow history. The UI also removes linked session records by default; select **Keep linked sessions** to retain them.

## Next step

{{< callout type="info" >}}
**[Run Your First Workflow](/valdr/docs/ui/workflows/first-workflow/)** — Start, review, and inspect a complete workflow without writing YAML.
{{< /callout >}}

Other paths: open the [Workflow UI guide](/valdr/docs/ui/workflows/) to operate runs, follow [From Idea to Verified Sprint](../idea-to-sprint/) for a concrete lifecycle, or read [Reliability and Recovery](../reliability-and-recovery/) for deeper operational guarantees.