Managing multiple graph streams and message routing without user platform selection

OSS Product Help LangGraph
1

Hey folks, I’m trying to develop the right mindset for building graphs properly, and right now my reasoning is context-based — if the context is different, I create a new graph dedicated to that context. This approach works great for me so far. For example, if I have LinkedIn support, I create a LinkedIn graph; if I have X support, I create an X graph.

I’m now building a client where I stream responses from these graphs. My question is: can I have two useStream hooks, one for each graph (LinkedInGraph and XGraph), then simply merge the messages and display them to the client?

The issue I’m stuck on is with sending messages, because right now I submit like this:
``
thread.submit({
messages: [{ type: ‘human’, content: message }],
});
``

…and this is connected to a specific graph. How can I properly submit messages to the right graph (LinkedIn or X) without the user having to manually choose the platform in the client?

Would an orchestrator be the best option here? If so, wouldn’t that always become a bottleneck as the single entry point — especially if there are many users and many subgraphs (e.g., multiple social platforms)? Would it scale well?

2

Hey Andon,

For your first question - yes I believe you should be able to have two useStream hooks. For your second question, I think you could either implement some sort of dynamic routing outside of the graph (i.e. just a function on your side) or yes you could use the orchestrator approach. I don’t think there should be any scalability concerns here - the graph can only execute 1 run at a time, so nodes are never really the bottleneck, the bottleneck is mainly how long the graph takes to execute. Let me know if that makes sense and happy to answer any further questions.

Isaac

3

Thanks, Isaac — that makes sense.

I’m also leaning toward the orchestrator approach. My only concern is how it behaves as the number of sub-graphs grows. Imagine an orchestration graph that routes to many modules → their sub-modules → sub-nodes (dozens in total). Will the orchestrator/RouterNode handle that depth and breadth well, or would you still recommend pushing some of that dynamic routing outside the graph?

Appreciate the guidance!