Fleet 2.9.1 is out.See what's new →
FleetFleet

Steps and typed I/O

Each connection carries the upstream step's typed output, such as a file, ticket, PR, decision, or action marker, into the next step.

Step kinds

report / data / siteRuns an agent prompt over inputs and emits a versioned file artifact.
codeDispatches a coding agent in the workflow repo, parks the run, and produces a PR reference.
reviewChecks an upstream output or PR against source-of-truth inputs and emits pass or flag.
code_reviewRuns Fleet's tool-free review one changed file at a time over a worker-local immutable PR snapshot, then incrementally synthesizes the result.
review_publishRechecks the pinned PR revision and publishes provider-native review output with validated RIGHT-side comments; GitHub may use evidence parts followed by the final verdict.
approvalParks for a human decision and records the approver, time, and reason.
publishShares an approved upstream artifact and returns a link.
mergeMerges the approved upstream PR. It must sit behind the workflow's governance boundary.
notifyEmails the content flowing into the step to the configured recipients.

Where inputs come from

Dependency edges

Files, tickets, and PRs produced by upstream steps.

Trigger ticket

The backlog ticket that started a label-triggered run, available to entry steps.

Corpus globs

Repository files matching patterns such as docs/**/*.md, with .gitignore respected.

Failure feedback

The precise review flag, rejection, or error routed back during a fix loop.

Outputs

Document-producing steps default to a content-addressed artifact. They can instead create a ticket or update the triggering ticket. Action steps have intrinsic outputs: code produces a PR, merge produces a merged-PR marker, approval produces a decision, and publish produces a link. Pull-request review source, assembled model input, raw findings, and rendered review bodies remain in the assigned worker's local CAS. Saved author instructions are part of the control-plane workflow definition, and the worker sends validated review text directly to GitHub. Only status, counts, coverage, SHAs, and the GitHub review link enter run history or a downstream notification. If the base or head changes, Fleet publishes nothing and queues one fresh revision review through the normal workflow path. Unreferenced local review content is pruned after 30 days.

The builder derives the input summary from the graph. There is no separate free-form input picker that can drift away from the dependency edges.

Agent types and house rules

Agent-running steps can bind a role. The value names an agent type rather than a specific instance. At run start, Fleet pins that type's house rules and model defaults. Control steps such as approval, publish, merge, and notify never run an agent and cannot bind a role.

A step can also choose its coding harness and model. For OpenCode, Fleet suggests models reported in every connected worker's catalog for the selected repository and shows the workers' reported versions. You can still type a provider/model ID manually. Run fleet doctor on a worker to check whether its installed OpenCode version supports the preferred model discovery interface.

Fan-out

A document step can run once per file matching a forEach glob. Each item produces its own artifact and cache fingerprint. A downstream step receives the combined outputs for synthesis.

Next: triggers and outcome routing →