| title | What are steps? |
|---|---|
| description | The building blocks of a workflow. |
A workflow is made of steps. Each step is a single prompt sent to an AI agent, plus a declaration of the structured output that prompt must produce. Steps are grouped into depths and run in order, with each depth's output feeding the next.
| Part | What it is |
|---|---|
| Name | A human-readable label for the step. |
| Content | The prompt sent to the agent, with {{variable}} placeholders. |
| Output format | The keys the step must emit and their types. |
| Depth | Which level the step sits at (0 = entry point). |
| Multi-output | Whether the step may emit many results per input. |
| Consume all | Whether the step receives the whole previous level as one batch. |
| Bound source | Optional one-to-one route from a sibling in the immediately previous depth. |
Every step declares an output format - a map of key names to types. Valid types are
string, number, boolean, array, and object. At run time the engine instructs the
agent to return JSON matching this schema, and stores the result so later steps can read
those keys.
Keys must be globally unique across the whole workflow, and no key may collide with a
built-in variable or with extra.
The deepest step is the terminal step, and it must emit the fixed finding schema so every finding is consistent and comparable. The required keys are:
explanation, file_path, line, malicious_input_example, summary, trigger_flow,
vulnerability_type, and malicious_actor (plus an optional exploitable).
When a step completes, its JSON output is merged into the context used by the next depth. So a depth-1 step can reference any key a depth-0 step emitted, exactly as if it were a built-in variable.
With bind routing enabled, the available keys stay the same, but execution is filtered: each destination runs only for results produced by its selected source sibling. See Depth and siblings.
Next: the prompt editor and prompt output.