Workflows: the rules your fleet works by

5 min read

A workflow is a named way of working that your whole fleet shares. Not a script and not automation - it is written guidance about how a kind of job should be run, stored on your Gateway, and read by every agent on every machine at the moment it starts.

It exists because the alternative is retyping the same expectations into every session and getting slightly different behaviour each time.

The catalog

Open Workflows in the Cockpit. Each row is one workflow: its name, whether it is currently in force, which version is live, and when it last changed.

The Cockpit Workflows page listing three built-in workflows - mission, standalone, and standalone-with-review - each marked In force with its live version, last updated date, recent activity, and Preview and Clone actions

DevThrottle ships with three built-in workflows:

Mission - an Architect settles the design, a Manager drives the phases, and Workers build. You are bothered once, at the report.
Standalone - one agent picks up the work and finishes it. No manager, no review seat.
Standalone with review - one agent does the work, and a second, separate agent reviews it before it is called done.

How a change reaches your agents

Any agent can author a workflow. It is pushed as a draft, and publishing makes it the version every machine reads - immediately. There is nothing to deploy and nothing to restart.

Note

Publishing does not disturb work already underway. A run that is in progress keeps the version it was pinned to when it started, so changing a workflow never rewrites the rules out from under a job that is halfway done.

Reading and authoring from the command line

The Cockpit is one window onto the catalog; the command line is the other, and it is the one your agents use.

Reading

cc-devthrottle workflow list             # every workflow the fleet can run
cc-devthrottle workflow show <id>        # metadata, steps, outcome criteria
cc-devthrottle workflow instructions <id>  # the raw conduct, to be followed
cc-devthrottle workflow versions <id>    # version history, newest first

instructions is the one an agent actually calls: it prints the workflow's guidance so the agent can follow it as its conduct for that job.

Authoring

cc-devthrottle workflow pull <id> <dir>  # workflow.json + instructions.md + helpers/
cc-devthrottle workflow push <dir>       # upload as a draft (creates it if new)
cc-devthrottle workflow publish <id>     # the draft becomes the live version

Turning one off

A workflow can be switched off without being deleted. disable hides it from every agent's briefing and stops new runs and seats; nothing is removed, and enable puts it back. Built-in workflows can be reset to their shipped content with reset, and can never be deleted - deleting only archives a custom one, and its version history stays.

Runs

Each execution of a workflow is a run. runs lists them newest first, and run shows one in detail: the version it was pinned to, its lifecycle, its acceptance criteria, who took part, and the proof it produced.

Tip

Workflows are fleet-wide, so they are also how you make an improvement stick. Rather than telling one agent to work differently, change the workflow and every session that starts afterwards is briefed with it.

Where to go next

For a walk-through of writing your first one, see Workflows: your named ways of working. For the roles a mission workflow staffs, see Session roles and missions. For the rest of the command line, see the command reference.