Who Decides the Next Step? Multi-Agent Patterns in Strands Agents
Strands Agents offers several ways to combine agents. A decision guide from workflows and graphs to agents-as-tools and swarms, with a decision flow, production notes on session state, limits, hooks, and tracing, and common anti-patterns.
Introduction
The Strands Agents SDK is an open-source toolkit for building AI agents in Python and TypeScript. Its core idea is a model-driven agent loop: you give a model instructions and tools, and it decides how to use them. That keeps a single agent simple.
Things get more interesting when one agent is not enough. Strands ships several multi-agent building blocks, and the hard part is no longer how to connect agents but which pattern to choose. This article is a decision guide plus a set of production notes. It assumes you already know how to build a single agent and want to reason about structure, limits, and failure modes.
The organizing question is simple: who decides the next step, you or the model?
The control spectrum
Figure 1. Multi-agent patterns in Strands, ordered from developer-defined control flow to model-driven control flow.
The more control you keep in code, the easier a system is to test, trace, and cost. The more you hand to the model, the more it can adapt to inputs you did not anticipate, and the more ways it can wander. Neither end is better. They suit different problems.
The building blocks
Pattern | How it works | Who decides the path | Best for | Main risk |
|---|---|---|---|---|
Workflow | Tasks run with defined dependencies between them | You | Repeatable processes with known steps | Rigid when inputs vary |
Graph | Agents are nodes in a directed graph with conditional edges | You define the structure; conditions choose the route | Branching logic, review loops, approvals | Cycles and long paths need limits |
Agents as tools | Specialist agents are wrapped as tools that an orchestrator agent calls | The orchestrator model | Clear roles under one coordinator | The orchestrator becomes a bottleneck |
Swarm | Agents hand work to each other using shared context | The agents themselves | Open-ended, exploratory problems | Loops, unclear ownership, harder debugging |
Agent2Agent (A2A) | Agents in separate services communicate over a standard protocol | Each service | Cross-team or cross-system collaboration | Network, versioning, and trust boundaries |
The first four describe how agents are organized inside one application. A2A describes how agents talk across applications, so it often combines with the others instead of replacing them.
A decision guide
I use these questions in order:
- Can one agent with good tools do this? If yes, stop. Every added agent costs latency, money, and debuggability.
- Are the steps known in advance? Prefer a Workflow, or a Graph if routing depends on results.
- Do the roles divide cleanly under one coordinator? Use agents as tools.
- Is the path genuinely unpredictable, and are you comfortable with autonomy? Consider a Swarm, with strict limits.
- Does another team or system own part of the work? Expose it over A2A.
Rule of thumb: choose the most deterministic structure that still solves the problem, and move rightward on the spectrum only when you can name the reason.
Agents as tools: the usual starting point
For many systems, agents as tools is the easiest to reason about: each specialist keeps its own prompt and tools, and the orchestrator treats it like any other function.
Python
from strands import Agent, tool@tooldef research_specialist(topic: str) -> str:"""Research a topic and return key findings as short bullet points."""agent = Agent(system_prompt="You are a careful researcher. Return 5-7 factual bullets. ""State uncertainty explicitly.",callback_handler=None, # keep intermediate output out of the console)return str(agent(topic))orchestrator = Agent(system_prompt="Call research_specialist once for the topic, then summarize ""its findings for the user.",tools=[research_specialist],)
Two design points matter more than the code:
- The tool's docstring is the contract. The orchestrator decides when to call a specialist based on that description, so write it as carefully as a prompt.
- Return structured, bounded output. Whatever the specialist returns becomes the orchestrator's context, so concise and consistent results reduce cost and confusion.
Production notes that are easy to miss
1. Session state belongs to the orchestrator only
Strands supports session management for multi-agent systems, but the rule is strict: only the orchestrator should have a session manager. In Python, adding an agent that has its own session manager to a Graph or Swarm raises an error. The persisted multi-agent state tracks the orchestration itself and does not store each agent's individual conversation history. If you need a full audit trail of what every agent said, plan for that separately through logging or tracing.
2. Put limits in the structure, not in the prompt
A line such as "do not loop forever" is a request. Use the framework's execution limits (timeouts, iteration or handoff caps) and your own budgets. Check the current documentation for the exact options, because they evolve between releases.
3. Use hooks for cross-cutting concerns
Strands exposes lifecycle hooks around agent and tool execution. They are the right place for audit logging, cost metering, approval gates, and redaction, because they apply the same rule to every agent without relying on each prompt to remember it.
4. Make behavior observable
Strands integrates with OpenTelemetry, so agent loops, model calls, and tool calls can be traced. In a multi-agent system, traces matter more than logs, because the failure is often in a handoff. Ensure a request can be followed end to end across agents.
5. Treat inter-agent content as untrusted
Anything an agent reads from the web, documents, or users can carry instructions meant for the model. When one agent passes that content to another, the injection travels with it. Validate and scope what crosses boundaries, and keep sensitive tools behind explicit approval. The Strands documentation includes sections on guardrails, PII redaction, human-in-the-loop interrupts, and authorization controls that are worth evaluating for this.
6. Keep deployment portable
Agents built with Strands can run on managed platforms such as Amazon Bedrock AgentCore, in containers, or in serverless functions. Keep model access and state behind thin interfaces so a change of host or model provider does not require a redesign.
Common anti-patterns
- A Swarm for a known pipeline. If you can draw the steps on a whiteboard, use a Workflow or Graph.
- A "manager" agent that only forwards. If the orchestrator adds no judgment, it is just latency.
- Free-text handoffs. Prose between agents invites misreading. Use agreed formats.
- Shared mutable assumptions. Agents silently relying on the same unstated context drift apart when that context changes.
- No evaluation of the whole system. Each agent can pass its own tests while the combined behavior fails.
Testing and evaluation
Evaluate the pattern, not just the prompts. A useful approach is to run the same task set through two structures, for example agents as tools versus a Graph, and compare quality, cost, latency, and variance across repeated runs. Often the more deterministic design wins on cost and consistency, while the more autonomous one wins on unusual inputs. You can only see that trade-off if you measure it.
Conclusion
Strands gives you a full range of multi-agent patterns, but the best designs are rarely the most elaborate ones. Start with one agent. Add structure only when you can name the problem it solves. Keep control in code where you can, hand it to the model where you must, and put limits, hooks, and tracing in place before you scale.
If you work with Strands, which pattern do you reach for first, and what made you change your mind? I would love to compare notes.
References
Disclaimer: This article reflects the author's personal views and does not represent AWS or any other organization. The Strands Agents SDK changes quickly; verify APIs, options, and features against the current official documentation before relying on them.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article