These MAP-specific node graphs can then be further processed to generate executable code. In our case, this step is rather straightforward since the nodes are directly generated from the high-level methods of the python API controlling our MAP, but in principle, they can also be used to generate e.g., XDL code that can then be executed. It should be noted that in general, some user input is still required before converting the node graph to executable code. Besides cleaning up any incorrect actions, this typically also involves specifying the positions of the required starting materials and reagents on the platform, as well as the reaction vessels that should be used during the reaction. For commonly used chemicals (such as solvents) and "fixed" containers (such as waste containers) that are always connected to the same ports of a valve, these can of course also be hard-coded into the node generation process and be saved as part of the hardware configuration of the MAP. The same applies to cases in which always the same chemicals are used for the reactions run on the MAP, e.g., during one synthesis campaign. In more material-agnostic MAPs that are generally used in a research-centered environment with constantly changing reactants, reagents, and target materials, this step is typically left to the user. A full example of this processing pipeline from natural language input to an action graph (Example 2 in Table , SI), a node graph (Figures S4, SI), and executable python code (Table , SI) is given schematically in Figure and in more detail in the supplementary information.