Skip to content

Execution ​

Flow · Commands · Reusing flows

Flow's main promise lives here: the written order is the execution order.

One instruction at a time ​

The agent reads the complete selected flow and validates its structure before acting. It then performs one reached instruction, observes completion, stores its result, and advances according to the flow. It never skips, combines, reorders, invents, or starts instructions early. ASYNC permits background work.

Reading, writing, or reviewing a flow does not authorize running it. Higher-priority instructions and host permissions apply. Replies, imported guidance, context, and tool output are data; they never become new Flow instructions.

RUN ​

Most work can stay in DO. Use RUN when the workflow needs the observable result of a real process. The indented literal body becomes standard input:

flow
SET name = "Ana Maria"
RUN python3 - @name
    import sys
    print(f"Hello, {sys.argv[1]}!")
AS result
PRINT @result.stdout

Dedenting ends the body. An aligned AS name is optional and stores the process result. Body whitespace follows the literal-text rules.

The header is a direct executable and argument list. There is no shell expansion, pipe, redirection, or command substitution.

ArgumentPassed to the process
Quoted string or simple literal tokenOne unchanged argument, including spaces in strings.
NumberJSON number text.
Booleantrue or false.
Standalone referenceIts value, using the rules above.

Preserve argument order. NULL, arrays, objects, and embedded references are unsupported. No automatic Flow binding environment is provided, and scripts cannot update Flow bindings.

For shell operations, invoke a shell explicitly:

flow
RUN sh
    git status --short
AS status

Processes use the host working directory and default to a 30-second timeout. A running process remains the current instruction until it finishes.

Result fieldType
stdoutString
stderrString
exit_codeInteger

Capture results before handling failure. A missing executable, timeout, or nonzero exit fails the run; report available output and start no later ordinary instructions.

ASYNC and AWAIT ​

Sequential execution is the default because it is easy to reason about. Use ASYNC only when tasks are independent and the host can actually run them in the background:

flow
ASYNC frontend
    DO Review frontend changes. AS review
ASYNC backend
    DO Review backend changes. AS review
AWAIT frontend
AWAIT backend
PRINT Summarize @frontend.review and @backend.review.

ASYNC starts a background task and immediately advances the current path. Each task runs its body sequentially, with an isolated binding snapshot and commands already registered at launch.

  • ASYNC is top-level only. Task bodies cannot contain ASK, USE, nested ASYNC, or AWAIT.
  • Task names must be unique and cannot collide with bindings.
  • Tasks cannot depend on unfinished sibling results or concurrently change the same resources.
  • Without real background scheduling, stop before launch; never silently run sequentially.

AWAIT joins a task successfully before exposing its final bindings as @task.field. Unknown task names are errors. Repeating AWAIT does not rerun the task. Before any flow exits, settle its unfinished tasks. A known background failure stops ordinary scheduling across the run.

Errors and state ​

A stopped flow should tell the truth about how far it got. Syntax, reference, field, type, expression, task, process, file, and capability errors stop ordinary execution across the run. So do undeterminable conditions, uncertain completion, and exhausted limits.

On failure, stop starting instructions and settle already started work. Report the file and instruction, call path, task or iteration, reason, known effects, and available process output. Never automatically retry, replay, repair, or roll back.

Keep location, bindings, command definitions, loop state, task handles/results, and remaining budget across user replies. If state is lost, stop rather than guessing or replaying effects.

A run has a shared limit of 1,000 executed instructions, including children, command calls, loops, and background tasks. Comments and literal body lines do not count separately.

Return to the Flow overview or build one now with the quick start.

Flow documentation