Proper way to set up a dynamic map-reduce graph in Strands?

[Nicricflo]

I would like to understand the proper way to set up a map-reduce graph framework in Strands. I am used to using the Send api from langgraph (see https://docs.langchain.com/oss/python/langgraph/graph-api#send for reference).

Basically, at runtime, depending on the users query, I would like anywhere from 1-5 sub-agents to be spawned (depending on user query complexity) to perform various tasks (in parallel). What would be the best way to accomplish this with strands?

[advijaykar]

Strands doesn’t have an exact equivalent of LangGraph’s Send API, because the framework doesn’t dynamically spawn nodes inside the graph itself. Instead, the recommended pattern is to let a single agent decide how many subtasks are required, and then let that agent call other agents or tools as needed. In other words, the “dynamic” part happens in the agent’s reasoning layer, not in the graph structure.

The usual way to build a map-reduce workflow in Strands is to have one coordinator agent that receives the original query, breaks it into however many subtasks are needed, and then calls the appropriate sub-agents in parallel. You don’t need to pre-declare five different branches in the graph; you only declare the coordinator agent and the sub-agents, and the coordinator chooses which ones to invoke at runtime. Strands automatically handles the parallel execution of tool or agent calls when you invoke multiple calls inside a single step.

The reduce phase is done by the same coordinator agent. After the sub-agents complete their work, their outputs come back to the coordinator, and the LLM decides how to merge them into a final answer. So the graph itself stays simple and static, but its behavior becomes dynamic because the model decides how many calls to make and how to combine the results.

This pattern is how most complex or branching workflows are implemented in Strands today. It keeps the graph definition minimal while still giving you dynamic fan-out and fan-in behavior similar to map-reduce.

[advijaykar]

If you’re looking for something closer to true dynamic node creation, Strands doesn’t currently allow you to modify the graph structure during execution. Instead, the idea is that your coordinator agent acts almost like its own scheduler. It can look at the user’s query, decide how many workers it needs, and then fire off those calls inside one turn. Each call behaves like an independent branch, and since Strands handles concurrency internally, they all run in parallel without you having to define separate edges or nodes manually.
Most people implement this by giving the coordinator a tool or function that takes a list of tasks and returns a list of parallel calls. The model fills in that list, and Strands automatically parallelizes the execution. Once everything finishes, the coordinator gets back an array of results that it can summarize or merge.
So even though it doesn’t feel like building a dynamic graph, the end result is the same: you get dynamic fan-out, parallel worker execution, and a reduce step afterward, all driven by the LLM’s planning. This is the pattern the Strands team recommends until official dynamic graph features are introduced.