Multi-agent systems on AWS: orchestrating specialists vs one generalist

For solution architects, multi-agent design is one of the first genuinely hard decisions in an agentic project. It is tempting to treat “more agents” as more capability, the way more microservices once felt like more scalability. It is not. Every agent you add is another model in the loop with its own latency, cost and failure mode. The right number of agents is the smallest number that makes the system reliable, and finding that number is the work.

This piece walks the decision the way you actually meet it: when one agent stops coping, what the supervisor pattern looks like on AWS, when to split and when to resist, where deterministic workflows beat agentic ones, how to hand off cleanly, and what it all costs.

When one agent is not enough

A single agent reasons over one context window and chooses from one tool set. That works beautifully until the job grows in two directions at once. The tool set widens, and now every decision the model makes includes a tool-selection step over a longer menu, where the wrong choice is more likely and harder to recover from. The context fills, with instructions for half a dozen unrelated sub-tasks, the schemas of a dozen tools, and the running history of a conversation that keeps switching domains.

The symptoms are familiar. The agent calls the wrong tool, or the right tool with the wrong arguments, more often as the catalogue grows. Instructions that matter for one task dilute the instructions for another, so behaviour drifts. The prompt that held twelve tools together becomes a balancing act where fixing one task quietly breaks another.

Splitting the work can restore the reliability you had at the start. Give each focused agent a narrow tool set and only the knowledge its task needs, and tool selection becomes easy again, because there are few tools and they are obviously relevant. The context stays small and on-topic. You trade one overloaded generalist for several agents that each do one thing well, and the system as a whole gets more predictable.

The supervisor and specialists pattern

The most common shape for this is a supervisor (or orchestrator) agent that owns the user's intent and routes work to specialist sub-agents. The supervisor does not do the domain work itself. It decides which specialist a request belongs to, hands it across, collects the result, and decides what to do next, possibly calling another specialist, possibly returning to the user. Each specialist holds a narrow set of tools and the knowledge for its domain, and nothing else.

A supervisor routes to specialists; each specialist sees only its own tools and knowledge. The supervisor never touches a domain API directly.

On AWS, Amazon Bedrock supports this directly through its multi-agent collaboration capability: you configure a supervisor agent and associate collaborator agents under it, and Bedrock handles the routing of requests to the right collaborator and the consolidation of their responses. That gives you the pattern as a managed feature rather than something you wire by hand. The same shape can also be built with frameworks such as Strands Agents or LangGraph running on your own compute; the principle is identical, a routing brain over a set of narrow specialists.

When to split, and when not to

The pattern is seductive, so the discipline is in restraint. There are three honest reasons to split an agent.

• Distinct domains. The tasks need genuinely different knowledge and tools, billing versus account management versus product help. Each becomes a clean specialist.
• Too many tools for one agent. Tool selection has become noisy because the catalogue is large. Grouping tools behind specialists shrinks the menu each agent must reason over.
• Separate ownership and permissions. Different teams own different capabilities, or different tasks must run under different IAM permissions. A boundary between agents is also a boundary you can govern, log and least-privilege independently.

And there is one strong reason not to: the task is simple. If a single agent with a tidy tool set already does the job, a second agent adds a model call, a handoff, and a new way to fail, for no reliability you did not already have. One agent is simpler to build, cheaper to run and easier to reason about. Reach for a second agent when one is visibly straining, not in anticipation.

Agentic orchestration vs deterministic workflows

Before you reach for any agents at all, ask whether the control flow is actually dynamic. A great deal of work that gets labelled “agentic” is in fact a fixed sequence of steps that you already know in advance: validate the input, enrich it, write it to a store, notify a queue. When the path is known and fixed, a deterministic workflow is the better tool. On AWS that is typically AWS Step Functions, where each step is explicit, retries and error handling are declared, and the execution is the same every time. You get auditability and predictable cost for free, and no model decides the order of operations because the order is not in question.

Use agentic orchestration where the path genuinely cannot be drawn ahead of time, where the next step depends on what the previous step found, and the model has to decide at runtime which tool or specialist to engage. That is where an agent's judgement pays for its unpredictability.

Most real systems are a hybrid, and that is the mature answer rather than a compromise. You embed an agent inside a workflow for the one step that needs judgement, while the surrounding steps stay deterministic. Or you expose a deterministic workflow to an agent as a tool, so the agent decides whether and when to invoke a reliable, fixed procedure but never improvises its internals. Drawing the line in the right place, deterministic for the known, agentic for the unknown, is most of good agentic architecture.

Handoffs and shared context

The moment you have more than one agent, the system lives or dies on its handoffs. When the supervisor passes work to a specialist, the specialist needs enough context to act, the user's actual goal, the relevant state, and any intermediate results from earlier steps, without being flooded with the entire conversation. Too little and the specialist is working blind; too much and you have rebuilt the context bloat you split the agents to escape.

A clean handoff carries the goal, the few facts that matter, and the structured outputs of prior agents, then lets the specialist add its result back in a shape the supervisor can use. A poor handoff loses the thread: the specialist solves a subtly wrong problem because the intent did not survive the trip, or it repeats work because a prior result was never passed forward. Treat the contract between agents as a first-class design artefact, with explicit fields, not a loose hope that the model will infer what it needs. Bedrock's multi-agent collaboration manages much of this routing and consolidation for you, but the quality of what you pass and what each agent returns is still yours to design.

The cost and latency trade-off

Every agent in the loop is at least one more model invocation. A request that a single agent answers in one or two calls can, in a deep multi-agent topology, fan out into a supervisor call, a specialist call, perhaps a second specialist, and a consolidation call, each adding tokens, dollars and wall-clock latency. The reliability you gain from specialisation is real, but it is not free, and it is easy to build a system that is more correct and too slow or too expensive to use.

So size the topology to the problem. Add agents where they measurably reduce errors or isolate a boundary you need; stop where the next agent only adds round-trips. Keep the depth shallow, prefer a flat supervisor over many tiers of supervisors over supervisors, and let deterministic steps carry the parts of the flow that never needed a model. The best multi-agent system is usually the smallest one that holds the reliability you require.

The shape to aim for

Start with one agent and let it strain before you split. When you split, split along real seams, distinct domains, an overgrown tool set, or a permission and ownership boundary, and put a supervisor over narrow specialists, which Amazon Bedrock supports as a managed pattern. Be deterministic wherever the path is known, reserve agentic orchestration for the genuinely dynamic, and accept that most good systems are a hybrid of the two. Design your handoffs deliberately, and keep the whole topology as small as the problem allows. Get those choices right and a team of specialists outperforms the lone generalist; get them wrong and you have simply paid more for the same answer, more slowly.