Atomic workflows

Atomic workflows divide engineering work into units with a specific task, a defined output and explicit acceptance criteria. Reusing workflows makes results comparable across runs and provides evidence for improving how the work is done.

An atomic workflow uses atomic task decomposition to define the work needed to produce an acceptable result. In the example below, an agent creates an artifact and other agents evaluate it against defined criteria. The workflow returns findings for revision or stops when the revision limit is reached. When evaluations pass, it asks a person to approve the artifact before accepting it.

An agent task specifies a harness, model and effort level, with versioned skills providing its instructions. It defines the context the agent receives, the tools it may use and the expected outputs.

Why organise work this way?

• Make acceptance checks precise. Defined tasks let you specify requirements for each output. Deterministic checks can identify which requirement failed and which task needs attention. Qualities that require judgement can be evaluated by agents or people.
• Route work according to its results. Individually evaluated outputs let the workflow accept a result, repeat a task with findings, or take another defined route. The route responds to the results; the rules for selecting it remain deterministic.
• Choose where people intervene. Defined steps let you place human decisions where they are needed. In this example, agents author and evaluate the artifact, but acceptance waits for human approval. Other workflows can reserve different decisions for people.
• Build evidence across issues. Reusing workflows across different issues accumulates runtime evaluations against the same criteria. These provide evidence for improving the workflow and comparing harness, model and effort configurations for quality, cost and completion time.
• Focus the agent’s context. Each task receives the inputs, instructions and evidence needed for its result, reducing the need to carry the history of an entire issue into every agent session. Context Orchestration explains how that information is selected.

Spec-driven development

Spec-driven development is one way to organise an issue into atomic workflows. A specification defines the required behaviour, a plan determines how to implement it, and verification checks the resulting change against the specification. Each workflow evaluates its own output before handing it on.

GitHub Spec Kit

Framework docs ↗

1. 1 Specify Atomic workflow
2. 2 Plan Atomic workflow
3. 3 Tasks Atomic workflow
4. 4 Implement Atomic workflow
5. 5 Converge Atomic workflow

The short-form process, after establishing project principles. Converge checks implementation against the specification, plan and tasks.

Kiro Specs

Framework docs ↗

1. 1 Requirements Atomic workflow
2. 2 Design Atomic workflow
3. 3 Tasks Atomic workflow
4. 4 Implement Atomic workflow

The requirements-first process, from defining behaviour to implementing the tasks. Kiro also offers a design-first variant.

OpenSpec

Framework docs ↗

1. 1 Proposal Atomic workflow
2. 2 Specs Atomic workflow
3. 3 Design Atomic workflow
4. 4 Tasks Atomic workflow
5. 5 Implement Atomic workflow

The default artifact flow, shown in sequence. Specs and design can be prepared in parallel after the proposal.

Runtime evaluations and improvement

Runtime evaluations provide evidence for improving workflow instructions, context, checks and routing, and for comparing harness, model and effort configurations. Proposed changes can then be evaluated for quality, cost and completion time before adoption. Self-Improvement explains how those changes are assessed and authorised.

See Workflow Engine for how Nucleus defines and executes these workflows.