node
On this page
What is a Node?
A node is the primitive building block on the canvas. Every visible element — a flowwLITE conversation, a file reference, a note, a diagram — is a node. Nodes are the atoms of the floww workspace. They can be created, positioned, connected, and composed into workflowws.
Each node has a type that determines its behavior. Some node types execute actions (like flowwLITE, which runs Claude). Others hold static content (like notes or file viewers). Some transform data between other nodes. But they all share the same fundamental properties: a position on the canvas, optional input/output ports, and a visual representation.
Connecting Nodes
Nodes connect to each other through ports. An output port on one node connects to an input port on another, creating a directional flow of context. These connections define the structure of a workfloww — they determine what information flows where, in what order, and through what transformations.
Connections are visible on the canvas as lines between nodes. This visibility is intentional: you can see the flow of information through your workfloww at a glance, identify bottlenecks, and understand dependencies without reading code or configuration files.
Node Types
The floww client supports multiple node types, each designed for a specific purpose. flowwLITE is the most important — it is the node that executes Claude. Other node types include file viewers, text notes, image viewers, and custom nodes. The set of available node types grows as the client evolves.
Nodes as First-Class Objects
In floww, nodes are first-class objects. They have identity (each node is uniquely addressable), state (nodes remember their content and configuration), and history (nodes participate in stamps). This means you can reference, link to, and track individual nodes over time.
Why It Works This Way
In most development tools, the atomic unit is the file. In floww, it is the node. This is deliberate. Files are invisible — they sit in directories, behind tabs, organized by convention. Nodes are visible — they sit on the canvas, connected to other nodes, spatially arranged by intent. When the atomic unit is visible and connectable, you can compose workflows that a file-based system cannot express. A flowwLITE node feeding its output to a code analysis node feeding into another flowwLITE — that pipeline is visible on the canvas as a chain of connected boxes, not as an abstraction buried in configuration. Making nodes first-class objects means making the flow of work first-class, not the files that result from it.
In Practice
You are building a code review pipeline. A file reference node points to the PR diff. It connects to a flowwLITE that asks Claude to analyze the changes. The flowwLITE’s output port connects to a second flowwLITE that generates review comments based on the analysis. On the canvas, the pipeline reads left to right — diff in, analysis in the middle, review comments out. Each node is independently inspectable. You click the analysis node to read Claude’s reasoning, then click the review node to see the generated comments. The composition is visible and the data flow is traceable.