Building a supervisor routed multi agent system with Strands Agents

Most multi-agent tutorials start with a fixed pipeline. Agent A always feeds Agent B. Real workloads rarely look like that. A support inbox gets coding questions, planning requests, and research questions in the same hour, and routing all of them through the same chain wastes calls on specialists who do not apply. What you actually want is a single-entry point that reads each incoming task, decides which specialist fits, and checks the result before handing it back.

That is the supervisor with a dynamic routing pattern. It is one of eight multi-agent architectures worth knowing about: sequential pipelines, parallel fan out, hierarchical delegation, debate, voting and consensus, blackboard, market-based task assignment, and supervisor routing. Each one suits a different shape of problem, summarized below, before we build the last one.

This pattern — along with the other seven — is explored in depth in Dhivya Nagasubramanian's Agentic AI for Engineers (Apress, Springer Nature), which breaks down which architecture fits which class of problem. The implementation below builds on that framing.

This post builds the last one, using Strands Agents, which has a built-in primitive called Agents as Tools that maps onto it almost directly.

The supervisor sits between the user and four specialists. It reads the incoming task, picks one specialist, sends it a refined version of the task, reviews what comes back, and either returns it or tries again. Every agent in the diagram, the supervisor and each specialist, calls the same Bedrock model underneath, just with a different system prompt.

Say you have four kinds of work coming in: coding tasks, writing tasks, research questions, planning requests. And four specialists, each good at one of those things. A single generalist agent could attempt all four, but it will not do any of them as well as a specialist with a tightly scoped system prompt. A fixed pipeline does not fit either, since the tasks do not arrive in a fixed order or combination. What you need is a router that reads each task and sends it to the right specialist, then checks the output before returning it.

That second part, checking the output, is worth calling out on its own. Routing alone gets you delegation. Adding a review step gets you a quality gate. The supervisor does not just hand off and trust whatever comes back. It reads the result and decides whether it is good enough or needs another pass.

Strands' Agents as Tools pattern wraps each specialist as a callable tool the orchestrator can use. Each specialist gets its own narrow system prompt.

The supervisor is a regular Strands Agent that gets the specialists passed in as tools. The supervisor's system prompt handles both the routing decision and the review of the specialist's output. Routing means reasoning about which specialist to select; review means judging whether that output is good enough to return, or whether the specialist needs another pass with refined instructions.

By default, this uses whatever provider Strands defaults to in your environment. To point it at a specific Bedrock model explicitly, construct a BedrockModel and pass it to each agent:

Do the same inside each specialist function if you want every specialist pinned to the same model rather than falling back to a default.

That is the whole system. No manual routing table, no chain of if and elif statements matching keywords to specialists. The supervisor's own reasoning does the dispatch, using the tool docstrings as its menu of options.

With a sequential pipeline, every task passes through every agent in the same order, whether or not that agent is relevant. The supervisor pattern trades that predictability for flexibility. A coding question never touches the writer or the researcher, so you are not paying for calls that do not apply. The cost is that the routing decision is now a judgment call made by a model instead of a fixed rule, which is exactly why the review phase matters. It is the check that catches a misrouted or shallow response before it reaches the user, instead of assuming the first specialist called was the right one.

A few directions worth trying from here. Have the supervisor state its confidence in a routing decision and fall back to a second specialist opinion when that confidence is low. Have it emit a structured pass or fail on review instead of free text, so you can log and monitor rejection rates per specialist over time. Or let a specialist be a small Graph or Swarm internally, so a call to coder_specialist can hand off to a small sub team of its own for larger tasks.

There is no persistent infrastructure to tear down here; this example runs as a plain Python script and does not provision anything. The cost to be aware of is Bedrock inference itself: a supervisor call typically triggers two model invocations per task, one for routing and specialist dispatch, one for review, plus whatever the specialist's own inner agent call costs. For light testing, this stays well within typical Bedrock free tier or low usage pricing, but if you wire this into a production workload, track token usage per specialist so a chatty one does not dominate your bill.

The supervisor pattern is a good default when your workload is mixed, and you do not know ahead of time which specialist a given task will need. Strands' Agents as Tools primitive maps onto it almost directly. Most of the design work ends up in the specialist system prompts and the routing and review instructions you give the supervisor, not in orchestration plumbing.