All nodes/AI/LLM
Messages
Assembles an array of messages (Messages) from several inputs. Only the number of Message input ports is set in the config. Any input value becomes a role=user message; if an incoming input is a Messages array, it is unpacked and inserted in place. The node waits for the inputs that start it; a value on an input that only carries data is taken only if its source has already run — set the order with a connection from the source's Success output. The history from Chat History already contains the current message: there is no need to add the Entry message to it.
Type in the graph: messages
An error output can be enabled to handle failures on their own path.
Ports can be split into separate execution and data handles.
Try it
Minimal working scenario
- Execute + Data
Runs as pasted
When to use it
This node assembles one conversation out of several inputs: a system instruction, a couple of question-answer examples, the history and the current question. Reach for it when the model needs a sequence of turns with different roles rather than a single one. A single turn is built by Message; if a plain string is enough, there is nothing to assemble — the LLM nodes accept it as a user turn. An ordinary chat scenario does not need this node: the history comes from Chat History, its array already ends with the current message, and the LLM nodes take it on their Message port whole.
How it works
The configuration holds only the number of ports — from 1 to 20, two by default. The ports are named Message 1, Message 2 and so on, and the result is assembled in port order, not in the order the branches happened to finish.
Every port accepts any value. A string or an object becomes a turn with role user; a ready message passes through unchanged; an array of messages is unpacked and spliced in place — which is how a whole history arrives over a single edge.
The node waits for the ports whose connections start it. Unconnected ports are simply skipped. If a port’s branch never ran — the untaken branch of an If, say — the node does not hang; there just is no message from that port. A port that receives data only (Chat History’s output, for instance) does not hold the node back when another input starts it: its value is taken only if the source has already run. To keep such a port from arriving empty, draw a connection to the node from the source’s Success output.
Common mistakes
- Splicing the history with the Entry message. The Chat History array already ends with the current message — added again, it reaches the model twice.
- The question is not last. The agent treats the last turn with role user as the prompt; if the array ends with a system or assistant turn, everything travels as context and no question is left. Put the current question in the last connected port.
- Reducing the port count without removing the edges first. The extra ports disappear along with their inputs, the edges stay dangling, and the graph fails validation. Disconnect the edges first, then lower the counter.
- Expecting the node to concatenate texts. The output is an array of turns with roles, not a single string. Joining texts into one paragraph is what a Template is for.
Inputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Message 1msg_0 | Execute + Dataexecute_data | message |
Outputs
| Port | Wire | Payload | Notes |
|---|---|---|---|
Messagesmessages | Execute + Dataexecute_data | messages |
Configuration
| Field | Type | Default | Description |
|---|---|---|---|
Message portsport_count | integer | 2 | Number of Message input ports |
Shared fields
Every node has these three — the platform adds them, not the node author.
expose_error_output— When enabled, show an execution output to connect nodes that run if this step fails.split_ports_in— Show separate execution and data input handles instead of one combined port.split_ports_out— Show separate execution and data output handles instead of one combined port.