Is dynamic parallelism in edges supported?

[RamiAwar]

I looked into the docs here:
https://langchain-ai.github.io/langgraph/how-tos/branching/#stable-sorting

What I'm doing is I have a planner node that comes up with a plan to do X, Y, Z, achieve some goals.

Most of the time, X, Y and Z are all runnable in the same "subgraph" lets say.
First step is look up SQL table metadata, second step is lookup column info, third step is generate and execute SQL.

What I want to have is a dynamically-built graph based on this plan that I get from the planner node. i.e. add_edge(basic_flow) (for X), add_edge(basic_flow) (for Y)...

Then the same flow would run 3 times in parallel.

It's a little weird because the graph structure itself here is dynamic based on the output of the first node.

The natural solution is have that node be called separately (not a node - just a separate call), then compile the graph dynamically. But that's not optimal.

Issue with that is that sometimes I'd like to modify the plan as I go through the state machine. I sometimes need to add/remove parts of the plan. Then I want the graph to be dynamic again based on the new plan (maybe we come up with a new set of questions I, J, K that will run in another flow (advanced_flow) and I want those to run in parallel).

Any idea if this is possible? I'm not sure how to word it better, I feel like I might've done a bad job, so let me know if any part is confusing and I'll clarify.

[hwchase17]

Trying to understand. so you want to have the first node come up with plan (do X->Y->Z)?

Then the same flow would run 3 times in parallel.

Why would it run three times in parallel?

[RamiAwar]

@hwchase17 Cause it would dynamically decide that "Oh! The user query involves answering 3 different questions using the same subgraph - so I will dynamically decide to branch out 3 parallel subgraphs to answer these questions, then merge the resulting state updates!"

Does that make sense?

[RamiAwar]

Just saw llama-agents and it sparked a thought - it makes sense for some parts of the graph to be distributed horizontally-scalable workers. They're still a 'subgraph' interface wise, but internally it's a message queue with workers and they just take an input and spit out state updates that go flow back into the parent graph.

I can definitely see Langgraph growing into that long term, where graphs will be massive and complex and you might want to share some subgraphs with multiple graphs in production.

Very long term thinking though, and doesn't apply to simple applications. Here normal parallelism in nodes would probably suffice for now.

[ariel-frischer]

Also have come into a situation where dynamic parallel node/edge addition would be useful:
#217

[iboates]

Just wondering if there is any follow up on this at all? I am in a similar situation. I have a kind of "decomposer" agent resolves a list of necessary datasets. This list is of variable size. Each dataset can be resolved from the same database, so I would like to be able to "spawn" as many nodes as necessary to solve the task. A kind of "node pool" or "subgraph pool" which will maintain N active threads all executing the same node/subgraph with different inputs until the inputs are exhausted would be very useful