So if it's a long running task that's definitely a more complex problem that would require some sort of queue/pause/resume system presumably but I imagine the s

So if it's a long running task that's definitely a more complex problem that would require some sort of queue/pause/resume system presumably but I imagine the same concept could still apply. The node that merges context would simply have a requirement/dependency on the results "provided" by each branch. It would wait to execute until those requirements were met. The user wouldn't need to know about the data model still, the "merge node" would just intrinsicly wait for the results provided form the seperate branches. Fundamentally when each node completes the system itself just needs to check against the list of nodes to see if its dependencies have just been met and keeps track of which nodes have been already executed so that they don't end up getting triggered again when the next check happens. There will always be a need for some sort of workflow level state or context management that governs all of this orchestration that you would want to persist to a database somewhere if this is a long running workflow but this is a systems concern and the user doesn't need to know about it. That was just a long way of me more or less saying that it doesn't matter how many branches there are, all that matters ultimately is that a node waits to execute when its requirements are met.