Workflows declare what completion means

A workflow is a decision structure

The selected workflow package declares more than a list of prompts. It can define graph nodes, external intake routes, legal terminal markers, artifact schemas, handoff projections, runner bindings, timeouts, retries, waits, quarantine, and completion behavior.

The compiler validates those references and produces the plan that the runtime admits. This is why Millrace can support different domains without adding a domain-specific branch to the kernel.

One stage at a time

For a normal stage, the daemon finds work eligible under the selected plan, claims one activation, materializes only the selected prompt and skill assets, dispatches to the selected runner, authenticates the returned evidence, validates the marker and artifact payload, and applies the declared route.

Fanout and join behavior follow the same rule. The graph declares what branches create, what evidence they carry, and when a join is legal. The agent output is an input to that process, not the source of routing authority.

Different workflows, different closure

A simple loop may close after a review accepts the work. A software-development workflow may require remediation and more evidence. A purchasing workflow may stop at an operator decision. Completion is valid only when the selected workflow declares the action and the kernel applies it to current durable state.

Read the workflow package model and the getting-started path for the current source-backed shape.