> ## 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.

# The agent chain

> How workflow steps depend on each other, pass results forward, and how to order them.

## How the chain runs

The agents you add to a workflow form a chain, and what each one **[produces and consumes](/agents/writing-an-agent#contracts-what-a-step-produces-and-consumes)**
decides how it actually runs:

1. A step becomes eligible to run once every step it depends on has **settled** — either finished normally or
   been legitimately [skipped](/workflows/running#run-statuses). A step with nothing it depends on is eligible
   immediately.
2. **Steps with no dependency between them may run at the same time.** The order you drag them into sets which
   *earlier* steps a later one is allowed to draw on — a step can only consume a kind an earlier step in the
   list produces — but it doesn't by itself force one step to wait for another that it doesn't actually need.
3. **Two steps that both edit the repository never run at the same time**, whether or not they depend on each
   other — they'd be racing on the same checkout. This is `mutates-worktree` on the agent, not something you
   configure per workflow.
4. Each step is told what triggered the run (for a pull-request run: the PR number, head and base commits,
   the diff) and reads the actual results earlier steps recorded of the kinds it consumes — not a text summary
   of what an earlier step said it did.
5. **If a step fails, nothing that depends on it runs, and the run ends in error.** Workflow steps do not
   retry by default.

<Note>
  A step whose input turns out to be empty runs **zero times** and is recorded as **skipped** — a distinct
  outcome from *failed* and from *ran and found nothing*. See [run statuses](/workflows/running#run-statuses).
</Note>

## Passing results between steps

You don't wire inputs and outputs together by hand. What flows from one step to the next is exactly what the
consuming agent's `consumes` names — the actual results (findings, patches, or a kind of your own) that an
earlier step's `produces` recorded, not a prose account of what happened.

What this does **not** do is let you transform or filter results between steps. If you need different
handling, that belongs inside an agent, not between them.

## Choosing agents

Any agent can be a step — Console's or your own. Your organization's agents appear in the picker alongside the
built-in ones, and Console treats them identically.

* For what ships with Console and what each is for, see [the agent library](/agents/library).
* To write your own, see [writing an agent](/agents/writing-an-agent).

A few agents in the library are designed to be spawned *by* other agents rather than used as steps directly —
[noted here](/agents/library#agents-spawned-by-other-agents).

## Ordering

The rules of thumb:

* **Broad before narrow.** Discover first, then act on what was discovered.
* **Declare what a step actually needs.** Two steps that don't consume each other's output can run
  concurrently; a step only waits on the steps its `consumes` names.
* **Expensive before dependent.** If a step fails, nothing depending on it runs — so put the step most likely
  to fail where it costs least.
* **One step is a valid chain.** A single scanner plus an [output](/workflows/outputs) is a complete, useful
  workflow. Don't add steps for symmetry.

## Common chains

| Goal                                                 | Chain                                                 |
| ---------------------------------------------------- | ----------------------------------------------------- |
| Fastest signal                                       | `vulnerability-scanner-basic`                         |
| Balanced scan                                        | `vulnerability-scanner-standard`                      |
| Deepest audit                                        | `vulnerability-scanner-comprehensive`                 |
| Turn findings into permanent rules                   | `vulnerability-scanner-standard` → `detection-author` |
| Apply everything you've already vetted               | `detections-runner`                                   |
| Apply everything you've already vetted, and patch it | `detections-runner` → `patch-generator`               |

## Editing a chain

In the workflow editor the chain is drawn left to right as pills with arrows:

* **Add** with the **+** button, which searches the agent library.
* **Reorder** by dragging a pill.
* **Remove** via the grip icon on a pill.

Between 1 and 20 steps.

## Next steps

<CardGroup cols={2}>
  <Card title="The agent library" icon="books" href="/agents/library">
    What's available to chain.
  </Card>

  <Card title="Configure outputs" icon="arrow-right" href="/workflows/outputs">
    Deliver what the chain produces.
  </Card>
</CardGroup>