Automate with pipelines

A pipeline is appropriate when you know the sequence of work and how data should move between steps.

Design the data flow

List the pipeline input, the output produced by each step, and the final result. Use $variable references to map earlier output into later input.

Keep mappings explicit. A pipeline that relies on accidental response shape is difficult to debug and easy to break.

Configure each step

For every step:

1. select an agent or team;
2. map the required input;
3. name the output you need later;
4. decide what should happen on failure;
5. add a condition only when skipping is intentional.

Handle failure intentionally

Each step can either use the pipeline-wide recovery setting or override it with its own. The options are:

• Stop and show the error — the failure propagates and the pipeline stops. This is the default.
• Retry — reattempt the same step, with a configurable attempt count and backoff. Use it for transient failures.
• Try a backup agent — hand the step to a different agent when the first one fails.
• Skip — continue without this step's output. Choose it only when the downstream workflow is still valid.
• Pass error along — feed the error into the next step as input, for a workflow that handles failures itself.

Try a backup agent is agent-only: the backup you nominate must be an agent, and the option is not offered on a step that targets a team. Give a team-targeted step retry, skip, or stop instead — or split the fragile part into its own agent step so it can have a backup.

Test before triggering

Run the pipeline manually with normal and malformed inputs. Inspect step output and execution history. Add a schedule or inbound webhook only after failures are understandable and safe to retry.