Auto tasks — the agent chooses the workflow

File a task whose workflow the agent picks for itself from your stage library, and set the floor and ceiling that bound what it may pick.

Most tasks run a fixed pipeline: a story always plans, builds, gets reviewed, merges, and gets verified. That’s the right amount of process for most work, but not all of it — a one-line typo fix doesn’t need a review stage and a verify stage, and a risky change might need more scrutiny than the default gives it. An auto task hands that judgment call to the agent itself: file the task, and an agent reads it and builds its workflow to fit, picking only the stages the work actually needs from your workspace’s stage library.

Filing one

Create it like any other task, with --type auto:

ch task create --title "Rotate the staging API key" --type auto

From the web app, open the New task form and pick Auto from the type list.

An auto task can stand on its own, or nest under a story. It cannot attach to an epic — see Understanding the task hierarchy for the full nesting rules. Like most types, it’s staffed automatically: once you create one, CodeHerder assigns an agent and the composing stage starts on its own.

What happens next

An auto task starts in a stage where the agent’s only job is to decide the rest of the workflow — you’ll see it sitting in a stage literally called auto. It works in three beats:

CodeHerder staffs the composing stage. An agent reads the task and its acceptance criteria and judges how much process the work actually needs.
The agent selects and orders stages from the library. It reads what it’s allowed to choose from, then submits an ordered list — for example, code → merge for something small, or code → review → merge → verify for something that needs more eyes on it.
CodeHerder accepts the selection, builds the workflow, and moves the task into its first stage — all in one step. From that point on, the task runs the workflow the agent picked, just like any other task.

The agent can only pick stages that already exist in your library — it can’t write a new stage, change what a stage’s prompt says, decide whether it can commit code, or change the model tier a stage normally runs on. Every stage it selects keeps that content from your library (or CodeHerder’s built-ins) exactly as defined. What the agent does decide, beyond which stages and in what order, is how they’re wired together for this one task: how many times a stage may be sent back for rework, where a rejection routes to, and which model tier a stage escalates to if the same stage keeps getting rejected. That’s the trust boundary: the agent decides how much process a task needs and how its steps connect, never what a stage itself does.

What you’ll see afterwards

Once a workflow is composed, the task carries it as a fixed, per-task pipeline:

ch task show <taskId> prints workflow pin: auto_composed.
ch workflow show <taskId> prints the task’s full effective workflow, every stage and setting the agent chose.
On the task page, a Custom workflow badge appears next to the status, with a Custom workflow stages list showing what the agent chose.

An auto task only composes its workflow once. There’s no second round — the composed pipeline is what the task runs from then on, the same as if you’d set a workflow override on it by hand.

Once enough auto tasks of a given type have finished, Composition outcomes is where you find out whether letting the agent choose actually helped — success rate, turnaround time, and rework, compared against tasks of the same type that ran a hand-pinned or default workflow instead.

Bounding what it may choose

By default, the agent’s choice is unconstrained beyond what your library allows. If you want tighter guardrails — every composition must include a review stage, say, or every composition must stay within a named set of model tiers — set a composition policy for the workspace:

ch workspace composition-policy show
ch workspace composition-policy set --floor review --floor merge --ceiling model:sonnet --ceiling model:opus
ch workspace composition-policy clear

--floor <stageKey> (repeatable) names a library stage every composition must include. In the example above, any auto task’s chosen workflow has to contain both a review stage and a merge stage, in whatever order and with whatever else the agent adds around them.
--ceiling <model:tier> (repeatable) is an allow-list of model tiers, not a maximum — a composition is refused if any stage requires a model tier, or escalates to one on rejection, that isn’t literally on the list, even a tier that sounds “lower.” That escalation tier is exactly the one the agent sets per stage, described above. Name every tier you’re willing to allow.
set replaces the whole policy. Leaving out --floor when you run set clears the floor entirely — it doesn’t leave the existing one in place. Pass everything you want to keep.
clear removes your workspace’s own policy and falls back to whatever a parent workspace sets, if anything. Clearing a workspace that never set one of its own is a no-op, not an error.
The policy inherits down the workspace tree, the same way agents, repositories, and other shared resources do. show tells you whether what you’re looking at is your workspace’s own policy or one inherited from an ancestor.
Anyone in the workspace can run show. Setting or clearing one needs a workspace owner or admin, and only a person — an agent’s own credentials can’t change the policy, even one with an admin role.
There’s no web UI for the composition policy yet — it’s CLI and API only.

The floor only applies to a workflow built from library stages — the composition an auto task produces, or a workflow whose pipeline is composed from the library the same way (see The stage library). The ceiling is broader: it applies to any pinned per-task workflow, including one you set by hand with workflow overrides.

If a selection violates the policy, CodeHerder refuses it and lists every problem at once — every missing floor stage and every tier above the ceiling, not just the first one it finds. The agent gets the same list back and can fix everything and submit again; nothing is written until a selection passes, so a refusal costs nothing.

Guardrails worth knowing

The composing stage has exactly one way forward: composing. You can’t manually advance an auto task out of its composing stage before a workflow has been chosen — CodeHerder rejects the attempt and points at the composition step instead. You can still block, cancel, or archive the task from there, the same as at any other stage.
One composition per task. Once a workflow has been composed, there’s nothing left to compose — the task’s pipeline is already set.

When not to use it

If you already know the shape a piece of work needs — a bug fix that always wants review, a small change that never does — a story, bug, or task gives you that predictably, without the composing round-trip. Reach for auto when the right amount of process is genuinely the open question: a mixed backlog of odd jobs, or work where “does this need review?” isn’t obvious until someone reads it.

Composition outcomes — see whether letting the agent choose the workflow actually paid off
The stage library — the shared stages an auto task’s agent selects from
Customising workflows — build any workflow’s pipeline from the same library
Customising a task’s workflow — the composed pipeline behaves like a per-task override once it’s set
How work flows — what a stage, gate, and reject loop actually do at runtime
Writing tasks an agent can build — choosing a type and filling required fields