The palette is the panel in the visual editor you drag from — or click — to add steps to a draft. It carries 138 node types in 17 categories. This page is the index: one honest line per node, so you can find the right one without placing it first. Exact inputs and outputs are deliberately not here — pin-level signatures belong to the agent reference.
Primitives propose, verbs commit: brain nodes never write by themselves, state-changing service nodes are gate-guarded on every path, and the run's repository delta merges only when you accept the run.
Four conventions cover almost everything, so we state them once:
Every node sits on the Exec spine. Execution wires order the steps; data wires carry the values. See Anatomy of a workflow.
Almost every node emits one JSON result. 125 of the 138 end in a single result output that downstream nodes consume.
A few hand you a typed handle as well — a run id, an incident id, a lease id, or a workspace — which you wire straight into the nodes that need it.
Families come in threes for fan-out. Many service families ship a prepare (or load) node, a per-item node built to sit inside a fan-out body, and a reduce node that folds the items back together (analyze, aggregate, finalize, score or submit-report). Rows marked (per-item) below are the middle piece.
One thing you will not find in this catalog: the flow-control constructs. The palette's Structural section carries the tiles — Trigger, Approval Gate, Branch / Switch, For Each, Map / Fan-out, Wait (timer), Wait (event), Workflow Reference and the Comment frame — and Finally, which has no tile and is authored through the graph payload. They all have their own page.
Six of the 138 are generative — they call a model. Four are wired call-sites with a fixed job:
Missions:Decomposition turns a mission objective into a proposed task breakdown.
Coder:Default dispatches one coder task and waits for the resulting artifact.
Coder:AsyncDefault dispatches coder work and routes what happens next down outcome arms — onSuccess, onFailure or onRefusal. It is one of the palette's two multi-arm nodes — the other is service:mission:integrate, under Git; see Outcome arms.
ReviewEngine:Default reviews an artifact and produces findings.
Two are generic:
llm runs one bounded model turn over its input. It has no tools, by construction.
agent runs a multi-turn agent loop with an explicit toolset and a mandatory budget. Several built-in sys- flows now use it — one dispatches ten agent nodes. For your own graphs, llm or a coder is still the simpler first reach unless you know why you need it.
The discipline is the same for all six: primitives propose, verbs commit. A brain node never writes anywhere by itself. Its output reaches the world only through explicit service nodes downstream — and on every such path, a gate stands before the write.
Reads — 20 nodes. They fetch state and change nothing: a mission's details, a file from a branch, a project's onboarding progress. Safe to place anywhere.
Workspace actions — 2 nodes.workspace:write_file and workspace:create do write — but only inside a sandboxed workspace. They never touch your repository.
Service operations — 110 nodes. One platform operation each: create an incident, classify a support case, run a compliance check, push a branch. The ones that change platform state are exactly what the gate-dominance rule guards.
You can usually read the kind off the id: read: fetches, service: operates, and the workspace file verbs live under workspace:.
Deterministic checks — the platform evaluates them mechanically; no model writes a compliance verdict. Grouped by regulation family: cra-* (Cyber Resilience Act), pld-* (product liability), aiact-* (AI Act), nis2-* (NIS2).
One node on the palette is legacy: service:research:llm, an early research step superseded by the generic llm node. The validator blocks it at publish in new drafts. Workflows you already published are frozen graphs, so they keep resolving as they were.
