Multi-agent architectures: paradigms and patterns [4]
Multi-agent doesn't just mean multiple models. It means deliberate specialization — and choosing the right structure for what you're building.
![Featured image for "Multi-agent architectures: paradigms and patterns [4]"](/images/4.jpg)
Image: Arp 248 — NASA/ESA Hubble Space Telescope
In the previous posts we covered the foundational layer: what LLMs are, how agents use context, how RAG works, and when fine-tuning makes sense. Now we move up a level.
Multi-agent architectures aren’t just a way to add more models. They’re a design pattern — a way to structure complex AI systems so that each part does one thing well.
Why specialization matters
Here’s a concrete example that makes this intuition precise.
Suppose you have a handwritten document. You want to extract its content via OCR and anonymize the result — removing names, dates, and identifying information. The naive approach: write a single system prompt that says “extract the text and anonymize it.”
This is a classic case where a single-agent approach degrades quality.
An LLM generates text by computing probability distributions over the next token at each step. When you ask it to simultaneously recognize characters, reconstruct coherent prose, and apply anonymization rules, those three objectives compete. The model’s attention is split across conflicting requirements, and the output suffers accordingly.
Research confirms this: a 2025 study on multi-task prompting tested LLMs across progressively combined NLP tasks and documented systematic performance degradation as task count increased — up to a 59% drop in task-specific accuracy when multiple objectives were combined into a single prompt.
The solution: decompose. One agent extracts and reconstructs the text. A second agent handles anonymization. Each one does one thing, and does it well.
This principle — deliberate specialization — is the foundation of multi-agent design.
The core paradigms
Supervisor
The most common pattern. A supervisor agent:
- manages the conversation with the user
- understands the request and decides whether to answer directly, call a tool, or delegate to a sub-agent
- formulates the final response
Everything flows through the supervisor. Sub-agents and tools are invoked when needed but don’t talk to the user directly. In contexts where output format and editorial consistency matter, the supervisor can pass the final response to a dedicated editorial agent before it reaches the user.
Sequential
Two or more agents in sequence, where the output of one becomes the input of the next. The steps are interdependent — which is both the strength and the weakness.
Strength: each step can be precisely optimized. Weakness: errors compound. If step N produces degraded output, step N+1 has no way to know. In the absence of explicit errors, quality degrades silently from one agent to the next — and tracing the failure back to its origin requires examining the output of each individual step. Sequential pipelines are the hardest to debug in practice.
Parallel
Multiple agents run simultaneously on independent tasks, and results are combined. Example: to answer a complex question, you simultaneously run a RAG retrieval, a live web search, and a query against an internal system. The final answer synthesizes all three.
The dependency constraint is strict: if task B needs the output of task A, it’s sequential, not parallel.
Loop
An agent (or pipeline) that repeats until a condition is met. The canonical example is the writer/reviewer pattern: one agent generates content, another evaluates it against specific criteria, and the loop continues until the reviewer approves — or a maximum iteration count is reached.
Loops also appear in batch processing: run the same agent N times over N documents, accumulating results incrementally. The termination condition matters — an uncapped loop is a runaway process.
Composition
These patterns can be nested. A parallel workflow where each branch is itself a sequential pipeline. A supervisor that delegates to a loop-based quality assurance agent before returning a response. Real systems are usually compositions of the basic patterns, not pure instances of a single one.
Graph-based and dynamic workflows
The paradigms above describe fixed structures. Modern frameworks — LangGraph, Google ADK — implement more flexible approaches.
Graph workflows define execution as a graph where nodes are agents, functions, or sub-workflows, and edges define how data flows between them. Edges can be conditional, and the graph can contain cycles. This is what LangGraph’s StateGraph implements — a centralized state object shared across all nodes, with routing determined at each step by conditional edge logic.
Dynamic workflows take a different approach entirely. Instead of defining execution paths as a graph, you write the workflow as regular code — using while loops, if statements, asyncio.gather for parallel execution, and recursive calls. Nodes are defined with simple decorators and invoked as functions via ctx.run_node().
What this unlocks: loops over variable-length inputs without pre-wiring a branch per item, conditional branching that goes beyond what static graph edges can express, and native parallel execution. Automatic checkpointing means that if a workflow is interrupted, already-completed nodes are skipped on resume rather than re-executed.
The fundamental shift: in a graph workflow you configure routing; in a dynamic workflow you write it. This makes complex patterns — iterative quality loops, batch processing, human-in-the-loop pauses — easier to implement and maintain at the cost of less visual structure.
What’s next
The paradigms are the structure. The next post covers what you actually compose them from: tools, callbacks, skills, and the agent-as-tool pattern — the building blocks inside the architecture.
If you have questions or want to suggest a topic, reach out.