Graph Workflows
1. Graph Workflows
The agent as a tool pattern works when tasks are independent and you want the agent to have the maximum amount of adaptability. But it's not the best choice for every workload. There's no way to express direct dependencies or ensure agents execute in a specific order. Graphs solve this. You define the execution order of your agents explicitly and each node of the graph is a full agent. These agents can have tools, MCP servers, skills, plugins, or whatever else they need. You connect the agents through edges which express dependencies. The graph structure in strands resolves what can run in parallel and what has to wait based on how you define it. Let me build a graph so you can see how it works. Here we have four agents: a researcher, an analyst, a summarizer, and a report writer. We want the researcher to run first. When it finishes, the analyst and summarizer should run in parallel. Once both are done, the report writer combines everything into the final output. To enforce that order, we use the graph builder. We create a new graph builder instance, then register each agent as a node in the graph using add node. Then we connect them using add edge. A target node can't execute until its upstream dependencies complete. We define the edges so the researcher runs first, then the analyst and the summarizer branch off in parallel, and finally the report writer waits for both of them before running. Then we call build which validates the graph and returns an executable workflow. You can execute the graph like a function. You pass in a task string and you get back a graph result. Let's run it. I'll open up a new terminal session. And then we can go ahead and run the graph. And while this is running, let's talk about the data flow and state management for graphs. Entry point nodes receive the original task directly and downstream nodes receive the original task plus the outputs from their dependency nodes. Each dependency result is labeled with the node ID and combined into the downstream prompt automatically. So, in our example, the report writer receives the original task, the analyst output, and the summarizer output, all stitched together into one structured input. You can design downstream prompts to expect and reason over multiple labeled inputs. Now, sometimes you need to share more information across the graph without exposing it directly to the model prompt. That's where invocation state comes in. Invocation state is a shared dictionary passed into the graph at runtime. Every node can access it. This is useful for things like user IDs, feature flags, configuration, or metadata that components attach to each agent need, but the model itself doesn't need to know about. The graph has finished running, so now let's review what happened. We can see that the researcher ran, and then the analyst and summarizer ran, and the report writer combined everything into one final result. Now, let's look at four common graph patterns you'll see repeatedly in multi-agent systems. First is the sequential pipeline. One agent runs after another in a strict sequence. This is the simplest graph pattern. The second is parallel fan out with aggregation. One node fans work out to multiple parallel agents, then an aggregator node waits for all of them to finish before combining the results. Third is conditional branching. In this pattern, agents can have conditions attached to them, so different branches execute depending on runtime decisions or outputs. And finally, there are feedback loops. This is where the graph becomes cyclic. For example, a writer agent produces a draft, a reviewer agent evaluates it, and if revisions are needed, the workflow loops back to the writer before eventually continuing to the publisher. For cyclic graphs, there are two important safety controls worth knowing about. The set max node executions setting limits on the total number of node runs and prevents infinite loops. And reset on revisit clears a node's conversation history each time it reenters the cycle, so context doesn't grow uncontrollably across revisions. Both of these become important for controlling reliability and cost in iterative or long-running workflows. There's examples of these patterns in the repo if you want to explore them further, but you don't need to memorize every detail here. You just need to understand the architectural patterns that are possible, so you know how these systems can be composed. The tradeoffs for using the graphs is that you have to define the structure up front. If the optimal execution path depends heavily on what the agents discover dynamically during runtime, then graphs can become too rigid. That's exactly why the next pattern exists, agent swarms. Instead of predefining the workflow structure, swarms allow the execution path to emerge dynamically as the agents collaborate and make decisions in real time. I'll see you there.2. Final slide
Then explore emergent collaboration through agent swarms.Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.