For AI agents: the complete documentation index is available at https://a3s-lab.github.io/Flow/en/llms.txt, the full documentation bundle is available at https://a3s-lab.github.io/Flow/en/llms-full.txt, and this page is available as Markdown at https://a3s-lab.github.io/Flow/en/nodes/index.md.

Node catalog

A3S Flow 1.1 provides 18 nodes that authors can place on a canvas. After choosing a node, you can configure it, connect ports, and validate the full graph in the Playground, or generate the same structure through the CLI. Fields, defaults, ports, runtime bindings, and durable identity rules all come from one manifest catalog.

iteration-start and loop-start are internal container entries. The editor creates them with their container. They do not appear in the node picker and cannot be placed on the top-level canvas.

Node workbench

This workbench uses the public @a3s-lab/flow-ui components. Selecting a node gives the canvas card and configuration panel the same node object. Title, description, and field edits update the preview immediately. Waits, callbacks, batches, child workflows, and containers use dedicated controls.

18 nodes, one configuration model

Select a node and edit it in place. Canvas cards, settings, ports, and emitted DSL all read from the same manifest catalog.

18 nodes
Canvas previewEdits update the canvas card immediately
Upstream node
Run Step
Handler
task.run

Run one registered task, retry when needed, and save its result.

2 inputs · 2 outputs · 5 settings
Next node
Configuration panel

Run Step

Execution

Registered task that this step runs.

Step input

Choose the workflow data sent to the task.

Use the value from input.

Advanced · 3 optional settings

Retry policy

Total attempts for this step, including the first execution.

Wait time before the next attempt. Use 0 to retry immediately.

End the run, or continue from the failure branch.

Manifest contract5 fields · 6 ports

Node metadata

Type
flow.step
Category
Task execution · durable-work
Icon
Documentation
https://github.com/A3S-Lab/Flow#runtime-model
Manifest version
1
Owner
host
Role
runtime-command
Runtime binding
schedule_step
Stable ID
graph_node_id
Container start
Base classes
A3SFlowNode
Input types
FlowValue
Output types
StepResult · StepError
Flags
Official
Internal
No
Official
Yes
Tool mode
No
Beta
No
Legacy
No

Port contract

Inputs

  • Inincontrol · FlowControl
  • Inputinputdata · JsonValue

Outputs

  • Successsuccesscontrol · FlowControl
  • Resultresultdata · JsonValue
  • Recoverable failurefailedcontrol · FlowControl
  • Recoverable errorerrordata · String

Output definitions

  • ResultresultStepResult
  • Recoverable errorerrorStepError

Field contract 5 fields

  1. Step handlerstep_name
    Default
    textinputRequired

    Defaulttask.run

    Manifest properties
    • _input_typeStrInput
    • display_nameStep handler
    • infoRegistered task that this step runs.
    • namestep_name
    • placeholdertool.execute
    • requiredtrue
    • typestr
    • ui_groupexecution
    • ui_group_labelExecution
    • valuetask.run
  2. Step inputinput
    Default
    a3s.flow.expressioninput

    Default{"apiVersion":"a3s.dev/flow-expression/v1","expression":{"op":"field","path":"input"}}

    Manifest properties
    • _input_typeA3SFlowExpressionInput
    • display_nameStep input
    • expression_purposeinput
    • infoChoose the workflow data sent to the task.
    • input_types["FlowValue"]
    • nameinput
    • typedict
    • ui_groupexecution
    • ui_group_labelExecution
    • value{"apiVersion":"a3s.dev/flow-expression/v1","expression":{"op":"field","path":"input"}}
  3. Maximum attemptsmax_attempts
    Default
    numberruntimeRequiredAdvanced

    Default3

    Manifest properties
    • _input_typeIntInput
    • advancedtrue
    • display_nameMaximum attempts
    • infoTotal attempts for this step, including the first execution.
    • namemax_attempts
    • range_spec{"min":1,"max":100,"step":1}
    • requiredtrue
    • typeint
    • ui_groupretry-policy
    • ui_group_labelRetry policy
    • value3
  4. Retry delay (ms)retry_delay_ms
    Default
    numberruntimeRequiredAdvanced

    Default0

    Manifest properties
    • _input_typeIntInput
    • advancedtrue
    • display_nameRetry delay (ms)
    • infoWait time before the next attempt. Use 0 to retry immediately.
    • nameretry_delay_ms
    • range_spec{"min":0,"max":86400000,"step":100}
    • requiredtrue
    • typeint
    • ui_groupretry-policy
    • ui_group_labelRetry policy
    • value0
  5. If all attempts failon_exhausted
    Default
    selectbehaviorRequiredAdvanced

    Defaultfail_run

    Manifest properties
    • _input_typeDropdownInput
    • advancedtrue
    • display_nameIf all attempts fail
    • infoEnd the run, or continue from the failure branch.
    • nameon_exhausted
    • options[{"label":"End run as failed","value":"fail_run"},{"label":"Continue from failure branch","value":"continue_workflow"}]
    • requiredtrue
    • typestr
    • ui_groupretry-policy
    • ui_group_labelRetry policy
    • valuefail_run

Inspect the full manifest contract

Open Manifest contract at the bottom of a selected task panel to inspect the same metadata that drives the editor. It lists the manifest version, owner, role, runtime and stable-ID bindings, flags, every input and output port, and every field in declaration order. Each field reports its A3S UI control, semantic group, required, advanced, read-only, conditional, visibility, current-value state, and the complete set of manifest property names and values. Secret field values are masked.

The contract is a projection of the live node rather than a second schema. The same field visibility helper feeds the form, validation, and contract view. The document action exports the resulting node configuration, including values that are currently hidden by a condition, so a saved graph remains lossless.

Six groups

GroupNodesResponsibility
OrchestrationStart, ConditionAccept input and choose deterministic control branches
Tasks and toolsRun step, Step batchCall host tasks and store results, errors, and retry state
Wait and approvalWait until, Callback and approval, Signal waitRelease workers while waiting for time or external input
Child workChild operation, Child workflow, Child workflow batch, Continue as newTrack long jobs, own child runs, and continue history
Run stateProgress, Complete, Fail, Cancel, TimeoutRecord inspectable state and close run segments
Child-canvas containersIteration, LoopEstablish graph scopes and constrain parent, child, and edge relationships

Choose from the task in front of you

Use Run step for one host task after input arrives. Use Step batch when a set of tasks needs per-member results and retry state. Both require a real task handler registered by the host.

Use Wait until for a time boundary, Callback and approval for an approval or one callback, and Signal wait when an existing business channel resumes the run by name. All three release the worker while waiting.

Use Child workflow when a unit of work needs its own history, state, and cancellation policy. Use Iteration to apply one child graph to a collection, and Loop when a condition controls repetition. Ordinary graph edges remain acyclic.

Runtime binding

Nodes with a runtimeBinding compile to durable A3S Flow runtime commands. flow.start and flow.condition execute at the graph layer. iteration and loop define child-canvas structure, while the host decides how each pass compiles into steps or child workflows.

Task and wait nodes normally use the graph node ID as durable identity. Batch nodes also include each member key. Changing those IDs after a run starts prevents replay from matching the original history.

Every individual node page includes the following material.

  • Intended use and runtime behavior
  • Every field, default, control, range, option, and visibility condition
  • Control and data ports
  • Runtime binding and durable identity rules
  • Complete node JSON, CLI commands, and a Skill prompt
  • Recovery, retry, cancellation, and container-scope notes

When configuration validation fails

Start with the reported path and locate the exact node and field. Field errors usually mean a required value is empty, a number is out of range, or a dependent setting no longer matches. Edge errors usually mean incompatible port types, an occupied input, a cross-scope connection, or a cycle.

Do not delete unknown fields merely to silence validation. Check the node page for its current fields and ports, then validate again in the Playground or CLI. Preserve node IDs after runs exist because steps, hooks, progress records, and child runs use those IDs to match committed history.

Verify the catalog with the CLI

The installed catalog ships with the front-end components. Inspect the current version before creating a node.

a3s-flow nodes --pretty
a3s-flow node flow.step --pretty
a3s-flow new flow.step --id charge-order --pretty

After adding nodes to the graph, run validate, compile, and digest. The CLI checks fields, ports, scopes, cycles, and deterministic execution order.