A multi-agent system orchestrates several specialized agents to solve a problem that a single agent can’t easily manage.1 The core principle is decomposition: break a large objective into smaller sub-tasks and assign each to a dedicated agent with a specific skill. Those agents then interact through collaborative or hierarchical workflows to reach the final goal.
The argument for it is modularity. Compared with a single agent carrying a monolithic prompt, a set of narrowly scoped agents is more scalable, more reliable, and more maintainable — each one has a smaller job to get right.
Context engineering
Every agent in the system needs the specific context required to do its own task. Context here means documentation, historical preferences, relevant links, conversational history, or operational constraints. Managing that flow of information is context engineering, and the source names three strategies:
- Isolating context to the specific agent that needs it,
- persisting information across multiple steps,
- compressing large amounts of data to improve efficiency.
This is the tax that grows fastest as agent count grows: the decomposition that makes each agent simpler also means no single agent sees the whole picture, and what each one does see becomes a design decision.
Those three strategies have a direct counterpart in Anthropic’s long-horizon techniques — sub-agents isolate, structured note-taking persists, compaction compresses — which is some evidence the triad is real rather than one source’s framing. Context Engineering treats the discipline in its own right, including why context is a scarce resource in the first place.
What it costs you
Multi-agent systems need more evaluation, security, reliability, and cost work than a single agent. Concretely:
- precise access controls for each specialized agent,
- a robust orchestration system for reliable inter-agent communication,
- higher operational costs from the computational overhead of running multiple agents.
The two families
The multi-agent patterns split on one question — what decides which agent runs next?
Code decides (workflow agents operating on predefined logic, without consulting a model for orchestration):
- Sequential — fixed linear chain.
- Parallel — concurrent fan-out, then a gather step.
- Loop — repeat until an exit condition, with two named implementations: review and critique and iterative refinement.
A model decides (dynamic orchestration at runtime):
- Coordinator — a central agent routes sub-tasks, with hierarchical task decomposition as its multi-level implementation.
- Swarm — all-to-all collaboration with no orchestrator at all.
Code-driven orchestration is cheaper and more predictable; model-driven orchestration is more flexible and adapts at runtime. That trade sits behind most of the pattern-selection guidance in Choosing an Agentic Design Pattern.
A worked reference architecture for building one of these on Google Cloud is published separately as Multi-agent AI systems in Google Cloud.
Footnotes
-
Samantha He, “Choose a design pattern for your agentic AI system”, Google Cloud Architecture Center, last reviewed 2026-05-28. Local copy:
references/google-cloud-agentic-design-patterns.md. ↩