Agent Swarms
1. Agent Swarms
In a graph, you decide the execution order of the agents. With agents as tool, the orchestrator decides who to call. But what if you don't know the right structure up front? Think about a production incident triage system where the first agent checks logs, finds a database connection error, so it hands off to the metrics analyst who sees the connection pool is exhausted, and hands off to the deployment reviewer who finds someone changed the pool config 30 minutes ago. You can't draw that graph ahead of time because the path depends on what each agent discovers. This is why agent swarms exist. In a swarm, the agents decide. They hand off to each other autonomously based on what the task needs. Let me build a system debugging swarm. For this one, we have four agents: a triage agent who does the initial assessment, a log analyst, a metrics analyst, and a deployment reviewer. First, we define some tools using the tool decorator that simulate production debugging capabilities like checking logs, metrics, recent deployments, and infrastructure status. In a real system, these would integrate with external systems or maybe even use MCP servers, but for now mocking them up is fine. Then we create our four agents. Each has a system prompt describing their specialty, when to hand off, and any relevant tools. To use these agents in a swarm, we pass them all to a swarm object with an entry point set to the triage agent. Every agent automatically gets a hand off to agent tool injected by strands. That's what lets them transfer control to each other. There are some safety settings defined you should pay attention to here. You need to set these values carefully because swarms without proper configuration can run forever and burn up a ton of tokens. Two agents can ping pong. The log analyst says, "This looks like a deployment issue." The deployment reviewer says, "This looks like an application issue." And then you burn tokens until your configured timeout kills it. Max handoffs caps the total number of handoffs. Max iterations caps the total agent executions. Execution timeout is a time limit for the whole swarm, and node timeout limits any single agent's turn. There's also repetitive handoff detection. Set repetitive handoff detection window and repetitive handoff min unique agents, and the swarm will terminate if the same set of agents keeps bouncing back and forth. Then we pass in the task statement. The payment service is returning 500 errors for about 25% of requests started about 30 minutes ago. Let's give this a run and see what happens. The swarm is done running and we can review what happened. So, the triage agent was kicked off and it came up with its initial assessment. After that, it decided to hand off to one of the specialists. And in this case, we have both parallel investigation tracks are now active. So, the log analyst and the deployment reviewer kicked off at the same time. And then it decided to call the check infrastructure status tool. So, we can see the different agents are calling the tools that they have, and the agents are handing off to each other as needed. So, the path emerged organically from what each agent discovered. The key difference from agents as tools is there's no request response model in the same way. When the log analyst hands off to the metrics analyst, the log analyst turn is done and the metrics analyst takes over completely. It's a full transfer of control, not just a function call that waits for another agent to return the result. Swarms operate over a shared context. So, each agent sees the accumulated work from previous agents, including prior findings, handoff history, and shared state contributed during execution. So, when the deployment reviewer takes over, it doesn't just see payment service has errors. It sees the original incident report, the triage assessment, the log analyst's finding about connection timeouts, and the metrics analyst's data about pool exhaustion. Each agent builds on the work of the agents before it. Now, let me compare all three multi-agent patterns we covered, so you know when to use each one. First, agents as tools. This is the hub and spoke model. One orchestrator calls specialists and gets results back. The orchestrator stays in control. This is best for when you have clearly separable domains, where you want one agent synthesizing everything. Then, for graph. These are directed edges between nodes. You define the execution order, the dependencies, and the conditions. This is best for workflows with known structure, like pipelines, fan out, and feedback loops. And finally, swarm. Each agent can talk to every other agent. Agents hand off autonomously, with no predefined structure. Use this when the optimal sequence isn't known in advance, like collaborative investigation, where agents build on each other's discoveries. The mental model I use, if you can draw the workflow on a whiteboard, use a graph. If you can have a clear manager-specialist relationship, use agents as tools. If you need the team to figure it out together, use a swarm. And you can mix them. A swarm can be a node in a graph. A graph can contain agents that call agents as tools. These patterns compose naturally, so you can build a really customized multi-agent system, dependent on your use case. Next up, let's talk about agent evaluation and how to measure your agent's performance.2. Final slide
Multi-agent patterns complete — evaluate and deploy your agents to production.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.