Rag And Agents
Multi-Agent Systems
Chapter 4's single agent handles one task with one set of tools and one system prompt. As tasks grow more complex, a single agent juggling many different tools,
Jr Codex NLP & LLM Notes
Level: Advanced Prerequisites: Chapter 4: Agents & Tool Use Time to complete: ~20 minutes
Table of Contents
- Why Use Multiple Agents
- Common Multi-Agent Patterns
- The Orchestrator Pattern
- Implementing a Simple Multi-Agent System
- Connecting Back to the AI Notes' Multi-Agent Systems
- When Multi-Agent Complexity Is (and Isn't) Worth It
- Summary & Next Steps
1. Why Use Multiple Agents
Chapter 4's single agent handles one task with one set of tools and one system prompt. As tasks grow more complex, a single agent juggling many different tools, instructions, and responsibilities can become confused or unreliable — directly echoing a general software engineering principle: separation of concerns.
The Core Motivation
─────────────────────────────────────────
A SINGLE agent instructed to "research a topic, write a
report, AND fact-check the report" must hold ALL THREE
roles' instructions and context SIMULTANEOUSLY — increasing
the chance of confusing which INSTRUCTIONS apply at which
MOMENT. SPLITTING this into SEPARATE agents — a researcher,
a writer, a fact-checker — each with a FOCUSED system prompt
(Module 7, Ch.1, Sec.3) and a NARROW tool set, tends to
produce MORE reliable results for each sub-task.
─────────────────────────────────────────
2. Common Multi-Agent Patterns
Three Structural Patterns
─────────────────────────────────────────
Sequential (pipeline): agent A's OUTPUT becomes agent
B's INPUT, becomes agent C's
input — a linear CHAIN
Orchestrator-worker: a CENTRAL "orchestrator" agent
decides WHICH specialized
"worker" agent to invoke for
each SUB-task, and combines
their results (Section 3)
Debate/collaboration: MULTIPLE agents work on the
SAME problem, potentially
critiquing or REFINING
each other's work before
converging on a final
answer
─────────────────────────────────────────
3. The Orchestrator Pattern
The most common and flexible pattern: an orchestrator agent breaks down a complex request and delegates sub-tasks to specialized workers — directly analogous to Chapter 4's single agent choosing which TOOL to call, except now the "tools" are themselves full agents.
Orchestrator-Worker Structure
─────────────────────────────────────────
User request
│
▼
Orchestrator agent — decides WHICH worker(s) are needed,
and in WHAT order
│
├──► Researcher agent (has WEB SEARCH / RAG tools, Ch.1-3)
├──► Writer agent (focused on PROSE quality, no tools needed)
└──► Fact-checker agent (has SEARCH tools, verifies claims)
│
▼
Orchestrator combines results into a FINAL response
─────────────────────────────────────────
4. Implementing a Simple Multi-Agent System
def researcher_agent(client, topic, search_tool):
messages = [
{"role": "system", "content": "You are a research assistant. Use the search tool to gather facts. Report findings concisely."},
{"role": "user", "content": f"Research: {topic}"},
]
return run_agent(client, messages, tools=[search_tool], tool_functions={"search_web": search_tool}) # Chapter 4
def writer_agent(client, research_notes, topic):
messages = [
{"role": "system", "content": "You are a skilled writer. Write clear, engaging prose based on the provided research notes."},
{"role": "user", "content": f"Topic: {topic}\n\nResearch notes:\n{research_notes}\n\nWrite a short article."},
]
response = client.chat.completions.create(model="gpt-4", messages=messages)
return response.choices[0].message.content
def fact_checker_agent(client, article, research_notes):
messages = [
{"role": "system", "content": "You are a fact-checker. Verify the article's claims against the research notes. Flag any unsupported claims."},
{"role": "user", "content": f"Article:\n{article}\n\nResearch notes:\n{research_notes}"},
]
response = client.chat.completions.create(model="gpt-4", messages=messages)
return response.choices[0].message.content
def orchestrate_article_writing(client, topic, search_tool):
research_notes = researcher_agent(client, topic, search_tool)
draft_article = writer_agent(client, research_notes, topic)
fact_check_result = fact_checker_agent(client, draft_article, research_notes)
return {"article": draft_article, "fact_check": fact_check_result}Each agent has a NARROWLY focused system prompt and, where relevant, a LIMITED tool set — directly the separation-of-concerns benefit from Section 1, made concrete.
5. Connecting Back to the AI Notes' Multi-Agent Systems
AI Notes, Module 5, Chapter 2 covered multi-agent systems from a classical AI perspective — cooperative and competitive agents, coordination problems, game-theoretic considerations. Those same foundational concerns apply directly here, now with LLM-based agents instead of classical, rule-based ones.
What Carries Over Directly From the AI Notes
─────────────────────────────────────────
Coordination problems: MULTIPLE agents needing to avoid
duplicated or CONFLICTING work
— the orchestrator (Section 3)
exists SPECIFICALLY to manage
this
Communication protocols: HOW agents pass information to
each other (Section 4's
research_notes being passed
from researcher to writer to
fact-checker) — a SIMPLIFIED,
text-based version of the
formal communication
protocols discussed in the
AI Notes
Emergent system behavior: the OVERALL system's
behavior depends on HOW
individual agents
interact, not just each
agent's OWN capability in
isolation — the SAME
principle covered
generally in the AI Notes,
now instantiated with
LLM-based agents
specifically
─────────────────────────────────────────
6. When Multi-Agent Complexity Is (and Isn't) Worth It
A Practical Decision Guide
─────────────────────────────────────────
Simple, single-purpose task: a SINGLE agent (Chapter 4)
is simpler, cheaper, and
easier to debug — don't
add multi-agent complexity
WITHOUT a clear need
Complex task with GENUINELY multi-agent decomposition
DISTINCT sub-responsibilities (Sections 1-4) can
(research vs writing vs improve reliability
fact-checking): and MAINTAINABILITY,
at the cost of
MORE total LLM
calls (higher
cost/latency,
Module 9)
─────────────────────────────────────────
This directly echoes the ML Notes' "start simple" workflow principle, applied one more time: multi-agent systems add genuine value for genuinely complex, decomposable tasks, but are not a default architecture to reach for automatically.
7. Summary & Next Steps
Key Takeaways
- Multi-agent systems apply separation of concerns to LLM-based agents, splitting complex tasks into narrower, more reliably executed sub-responsibilities.
- The orchestrator-worker pattern is the most common structure: a central agent delegates sub-tasks to specialized workers and combines their results.
- Multi-agent coordination concerns — communication protocols, avoiding duplicated work, emergent system behavior — directly extend the classical multi-agent concepts from the AI Notes to LLM-based agents.
- Multi-agent complexity should be reserved for genuinely complex, decomposable tasks; a single agent remains the simpler, cheaper default for straightforward tasks.
Module 8 Complete — What's Next
You've now covered the complete path from grounding an LLM in external knowledge (RAG) to giving it the ability to take multi-step actions (agents) and coordinate multiple specialized agents on complex tasks. Module 9 covers how to rigorously evaluate everything built across this curriculum — classical NLP metrics, LLM-specific evaluation, production deployment, and a full capstone project.
Concept Check
- Why might splitting a complex task across multiple narrowly-focused agents produce more reliable results than one agent handling everything?
- What role does the orchestrator play in an orchestrator-worker multi-agent system?
- What AI Notes concept does "avoiding duplicated or conflicting work between agents" directly extend?
Next Module
→ Module 9: Evaluation, Production & Capstone
Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to NLP & LLM Index