reference
Living

the Kitchen

A node-and-wire canvas for building recipes: the repeatable procedures a session, or a worker it spawns, runs from a graph of typed steps wired together, instead of one long prompt.

Most of what a session does gets written down once, in a prompt, and the next session that needs the same procedure reconstructs it from scratch. The Kitchen is where a procedure gets built instead: nodes dragged onto a canvas, wires drawn between them, the whole shape of a multi-step job sitting there before anything runs. It's the newest part of the product, and the one we've talked about least on this site, mostly because it's better shown than described.

§01 · the canvas

A canvas for building recipes.

Open the Kitchen and you're looking at a canvas: blocks you drag in, wires you draw between them, a procedure taking shape as a picture instead of a paragraph. Anyone who's used a node-based editor like ComfyUI already knows the motion: you connect typed blocks, and the procedure sits there as a shape you can look at rather than a paragraph you have to re-read.

What gets built on that canvas is a recipe: a repeatable procedure a session, or a worker it spawns, can run again later exactly as wired. Write the steps once as nodes, and the next session runs the graph rather than re-reading a paragraph to figure out what to do.

§02 · what a node is

A node is one typed step. A wire is where its output goes.

A node is one step, and it comes with a kind stamped on it: ask a question, call a model, spawn a worker, gather what came back, judge a result against a rubric, save a value for later. Each kind has a job and a shape: inputs it needs, an output it produces.

A wire is where one node's output goes. Draw a line from ask into judge and the dependency is sitting on the canvas in plain sight: judge's evaluation depends on what ask returned, instead of living in a sentence three paragraphs into a prompt that's easy to skim past.

§03 · why a canvas, not a prompt

A prompt describes a procedure once. A graph keeps it.

A prompt gets read once, and the exact sequence behind it disappears with the response: the next session that needs the same procedure has to reconstruct it from memory or from scratch. A graph stays put. Change one node's wiring and the rest of the recipe doesn't need re-explaining in prose; the parts you didn't touch are still sitting there, still wired the way they were.

It's close to the difference between giving someone spoken directions and handing them a wiring diagram. Repeat directions from memory and each retelling drifts a little; a diagram just sits there, the same shape every time anyone looks at it.

§04 · the vocabulary

Twenty-three node kinds, locked. Twenty-two run today.

The backend locks a fixed set of node kinds for v2 recipes, twenty-three of them, and only one is actually excluded from running: publish. Two other names turn up in old references, parallel and join, but those are retired v1 primitives that predate the v2 vocabulary; they were never real v2 kinds to begin with. Net result: twenty-two of the twenty-three locked kinds execute today (#13048).

The seeded catalog holds fourteen recipes, and most lean on an older, simpler vocabulary than the one the Kitchen exposes; see cookbook & recipes for the honest count. One recipe, scout-and-brief, puts the fuller v2 vocabulary through its paces: its live graph wires fifteen nodes together, one of each of fifteen distinct kinds (#13048).

askenumeratefan_outgategatherinputjudgemodelpreviewrecallreferencerubricsavespawnstep
§05 · the receipt

The eligibility check, run for real.

Checking whether a graph can actually run through the recipe engine is one function call. Run against scout-and-brief's live graph, recipe_runtime._graph_is_walker_eligible() returns True: the graph is walker-eligible (#13048).

That check is static: it reads the graph's shape and confirms every node in it is one the walker knows how to execute, without starting a run. That's a smaller claim than saying it ran successfully end to end (#13048).

What was measuredThe number
v2 node kinds locked23
of those, execute today22 (publish is the one real exclusion)
recipes in the seeded catalog14
nodes in the scout-and-brief graph15, one of each distinct v2 kind
walker-eligibility checkTrue, from static analysis (no run was started)
sourceVinculum substrate entry #13048
§06 · common questions

Common questions.

What's a 'node kind,' exactly?

A node kind is the type stamped on a node when you place it on the canvas: ask, judge, spawn, gather, and the dozen others. Picking a kind fixes what a node needs as input and what job it does; the vocabulary of kinds is locked in the backend, twenty-three of them today (#13048).

Does every recipe in the Kitchen run today?

No. The seeded catalog holds fourteen recipes, and most of them still lean on an older, simpler vocabulary than the full v2 node set the Kitchen exposes. See cookbook & recipes for the honest count of what actually executes (#13048).

Is this a general-purpose visual programming tool?

Narrower than that. The node kinds are fixed and typed: ask, gather, judge, spawn, and the rest of the locked set, rather than an open vocabulary you extend yourself. The Kitchen is built for wiring together the steps a session or a spawned worker takes, not for general-purpose computation (#13048).

see also

Related entries.

architecturethe Kitchen
watch it happen1
the dashboard