Fleet now makes the workflow the source of truth.
A saved coding workflow can start when a ticket gets labeled ready: refine the ticket, develop the change, review the pull request, pause for approval, merge, and announce. Every step has a type, every dependency is visible, and every recovery route is bounded so a review that keeps failing cannot loop forever.
Coding is only one use for that model. The same graph can produce a report, refresh a dataset, publish a site, or coordinate any other repeatable job that needs review and sign-off. The Fleet Workflow Builder is the canvas for designing those graphs.
What it is
A workflow is a graph of typed steps. You build it visually: drop steps on a canvas, drag a connection from one to the next, and the edge you draw is the dependency. There's no YAML to hand-write and no step-ordering to get right by hand — the graph is the source of truth, and the engine runs it.
Each step is typed, and the type decides what it needs. A document step takes a prompt and a corpus of source files and produces a document. A review step reads whatever flows into it and writes its findings. An approval gate takes a question and a list of people. A merge step takes nothing at all — it just merges the pull request that came in on its input edge. The builder's inspector only ever shows you the fields that apply to the step you're looking at, because a coding agent has no use for a corpus and a merge has no use for a prompt.
There are nine kinds today:
- Report — produce a governed document from a prompt and a corpus.
- Data — transform source material into a structured dataset.
- Site — build or update a site artifact.
- Code — dispatch an agent to implement a change and open a pull request.
- Review — read the inputs and write a findings document.
- Approval gate — pause for a human decision, and record it.
- Publish — share the approved document as a link.
- Merge — merge the pull request after review and approval boundaries clear.
- Notify — tell the right people a step finished.
You compose them however the work demands. A coding workflow is one arrangement. A monthly report is another. A security questionnaire is a third.
Where the type system earns its keep
The reason every step is typed isn't tidiness. It's that the type tells the engine what a step produces, which tells the next step what it's receiving. A code step produces a pull request, so the merge step downstream knows it's merging a PR. A document step produces a file. A step configured to write to your ticket system produces an issue. The input to any step is just whatever its upstream edges carry, plus any corpus files and — for a workflow triggered off a ticket — the ticket that started the run.
That's what makes the graph trustworthy. You're not wiring strings together and hoping the shapes line up. The edges are typed, and the builder won't let you draw an arrangement that doesn't make sense.
The review and sign-off are the point, not a setting
Plenty of tools will run a sequence of LLM calls for you. The reason to run one inside Fleet is everything that wraps the sequence.
Approval gates pause the run. Drop one anywhere in the flow and the run stops there, asks the people you named, and won't proceed until someone decides. The decision is recorded — who approved it, when, and what they were looking at. For work where being wrong costs money, that record is the entire reason the workflow exists.
Every run leaves an audit trail. Each step writes a versioned, content-addressed artifact with its lineage intact. After the fact you can answer who proposed, who reviewed, who signed off, and what each step actually produced — for any run, not just the one that's still on your screen.
Retries are bounded. When a review flags an output, the workflow can route it back to be redone. Every fail edge carries a ceiling, and when the retries run out the run hands off to a notify step instead of grinding forever. You get self-correcting behavior without runaway risk.
It's self-hosted. You design the workflow in the dashboard, but the run executes on your own Fleet worker, on Claude Code. Your source and your documents stay inside your boundary — and if you point Claude Code at Bedrock or Vertex, the model runs in your cloud too.
None of that is a checkbox you remember to turn on. It's what a step is.
Three ways a workflow starts
A workflow can run on a button, on a schedule, or on a label. The button is for when you want one now. The schedule is a cron expression for recurring work — the report due the first of every month. The label is the autonomous path: tag a backlog ticket and Fleet creates a workflow run seeded with that ticket.
The coding template proves the whole shape: a label starts the run, typed edges carry outputs, a gate holds for sign-off, and a failure routes back with a bound.
What's actually shipping
Honesty, because this is a product blog and not a press release: you design and visualize workflows in the dashboard, and runs execute on your self-hosted Fleet worker — check the changelog for changes in your binary version. Document, code, review, approval, notify, publish, and merge steps share the same saved workflow model. The binary is free to install and inspect, and starting agents needs a license you get when you sign up.
Build a workflow for the recurring, multi-step work you do not want to run by hand — and put the gate exactly where a human should still decide.