Fleet 1.17.0 is out.See what's new →
FleetFleet
← All posts
Technical

Introducing the Fleet Workflow Builder

Fleet's reactive dev chain was always a workflow — a draft step, a review step, an approval gate, a merge. We pulled that engine out, put a canvas on top of it, and now you can build your own.

June 9, 2026·7 min read

For most of Fleet's life there was one workflow, and it was hard-coded.

A ticket gets labeled ready. A developer agent picks it up, writes the code, opens a PR. A reviewer agent reads the PR and either approves it or sends it back with changes. A release agent checks the gate and merges. Every step has a type, every handoff has a rule, and the whole thing is bounded so a review that keeps failing can't loop forever. That chain is the thing most people mean when they say Fleet "runs itself."

The longer it ran, the more obvious it got that the chain wasn't really about code. It was a workflow: a sequence of typed steps, with gates where a human decision belongs and routes for what happens when a step fails. The coding part was just one kind of step. So we pulled the engine out from under the dev chain, generalized it, and put a canvas on top of it. That canvas is the Fleet Workflow Builder, and it ships with this release.

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 six kinds today:

  • Document — draft a report, a dataset, or a page from a prompt and a corpus.
  • Review — read the inputs and write a findings document.
  • Approval gate — pause for a human decision, and record it.
  • Notify — tell the right people a step finished.
  • Publish — share the approved document as a link.
  • Code and merge — open and squash-merge a pull request. These two are in preview, behind a flag, while the rest are on by default.

You compose them however the work demands. The dev chain is one arrangement of them. 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.

Governance is 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 routes it back to be redone. That's the loop that makes the dev chain work. But 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 the self-correcting behavior without the 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 the recurring stuff — the report that's due the first of every month. The label is the autonomous path: tag a backlog ticket and the workflow fires a run seeded with that ticket, the same way the dev chain wakes up when an issue goes ready.

That last one is why the dev chain was a good first customer for this engine. It proved the whole shape — a label starts it, steps hand off through typed edges, a gate holds for sign-off, a failure routes back with a bound — under real load, on real pull requests, before any of it was something you could draw.

What's actually shipping

Honesty, because this is a product blog and not a press release: the Workflow Builder is new, and it's rolling out with this release. You can design and visualize workflows in the dashboard right now. Runs execute on your self-hosted Fleet, so you'll want to be on the release that ships the worker. The code and merge steps are in preview behind a flag — the document, review, and governance steps are the on-by-default set. Fleet itself is still in open beta: the binary is free to install and inspect, and starting agents needs a license you get when you sign up.

If you've been using Fleet to run a fleet of coding agents, this is the same machinery you already trust, with the lid off. Build a workflow for the recurring, multi-step work you don't want to do by hand — and put the gate exactly where a human should still decide.

Explore the Workflow Builder →

Try Fleet

One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.