> ## Documentation Index
> Fetch the complete documentation index at: https://amplifysecurity-eng-2210-deterministic-workflows-docs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflows
> Chain agents into repeatable automation that fires on a trigger and routes its results wherever you need them.
## What is a workflow?
A workflow is a saved sequence of agents that Console runs against your repositories. Where chat is a
conversation you drive turn by turn, a workflow is the same agents running unattended: you define the
sequence once, and Console executes it whenever a trigger fires or you run it by hand.
Workflows are where the other two layers pay off. [Agents, skills, and detections](/agents/overview) do
the work; [your repositories and connections](/data/overview) give them something real to reason about. A
workflow puts those to work on a schedule, with no one in the loop, and delivers the result to where your
team already works.
A typical workflow scans a repository for vulnerabilities, hands what it found to a second agent that
authors reusable detections or generates patches, and routes the result to whichever outputs you have
attached.
## Anatomy of a workflow
Every workflow is made of four parts. Only the first two are required.
| Part | Required | What it does |
| --------------- | -------- | ------------------------------------------------------------------------------------------ |
| **Name** | Yes | Identifies the workflow. Must be unique in your organization. |
| **Description** | Yes | A short summary of the workflow's purpose, shown in the workflow list and run history. |
| **Agents** | Yes | The ordered chain of agents to run. At least one, at most twenty. |
| **Triggers** | No | When the workflow fires automatically. Manual runs are always available without a trigger. |
| **Outputs** | No | Where the results go when the run finishes. Attach as many destinations as you need. |
The description documents the workflow for your team — it doesn't shape what any step does. Each agent
already carries its own instructions, which is what actually runs. See
[Create a workflow](/workflows/create-a-workflow#description).
## What happens during a run
When a workflow fires, Console does the following for **each** repository you targeted:
1. **Creates a run.** Every run gets its own record, visible under [Runs](/workflows/running).
2. **Snapshots the definition.** The run captures the workflow's name, description, and steps as they
are at that moment. Editing the workflow later never changes a run that is already in flight.
3. **Provisions an isolated sandbox** and clones the repository into it. For pull-request runs, it
clones the pull request's head — not the default branch.
4. **Runs the chain.** Each step runs once the steps it actually depends on have finished (or been
legitimately skipped) — independent steps can run at the same time; see
[the agent chain](/workflows/agent-chain) for exactly how steps depend on each other.
5. **Stops on failure.** If a step fails, nothing depending on it runs, and the run ends in error.
6. **Records findings** from the run, and **dispatches your outputs** once the run completes.
Targeting three repositories produces three independent runs — one per repository — not one run that
loops. Each gets its own sandbox, and one failing does not stop the others.
## Where workflows live
* **Workflows** — the list of workflows in your organization, with a run count for the last 7, 30, or
90 days. This is where you create, edit, and manually fire them.
* **Runs** — the execution history for every workflow, including per-step status, findings, and
whether each output was delivered.
## Next steps
Walk through the editor section by section.
How steps depend on each other and how to order them.
Decide what starts a run, and when.
Route results to where your team works.
Fire a workflow and read its run history.