Task Dispatcher

When a task becomes a project, the project's task dispatcher turns it into a graph of nodes — and the graph turns the nodes back into a finished result.

This page is a preview skeleton — detailed content is being expanded.

Projects and nodes

• A project owns a workspace and a graph — the plan of record, visible on the Flow Map and rewirable while work runs
• A node is one agent session on the general base: a task description plus the plugins the job needs
• Nodes are lightweight — no memory, no identity of their own; everything that matters is written into the graph

Wiring: in, deps, out

• in — barrier input: the node waits for its upstreams and receives their results into its context
• deps — ordering only: the node starts once its dependencies complete, but nothing is delivered
• out — the result channel: a node's final message is its result, delivered along the out edge; at most one out edge per node

Lifecycle

• A node with a task and no inputs is an entry node — it starts running the moment it is created
• Node states are visible on the graph: waiting, running, completed — plus failed and cancelled
• A failed node can be re-dispatched without redoing the rest of the graph; completed results stay put

The dispatcher session

• The dispatcher itself is a session: it reads the current graph, splits the task, creates and wires nodes, then ends
• The graph is the persistent state — decomposition can continue later in a fresh session exactly where it left off