Flownix
Sections
On this page

The decision lifecycle

How the runtime routes steps, gives agents context, shares a deliberation, requests human approval, and creates tracked work.

  1. 01Version
  2. 02Run
  3. 03Work item
  4. 04Deliberation
  5. 05Decision
  6. 06Approval
  7. 07Flownix nodes

Typical flow

  1. A person starts a published version with input and source_node_ids.
  2. The runtime starts every node without an incoming edge. Agent nodes expose work through work.list_available.
  3. An agent claims a lease and calls work.get_context for the run, role, predecessor outputs, and council data.
  4. The step output carries result_artifact_ids, optional structured output, and an explicit outcome. Matching outgoing edges start the next steps; several matches fan out in parallel.
  5. condition evaluates data, while loop repeats its body until its exit condition or max_iterations.
  6. Council nodes with the same config.deliberation_key share proposals, critiques, ballots, and decisions. debate can open more rounds; vote or judge records the decision.
  7. A human_gate moves the run to waiting_for_user. Approval follows the approved edge; rejection is an outcome = "rejected" branch, not a failed run.
  8. After a mandatory human gate, create_flow_nodes can create the confirmed output.flow_nodes through core-service. end completes the run.

What runs where

Flownix is the coordination plane. The harness-service advances the graph, opens work, enforces leases, retries, step and gate timeouts, tools policies, and the run budget. External agents perform the assigned analysis in their own environment and return structured results over MCP.