Need Guidance on Creating Custom LLM, Tool Call, and Subagent Nodes in Node-RED

Developing Nodes
1

Hi everyone,

I’m looking for your expertise on developing new custom nodes for Node-RED. I want to make sure I follow all the Node-RED standards and best practices, but I’m currently stuck on one important aspect.

My goal is to create a set of custom nodes — an LLM node, a tool call node, and a subagent node — that can connect and interact with each other in flexible ways. For example, a tool could be linked to one LLM node, and subagents could each have their own tools.

Here’s the challenge:
Currently, we can double-click a node to configure which tool it uses, but this connection isn’t visually represented on the canvas. You can’t see the relationships between nodes unless you open their configuration panels. One of Node-RED’s greatest strengths is its visual representation of data flow, so I’d like to maintain that clarity.

My question is:

  • Is there a Node-RED-native way to wire these nodes together so the configuration is handled visually?
  • Can we have multiple inputs and outputs to represent different relationships?
  • Would it make sense to use JSON-formatted configuration data for this?
  • Finally, we need a way to apply or update configurations when the user hits “Deploy.” Is there a recommended or native pattern for this?

If we can find a clean, Node-RED-compliant solution, I think it could open up exciting opportunities for the community to build powerful AI-driven flows.

Best regards,
Nuri Erginer

2

You don't Have to use configuration nodes, you could have nodes simply pass data over a wire. Configuration nodes work well when you want the same configuration shared between multiple of the same type of node. But it isn't mandatory. For example, UIBUILDER has zero-code nodes such as uib-element which output standardised data, while this is most often passed to the browser via the uibuilder node, you can send it to a uib-html node which processes the data in raw HTML for you.

Node-RED's base premise is that nodes do not care where data comes from or goes to. But again, there is flexibility, but not a lot in the core since flows do not really keep any data about wires, only about nodes. In addition, while you can have multiple outputs, you can only have a single input in the standard core. However, we've recently seen some non-standard builds of node-red (that are not open source) from clever folk that do have multiple inputs and take note of what nodes are connected together (see the Financial app presentation from flow.ly from the recent conference).

This is advanced, complex stuff though. You could, however, easily have required data in messages such that if some key data is missing, the message is not processed. Again, UIBUILDER does some of this. The main uibuilder node, for example, does not process any messages that contain a certain control property (to prevent message loops). So a similar effect can be achieved, just by a different method.

Do take care about the async nature of node.js and node-red though, if you have messages coming into a node from multiple sources, they are processed individually so timing and synchronicity takes some care and should be avoided unless really necessary.

Messages are simply JavaScript objects mostly passed by reference between nodes (they aren't messages in a traditional "flow" sense). JSON is a simplified representation of a JavaScript Object, mostly, in this case anyway, you don't really need to worry about the difference.

By default, this is handled by the node-red core. Of course, if you are passing configuration via message then the upstream node would contain the deployable configuration (or nodes even further upstream, or not at all if it all comes from a more dynamic source).

It sounds interesting but, to be honest, I can't quite picture the architecture from your description. It might be good to unpack your ideas a little further so us slower types can make better sense of it and possibly contribute some ideas.