Module 3: Agentic Architecture and Orchestration

Lesson 1: Single-agent vs Multi-agent Systems

In the early days of LLM engineering, we built "Monoliths"—single agents with long prompts and 50 tools. As systems scaled, these monoliths crumbled under the weight of Context Exhaustion and Tool-Choice Hallucination.

In this lesson, we define the shift to Multi-Agent Systems (MAS) and learn the architectural triggers that tell you it's time to split your "God Agent" into a "Team."

---

1. The Monolith (Single-Agent)

A single-agent system uses one model to handle perception, planning, and execution for the entire task.

Best For:

• Simple, linear workflows (e.g., "Summarize this file and email it").
• Tasks with a tiny toolset (1-3 tools).
• Prototyping and MVPs.

The Breakdown Point:

As you add more tools or more complex instructions, the model's "Attention" is diluted. If you have 30 tools, Claude might pick the "Read" tool when it should have picked the "Write" tool because the descriptions are too close together in the context window.

---

2. The Multi-Agent System (MAS)

In an MAS, you distribute "Mental Load." You have specialized agents (Experts) that only know how to do one thing well.

Typical Experts:

• The Coder: Only knows Python and syntax.
• The Researcher: Only knows search tools and RAG.
• The Critic: Only knows how to find errors in the other two.

---

3. The "Law of Specialized Context"

The fundamental reason MAS is superior for complex tasks is Signal-to-Noise Ratio (SNR).

• In a Single-Agent system, the "Coder" logic competes with the "Researcher" logic for the same 200k context window.
• In a Multi-Agent system, the "Coder" has a 100% focused context about coding.

---

4. Comparison Matrix

Feature	Single-Agent	Multi-Agent
Complexity	Low	High
Reliability	Drops as tools increase	High (Specialized Focus)
Latency	Low (Single turn)	High (Handoffs/Coordination)
Cost	Flexible	Generally Higher

---

5. Architectural Trigger: The "Rule of Three"

As an architect, keep an eye on these three triggers. If any are met, consider a Multi-Agent approach:

1. Tool Bloat: > 5-7 distinct tools.
2. Context Fragmentation: The agent needs to handle vastly different types of data simultaneously (e.g., Structured SQL + Unstructured Legal PDFs).
3. Requirement for Verification: The agent's output is high-stakes and needs a "Second Pair of Eyes."

---

6. Summary

• Single-Agent is a Swiss Army Knife. Good for everything, master of nothing.
• Multi-Agent is a surgical team. Each member is the best at their specific task.

In the next lesson, we will look at the most common way to coordinate this surgical team: The Planner-Executor Pattern.

---

Interactive Quiz

1. Why does a single-agent system hallucinate more as you add more tools?
2. What is the "Rule of Three" trigger for choosing a Multi-Agent architecture?
3. In which scenario would a Single-Agent be faster than a Multi-Agent system?
4. True or False: Multi-agent systems always cost more tokens than single-agent systems.

---

Reference Video: