Workflow stage (stage)

What it is

A workflow stage is one step in a task's life, from being filed to being finished. A typical sequence is plan, then code, then review, then merge, then verify, then done, but the sequence itself is configurable per task type. Each stage either has an agent doing the work, or is a gate a human has to clear, and a task can only move to the next stage once its current one is actually finished.

Why it matters to you

Stages are where quality control actually lives. If "review" is a real stage with its own agent or person, rather than a rubber stamp on the way to "merge," a wrong answer has a real chance of getting caught before it ships. Ask what a workflow's stages actually check. The stage count alone tells you nothing: five stages that all rubber-stamp are worth less than two that genuinely disagree with each other sometimes.

How it works in CodeHerder

CodeHerder lets a workspace define its own sequence of stages per task type, and each stage can require specific fields, approvals, or checks before a task is allowed to advance. That configurability means a bug fix and a database migration don't have to move through the same gates: the riskier one can carry an extra approval the simple one skips. How work actually flows through those stages, including which ones spawn an agent and which are just a bridge to the next one, is explained in the how work flows doc, with the bigger picture on how it works.

• How it works →
• How work flows →

What people get wrong

It's easy to assume every stage in a workflow runs an agent. Some stages, like "todo" or "done," are just bookkeeping: nothing runs there, they're places a task sits before or after the real work happens. It's also easy to assume a longer pipeline is automatically safer. A stage only adds real safety if it's actually configured to check something; an empty stage just adds a pause.