This article is published in English.
Multi-agent systems in 2026: ReAct, supervisors, swarms, LangGraph, and Strands
A field guide to multi-agent control-flow patterns—sequential, parallel, hub-and-spoke, graph, event-driven, critic, and human-in-the-loop—and how frameworks like LangGraph and Strands fit.
The next phase of generative AI is not only smarter models. It is systems where multiple agents can reason, call tools, delegate, verify outcomes, recover from failures, and coordinate. That is the domain of multi-agent systems (MAS).
A minimal LLM app looks like a straight user-to-model path:
User
↓
LLM
↓
Response
A production multi-agent layout is richer:
User
│
▼
┌─────────────┐
│ Orchestrator│
└──────┬──────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
└───────────┼───────────┘
▼
Verification
│
▼
Action
There is no single template. Common shapes include ReAct agents, sequential and parallel pipelines, supervisor (hub-and-spoke) designs, hierarchies, handoffs, swarms, planner–executor splits, graph-based workflows, event-driven agents, critic/evaluator loops, and human-in-the-loop gates. Frameworks such as LangGraph, Strands Agents, and Amazon Bedrock AgentCore supply primitives for those patterns. The sections below separate the ideas so teams stop treating unequal concepts as rivals.
1. What is a multi-agent system?
A multi-agent system is a collaboration of specialized agents toward a larger goal. Instead of one model doing everything:
LLM
├── Research
├── Coding
├── Database
├── Security
├── Decision making
└── Execution
responsibilities can be split:
Supervisor
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Research Agent Security Agent Execution Agent
│ │ │
▼ ▼ ▼
Search Security APIs
Tools Tools Tools
Each agent may carry its own instructions, tools, memory, context window, model choice, policies, duties, and evaluation criteria. Specialization is a primary reason to leave single-agent designs.
2. More agents is not automatically better
Extra agents add cost and complexity. Three agents often mean three prompts and three contexts:
3 agents
↓
3 × prompts
3 × contexts
3 × tool interfaces
3 × failure surfaces
3 × observability requirements
Chatty meshes amplify spend and debugging pain:
Agent A → Agent B
Agent B → Agent C
Agent C → Agent A
Agent A → Agent D
Agent D → Agent B
A sound design asks which responsibilities deserve separation and how control should flow between them.
3. ReAct agent
ReAct means Reason + Act. The loop reasons, picks a tool, observes, and continues—for example investigating unusual database CPU:
Reason
↓
Call CloudWatch
↓
Observe CPU metrics
↓
Call logs
↓
Observe errors
↓
Reason
↓
Return diagnosis
Strength: dynamic tool choice when the next step depends on the last observation.
Weakness: long loops raise latency, tokens, cost, and failure odds. ReAct is a reasoning pattern, not a full multi-agent topology by itself.
4. Sequential multi-agent architecture
The simplest multi-agent shape is a pipeline:
Document Agent
↓
Extraction Agent
↓
Risk Agent
↓
Decision Agent
A banking-style flow might look like:
Bureau Agent
↓
Policy Agent
↓
Risk Agent
↓
Decision Agent
When to use: order matters, outputs feed the next stage, the workflow is predictable, and audit trails matter.
Main limitation: failure in the middle can stall the whole line—hence retries, checkpoints, and recovery in production.
5. Parallel / fan-out–fan-in
Independent work need not wait in series:
Agent A
↓
Agent B
↓
Agent C
Concurrent specialists run together:
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└──────────┼──────────┘
▼
Aggregator
A cloud architecture review can fan out analysis agents:
Architecture Request
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Cost Agent Security Agent Performance Agent
│ │ │
└──────────────┼──────────────┘
▼
Architecture Agent
then aggregate findings.
Advantage: lower wall-clock time. Challenge: aggregation must be robust.
6. Hub-and-spoke / supervisor
A central supervisor routes work to specialists:
Supervisor
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Research Coding Finance
Agent Agent Agent
│ │ │
Tools Tools Tools
Given a user request:
User:
"Analyze this AWS account and identify security and
cost problems."
the supervisor may dispatch like this:
Supervisor
│
├──→ Security Agent
│
└──→ FinOps Agent
│
▼
Aggregator
│
▼
Report
Advantage: centralized control. Challenge: the hub becomes a bottleneck and critical infrastructure when every decision passes through it:
Agent A ─┐
Agent B ─┼──→ Supervisor
Agent C ─┤
Agent D ─┘
7. Hierarchical multi-agent architecture
When one supervisor is not enough, add levels:
Global Supervisor
│
┌───────────┴───────────┐
▼ ▼
Engineering Lead Business Lead
│ │
┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼
Coding Testing Finance Risk
Enterprise clouds often nest supervisors:
Enterprise Agent
│
├── Cloud Supervisor
│ ├── Security Agent
│ ├── FinOps Agent
│ └── Operations Agent
│
└── Application Supervisor
├── Coding Agent
├── Testing Agent
└── Documentation Agent
The shape mirrors org charts; the cost is more coordination overhead.
8. Handoff-based architecture
One agent transfers ownership of the conversation to another:
Agent A
│
│ handoff
▼
Agent B
│
│ handoff
▼
Agent C
Support flows often hand off technical issues:
Customer Agent
│
│ technical issue
▼
Technical Agent
│
│ billing issue
▼
Billing Agent
Unlike a permanent supervisor, the receiver becomes the active owner—useful for customer support, specialist routing, domain assistants, and conversational workflows.
9. Swarm architecture
Swarms drop a permanent center. Agents collaborate dynamically:
Agent A
↙ ↘
Agent B ←→ Agent C
↘ ↙
Agent D
Each may decide another peer is better suited. Flexibility comes with hard questions: who controls the system? Without boundaries you risk loops, duplicate work, context explosion, unpredictable paths, and high inference cost. Strong state management and termination conditions are mandatory.
10. Planner–executor architecture
Separate planning from doing:
User Goal
│
▼
Planner
│
┌────────┼────────┐
▼ ▼ ▼
Task 1 Task 2 Task 3
│ │ │
▼ ▼ ▼
Executor Executor Executor
│ │ │
└────────┼────────┘
▼
Result
For “migrate this application to AWS,” a planner might emit steps:
1. Analyze application
2. Identify dependencies
3. Design AWS architecture
4. Estimate cost
5. Generate Terraform
6. Validate Terraform
Executors then perform each step. Helpful when complex goals decompose into explicit tasks.
11. Graph-based agents
Frameworks such as LangGraph shine here. Instead of a loose chain:
Agent → Agent → Agent
think of a state graph:
START
│
▼
Research
│
┌──────┴──────┐
▼ ▼
Valid Invalid
│ │
▼ ▼
Analysis Research
│
▼
Verification
│
▼
END
Nodes can be agents, tools, functions, validators, human approvals, or routers. Shared state plus explicit edges give more control than asking a model to improvise every transition.
12. Strands Agents
AWS Strands Agents is an SDK for tool-using agents. Conceptually:
Agent
│
┌───────┼────────┐
▼ ▼ ▼
Tool Tool Tool
│ │ │
▼ ▼ ▼
AWS APIs Databases
Agents reason about tools and continue from observations. Strands can also sit inside multi-agent layouts:
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
AWS SQL Research
Agent Agent Agent
Important distinction: Strands is a framework/SDK; supervisor is an architectural pattern. They are complementary, not competitors.
13. LangGraph agents
LangGraph emphasizes explicit stateful workflows as graphs:
START
│
▼
Supervisor
│
├──────→ Research Agent
│
├──────→ Data Agent
│
└──────→ Security Agent
│
▼
Validator
│
┌───┴───┐
▼ ▼
Success Retry
│
▼
END
You define state, nodes, edges, conditional routing, checkpoints, retries, human approval, and persistence—control that production systems need.
14. Event-driven multi-agent systems
Not every flow is synchronous. Events can wake agents:
AWS Event
│
▼
EventBridge
│
├────→ Security Agent
│
├────→ FinOps Agent
│
└────→ Operations Agent
Operations example:
CloudWatch Alarm
↓
EventBridge
↓
Incident Agent
↓
RCA Agent
↓
Remediation Agent
↓
Human Approval
↓
AWS API
Useful for cloud ops, security monitoring, incident response, FinOps, and automation.
15. Critic / evaluator architecture
One agent generates; another evaluates:
Generator Agent
│
▼
Generated Result
│
▼
Critic Agent
│
┌──┴──┐
▼ ▼
Pass Fail
│ │
▼ ▼
Done Retry
Architecture review example:
Architecture Agent
↓
AWS Architecture
↓
AWS Best-Practice Evaluator
↓
Pass?
/ \
Yes No
↓ ↓
Done Revise
Because model output is not automatically trustworthy, the evaluator acts as a quality gate.
16. Human-in-the-loop multi-agent systems
Full autonomy is not always appropriate for high-impact changes:
Agent
↓
Analyze
↓
Recommend
↓
Human Approval
↓
Execute
Security remediation example:
Security Agent
↓
Detect vulnerable resource
↓
Remediation Agent
↓
"Delete public access?"
↓
Human Approval
↓
AWS API
AI proposes what could be done. Policy plus human approval decide what may happen.
17. The important taxonomy
These ideas live on different layers:
MULTI-AGENT SYSTEM
│
┌────────────────┼────────────────┐
│ │ │
Architecture Reasoning Framework
Pattern Pattern / Runtime
│ │ │
▼ ▼ ▼
Supervisor ReAct LangGraph
Sequential Plan-Execute Strands
Parallel Critic Bedrock
Hierarchical AgentCore
Handoff
Swarm
Event-driven
That framing prevents false comparisons such as “LangGraph vs supervisor vs ReAct” as if they were three competing products.
18. How they combine
Power appears in composition:
User
│
▼
Supervisor
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
│ │ │
ReAct ReAct ReAct
│ │ │
└──────────┼───────────┘
▼
Critic
│
┌────┴────┐
▼ ▼
Pass Fail
│ │
▼ ▼
End Retry
A single design can mix supervisor orchestration, parallel fan-out, ReAct reasoning, critic evaluation, and retries—implemented with LangGraph, Strands, Bedrock, AgentCore, Step Functions, or custom code.
Choosing patterns under constraints
Budgets for latency, tokens, and on-call complexity should drive topology. A sequential pipeline is easier to audit when regulators care about order. Fan-out helps when independent analyses dominate wall time. Supervisors help when routing policy must stay centralized. Graphs help when you need checkpoints and human gates. Swarms and free-form handoffs demand the strongest observability investment. Pick the lightest control plane that still makes failure modes explicit.
19. Which architecture should you use?
There is no universal winner. Match control flow to the problem. The useful question is not “which framework is best?” but “what control-flow pattern does this workflow require?”
20. The emerging production architecture
Production systems surround agents with identity, permissions, tools, state, memory, guardrails, evaluation, observability, retries, cost controls, and human approval. The industry is moving from “an agent” to “an agent system.”
21. Final takeaway
Multi-agent work is about decomposing intelligence and controlling collaboration—not spawning agents for their own sake. ReAct reasons and acts; supervisors delegate; graphs control transitions; swarms decentralize; planners decompose; critics verify; humans approve. LangGraph and Strands (among others) provide implementation primitives. The engineering questions become which agents exist, how they collaborate, what they may do, how decisions are verified, and what happens on failure.
The mental model to remember
LLM
↓
Agent
↓
Multi-Agent
↓
Orchestration
↓
Tools + Memory + State
↓
Verification
↓
Observability
↓
Production Agent System
Teams that skip this systems view often scale model size while leaving orchestration, permissions, and evaluation as afterthoughts. Those gaps show up as silent wrong answers, runaway tool loops, or agents that cannot be rolled back safely. Investing in control flow, verification, and human gates usually pays more than another model swap.
The future is not only smarter models. It is better systems built around them.