Nodes

The NodeFox 10-node system

NodeFox uses a compact 10-node system: Reader, Writer, Data, Wait, Buffer, Global, Conversation, Code, Decision, and Network. This is intentional. A smaller canonical system makes workflows easier to teach, easier to review, and easier to operate across engineering, operations, and business teams.

NodeFox is a directed graph runtime, not a DAG-only model. You can design loops when appropriate, but loops should always be bounded with explicit max-iteration and fallback behavior.

Why NodeFox keeps node types compact

Many workflow tools solve complexity by adding more primitive types. NodeFox solves complexity through composition. Instead of dozens of overlapping nodes, teams combine the canonical nodes into deterministic patterns using explicit slot contracts, activation edges, branch controls, and modular Network composition.

This approach scales better for real operations because teams can reason about behavior across many workflows without learning a different primitive every time.

Canonical node roles

Shared execution mechanics across nodes

All nodes participate in deterministic execution checks. They receive slot inputs, evaluate eligibility, and emit outputs through explicit routes. Slot references like $1, $2, and nested selectors are available across many configuration surfaces.

Important common flags include Optional (O, blue, per-slot non-blocking behavior), Activated (per-node activation requirement), Keep (K, green, per-slot state retention; Buffer exception applies across all slots when selected), and Delay (per-node eligibility deferral by graph steps/cycles). These controls should be used deliberately and documented for high-impact workflows.

In day-to-day implementation, most stability issues come from misunderstanding these shared controls rather than misunderstanding one specific node type. When teams define what each incoming slot means, when activation is optional, and what delay/optional behavior is allowed for each branch, workflows become easier to debug and safer to operate across engineering and operations handoffs.

Common field families and how to think about them

Across the 10-node system, configuration fields usually fall into a few repeated families: source/target fields, slot mapping fields, execution gating fields, and reliability bounds. Source and target fields define where data comes from or where side effects go. Slot mapping fields define exactly how values move between nodes. Execution gating fields decide when a node is eligible to run. Reliability bounds define what happens when data, tools, or dependencies are unavailable.

This means you can review any node configuration with the same practical questions. What enters this node and in what shape? What conditions must be true before it can run? What leaves this node and where can it go? What is the fallback behavior if this node cannot complete safely? When teams answer those questions consistently, graph complexity increases without destroying explainability.

Naming clarification

Legacy terms such as "LLM node," "trigger node," "input node," "output node," "transform node," and "HTTP node" may appear in older materials. They are not canonical NodeFox node types. Equivalent behavior is represented by canonical nodes and variants, primarily Conversation, Reader, Writer, Data, Code, and Decision compositions.

Deep references

Use the per-node pages below for detailed behavior, fields, variants, and configuration guidance.

• Reader Node
• Writer Node
• Data Node
• Wait Node
• Buffer Node
• Global Node
• Conversation Node
• Code Node
• Decision Node
• Network Node

Related guides

• Crucial Workflow Mechanics
• Execution Model
• Activation Edges
• Use Cases Guide