I just wanted to give you something to think about, even though you probably know this already.
Workflow engines also go under the name “process managers” and “sagas”. There’s also stream processing which has gained A LOT of traction lately, in particular projects like [https://flink.apache.org/stateful-functions.html](stateful functions).
There’s also a concept called complex event processing, which is a sub-set of stream processing, and lets you use temporal (time oriented) logic to program when what should trigger.
There’s also single-process level stream processing, most prominently with RxJS (and for all the other languages too). A sub-spieces is dependency networks like Excel cells, and a super-species is reactive demand programming which noone has picked up the last five years at the time of me writing this (to my knowledge)
Finally, workflows in games, are normally built using Behaviour Trees — in particular this is a great paper to implement it from. Behaviour trees are a super-set of almost everything I’ve found in n8n, while allowing greater control of concurrent processes that change state while the workflow is executing. The up-side of using such an abstraction is that you can use a designer for it https://assetstore.unity.com/packages/tools/visual-scripting/behavior-designer-behavior-trees-for-everyone-15277 and many people who have programmed game NDC behaviour can use it “easily”.
So when you’re thinking of what “aggregate nodes” mean, be aware that there’s a lot of research. The more correct you make your workflow engine, the more you’ll go towards stream processing. A good intro paper to the topic is actually the MillWheel paper — and later you can read the Flink series.
I sincerely hope I haven’t interrupted your product planning with this