# Teacher Guide — Session 7: Multi-agents & MCP **Program:** Applied AI — Intermediate Level **Instructor:** Yann Isola **Duration:** 2 hours (120 minutes) **Module covered:** Module 5 — Multi-agents & MCP (Model Context Protocol) --- ## 1. Session overview ### Educational objectives At the end of this session, each participant should be able to: 1. **Explain why split a monolithic agent into several specialized agents**: separation of responsibilities — each agent has *its* prompt system, *its* tools, *its* safeguards. 2. **Name and recognize the 4 multi-agent patterns**: orchestrator/executors (orchestrator/worker), pipeline (chain), debate/consensus, supervisor. 3. **Choose the right boss** for a given business case, and justify this choice in one sentence. 4. **Describe the 3 modes of communication between agents**: shared memory, message passing, blackboard architecture. 5. **Define MCP** (Model Context Protocol): a universal standard for connecting AI (artificial intelligence) models to tools and data sources. 6. **Draw the MCP architecture**: Host (your application) ↔ Client (inside the host) ↔ Server (which provides tools and resources). 7. **Distinguish the 3 MCP primitives**: Tools (actions invoked by the model), Resources (data controlled by the application), Prompts (reusable models). 8. **Name the 2 MCP transports**: stdio (standard input/output, standard input/output — for local) and HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events, events sent by the server — for remote). 9. **Explain the “AI USB” analogy**: a single protocol to plug any model into any tool vendor, instead of N×M custom integrations. 10. **Sketch an in-house MCP server**: expose its business logic in the form of standardized tools. ### Prerequisites - **Sessions 5 (Tools & Tool Calling) and 6 (Agentic Loop) essential.** This session generalizes: Session 5 = a tool, Session 6 = an agent, Session 7 = *several* agents and a *standard* for the tools. If a participant missed 6, have them redraw the perceive → think → act → observe loop in 3 minutes before starting. - Know how to read JSON (JavaScript Object Notation, data exchange format). - Concept of API (Application Programming Interface) and client/server. ### Materials needed - Video projector + slides (`slides/slides.md`). - Interactive web page (`webpage/index.html`) — **offline**: (1) multi-agent architecture viewer with drag and drop of agents into patterns and animated message flows; (2) MCP protocol explorer with clickable Host ↔ Client ↔ Server diagram and the 3 detailed primitives. - Worksheets (`exercises/exercises.md`). - Quiz (`quiz/quiz.md`). - Ideally one laptop for two participants (handling of the viewer in Sequence C and E). ### Central message of the session > “A single agent is an employee who does everything. A team of specialized agents is a company: each one has their role, their tools, their limits. And MCP is the USB port that allows any employee to plug in any tool — without rewiring each time. »Repeat this double idea (team + universal socket) at least three times in different forms. ### Narrative thread: NewsRoom 📰 The entire session is based on **a threaded example: NewsRoom**, a monitoring and writing system for a finance team. The typical mission: > “Every morning, produce a 500-word summary of stablecoin news: sourced, verified, proofread, and published on the internal channel. » NewsRoom agents: - 🔍 **Researcher** — tools: web search, reading articles. System prompt: “Find reliable sources, cite everything. » - ✍️ **Editor** — no external tools. Prompt system: “Write clear and structured, 500 words. » - 🕵️ **Checker** — tools: web search (cross-reading). System prompt: “Track down factual errors, be ruthless. » - 📣 **Publisher** — tool: publication on the internal channel. **Irreversible action** → human safeguard. NewsRoom illustrates **each** pattern: in pipeline (Researcher → Editor → Verifier → Publisher), in orchestrator (an editor distributes), in debate (two Editors propose, a judge decides), in supervisor (a controller monitors and takes control). Then, in the second hour, MCP answers the question: “how do all these agents access their tools without me coding 12 integrations?” » --- ## 2. Unfolded minute by minute | Schedule | Duration | Sequence | Support | |---|---|---|---| | 0:00 – 0:05 | 5 mins | Home, reminder Session 6 (the loop), objectives | Slides 1–3 | | 0:05 – 0:20 | 15 mins | Sequence A — Why multiple agents? The separation of responsibilities | Slides 4–7 | | 0:20 – 0:40 | 20 mins | Sequence B — The 4 bosses: orchestrator, pipeline, debate, supervisor | Slides 8–13 | | 0:40 – 0:55 | 15 mins | Sequence C — Manipulation: architecture viewer (drag and drop + animated flows) | Webpage (tab 1) | | 0:55 – 1:05 | 10 mins | ☕ Break | — | | 1:05 – 1:15 | 10 mins | Sequence D — Communication between agents: shared memory, messages, blackboard | Slides 14–16 | | 1:15 – 1:35 | 20 mins | Sequence E — MCP: the N×M problem, the Host/Client/Server architecture, the 3 primitives | Slides 17–24 + webpage (tab 2) | | 1:35 – 1:45 | 10 mins | Sequence F — Build your own MCP server + existing ecosystem | Slides 25–27 | | 1:45 – 1:55 | 10 mins | Flash exercise in pairs (Exercise 1) | Exercises | | 1:55 – 2:00 | 5 mins | Express oral quiz, exit tickets, announcement Session 8 | Quiz + slides 28–29 | > ⏱️ **Safety margin:** Sequence F can be compressed to 5 minutes (the MCP server catalog is on the webpage). **Never** sacrifice Sequence E: if participants leave without understanding Host ↔ Client ↔ Server, the session has missed its second half. In the event of a serious delay, Exercise 1 becomes homework. --- ## 3. Detailed notes by sequence ### Sequence A — Why multiple agents? (15 mins) **Objective:** to bring out the multi-agent need from the limits of a single agent. **Hook (3 min).** Start from Session 6: “You know how to build an agent. So let's build NewsRoom in ONE agent: a giant prompt system that says "search, write, check, publish", with the 4 families of tools. What will go wrong? » Let the room search. Expected (or expected) answers:- The **prompt system becomes a monster**: search, style, verification and publication instructions contradict each other (“be exhaustive” vs “be concise”). - **All tools for everyone**: the writing stage has no need for the publishing tool — but it does have access to it. Unnecessary risk. - **Impossible to debug**: when the synthesis is bad, was it research, writing or verification? Everything is mixed in one execution. - **Context explodes**: searches + drafts + rereads in a single context window → the agent drowns. **The principle (5 min).** State the **separation of responsibilities** (separation of concerns): each agent has… 1. **Its prompt system** — a unique, clear mission, without contradictions. 2. **His tools** — only those he needs (reminder Session 5: principle of least privilege). 3. **Its safeguards** — the Publisher has a human checkpoint; the Editor doesn't need it. Threaded analogy: **the company**. We don't hire a single person to do accounting + sales + legal + IT. Not because it's impossible — because it's *fragile*. One specialist per field, each with their own access (the accountant has the key to the safe, not the marketing intern). **Important nuance (4 min).** As in Session 6 ("agency is a property of the system"), insist: the 4 NewsRoom agents can run on **the same model** (same Claude, same GPT). What changes between them: the system prompt, the list of tools, the safeguards. Multi-agent ≠ multi-model. (We *can* mix the models — small, quick model for the Researcher, large model for the Editor — it's a refinement, not the definition.) **Counterpoint to install early (3 min).** Multi-agent is not free: more calls to the model (cost, latency), more coordination, more points of failure. Golden rule, symmetrical to Session 6: **if one agent is enough, don't use four.** We come back to this at the end of the session. --- ### Sequence B — The 4 multi-agent bosses (20 min) **Objective:** that each participant knows how to draw the 4 patterns and cite a use case for each. For each pattern: drawing on the board (or slide), carried out with NewsRoom, typical use case, main limit. About 5 minutes per boss, debate/consensus and supervisor can be grouped together if time runs out. **1. Pipeline/chain (simplest).**``` Chercheur → Rédacteur → Vérificateur → Publieur ```- Each agent receives the output of the previous one, transforms it, passes it to the next one. Flow **linear and predictable**. - Use case: document processing (extraction → normalization → validation), content generation, intelligent ETL (Extract-Transform-Load). - Limit: rigid. If the Verifier finds an error, it is necessary to provide a **backtrack** (send back to the Editor) — and already, the pure pipeline is no longer enough. - To say: “It’s the assembly line. Effective when the steps are known in advance. » **2. Orchestrator/worker — the most common.**``` ┌────────────────┐ │ ORCHESTRATEUR │ (décompose, distribue, assemble) └──┬────┬────┬───┘ ▼ ▼ ▼ Chercheur Rédacteur Vérificateur ```- A central agent **decomposes** the mission, **delegates** to specialists (in parallel if possible), **assembles** the results. The performers do not talk to each other: everything goes through the boss. - Use case: complex tasks with variable decomposition — in-depth research, multi-source analysis, report generation with independent sections. - Limit: the orchestrator is a **bottleneck** and a single point of failure. If it decomposes poorly, everything else fails. - To say: “He’s the project manager. Powerful when the decomposition is not known in advance — it is the orchestrator who decides it at execution. » Key contrast with pipeline: pipeline = steps set by the developer; orchestrator = steps decided by the model. **3. Debate/consensus.**``` Rédacteur A ──┐ ├──▶ JUGE ──▶ meilleure version (ou synthèse) Rédacteur B ──┘ ```- Several agents produce **independent** answers (or compete in several rounds of arguments), then a judge decides or a vote results in consensus. - Use case: high-stakes decisions, reduction of errors (a hallucination is unlikely to be committed identically by two independent agents), critical review (a “devil's advocate” agent). - Limit: cost multiplied by the number of debaters. To be reserved for decisions that merit it. - A telling example for this audience: validation of a regulatory risk analysis — two agents analyze independently, discrepancies are traced back to a human. Convergences give confidence; discrepancies provide information. **4. Supervisor.**``` ┌──────────────┐ │ SUPERVISEUR │ (observe, valide, interrompt, réassigne) └──────┬───────┘ surveille ┌───────┼─────────┐ ▼ ▼ ▼ Agent 1 Agent 2 Agent 3 (qui travaillent, éventuellement en pipeline) ```- An agent (or a component) **monitors** the execution of others: checks outputs, detects drifts (infinite loops, off-topic, rule violation), can interrupt or reassign. - Difference with the orchestrator: the orchestrator *distributes the work*; the supervisor *controls quality and safety*. The two are often combined. - Use case: environments with strong compliance (finance, health, legal) — the supervisor is the permanent control layer. - To say: “The orchestrator is the project manager; the supervisor is quality control + the compliance manager. » **Summary (2 min).** Summary table (slide 13): | Boss | Who decides the flow? | Strength | Weakness | |---|---|---|---| | Pipeline | The developer (fixed) | Simple, predictable, debuggable | Rigid | | Orchestrator | The orchestrator (dynamic) | Flexible, parallelizable | Central neck | | Debate | The judge / the vote | Cross-check reliability | Cost ×N | | Supervisor | Agents + continuous monitoring | Security, compliance | Complexity | --- ### Sequence C — Visualizer manipulation (15 min) **Objective:** anchor patterns through manipulation. Open `webpage/index.html`, tab **“Multi-agent architectures”**. Participants (in pairs if mobile phones are available, otherwise you on the video projector with the room guiding): 1. **Choose a boss** (pipeline, orchestrator, debate) — the board displays the boss locations. 2. **Drag NewsRoom Agents** (Researcher, Editor, Reviewer, Publisher, Judge, Orchestrator) into slots. 3. **Start the animation**: the messages flow along the arrows, with the content of each message displayed in the log (“Researcher → Editor: 5 sources found…”). 4. **“Inject Error”** button: Checker rejects the draft — observe how each boss handles rollback (the pipeline shows this explicitly). **Instructions to give:** “Place the agents for the pipeline boss, launch, then respond: when does the Publisher receive anything? What happens if the Verifier rejects? » Then do it again as an orchestrator and compare the number of messages exchanged. **Debrief (3 min):** Have a participant verbalize the pipeline/orchestrator difference. The correct wording expected: “in the pipeline, the path is fixed in advance; with the orchestrator, it is an agent who decides the path. » --- ### Sequence D — Communication between agents (10 min) **Objective:** know the 3 mechanisms by which agents exchange, with their compromises. **1. Message passing.** Each agent explicitly sends messages to other agents (like internal emails). This is the natural mechanism of the pipeline and orchestrator. - ✅ Traceable (each message can be logged), decoupled. - ❌ We must define *who speaks to whom* — the topology. - NewsRoom: the orchestrator sends “mission: find 5 sources” to the Researcher, who responds “here are the 5 sources”. **2.Shared memory.** All agents read and write in a common space (the complete history, a database, a shared document). - ✅ Simple: everyone sees everything. - ❌ The context expands quickly; risks of interference (one agent crushes or pollutes what another uses); no compartmentalization — contradictory with the separation of responsibilities if we are not careful. - NewsRoom: a shared folder where the Researcher places his sources and where the Editor draws. **3. Blackboard.** Structured refinement of the shared memory: a common **organized** space (sections, statuses) where each agent submits their contributions and is triggered when information that concerns them appears. - ✅ Ideal when the order of contributions is not known in advance; everyone contributes when they can. - ❌ More complex to set up (which is triggered when?). - Analogy: the **whiteboard in the crisis room** — everyone writes there what they know, and reacts to what others have written there. NewsRoom: a table with the sections “sources”, “draft”, “objections”, “publication status”; the Checker wakes up as soon as a draft appears. **To summarize:** “Messages = company emails. Shared memory = the common network folder. Blackboard = the whiteboard of the crisis room. All three exist in your human organizations — it's exactly the same for agents. » **Transition to MCP (1 min, important):** “We know how to make *agents talk to each other*. There remains one problem: each agent must also talk to *their tools* — the database, web search, GitHub, Slack. And there, historically, is chaos. Let's see why, and see the standard that puts an end to it. » --- ### Sequence E — MCP: the universal standard (20 min) ⭐ heart of the second hour **Objective:** Host ↔ Client ↔ Server architecture understood and the 3 primitives distinguished. **1. The N×M problem (4 min).** On the board: on the left, 3 models/applications (Claude, GPT, your internal app); on the right, 4 tools (database, web search, GitHub, Slack). Draw all the arrows: **3 × 4 = 12 integrations** to code, maintain, secure — each with its format, its authentication, its bugs. Add a template: +4 integrations. Add a tool: +3. This is the **N×M problem**. A telling historical reminder: before USB (Universal Serial Bus), each peripheral had its own socket — mouse port, printer port, keyboard port. USB imposed **one** socket, **one** protocol: any device on any computer. **MCP (Model Context Protocol) is the USB of AI**: proposed at the end of 2024 ⚠ by Anthropic, since adopted by the main players in the ecosystem ⚠. With MCP: N + M connectors instead of N × M. **2. The Host ↔ Client ↔ Server architecture (8 min).** The trio to know by heart — project the diagram (slide 20) and open tab 2 of the webpage:``` ┌───────────────────────────────┐ ┌──────────────────────┐ │ HÔTE (host) │ │ SERVEUR MCP │ │ = votre application │ │ = fournit outils, │ │ (Claude Desktop, IDE, │ │ ressources, prompts│ │ votre app NewsRoom…) │ │ (ex. serveur GitHub) │ │ ┌───────────────────┐ │ │ │ │ │ CLIENT MCP │◀─────▶│ │ │ │ │ = connecteur dans │ 1 ↔ 1 │ │ │ │ │ l'hôte │ │ │ │ │ └───────────────────┘ │ └──────────────────────┘ └───────────────────────────────┘ ```- **Host**: the application where the model lives — Claude Desktop, an IDE (Integrated Development Environment), your NewsRoom application. It is he who decides which servers to connect and applies the authorizations. - **Client (client)**: the component *inside* the host which manages the connection with **a** server (1↔1 relationship: one client per server). The host talking to 3 servers contains 3 clients. - **Server**: the program that **exposes** capabilities — tools, resources, prompts. Example: the MCP server “GitHub” exposes `créer_issue`, `lire_fichier`… **Complete analogy to give:** the host is the **computer**, the client is the **USB port**, the server is the **device**. Another formulation that helps: the MCP server is an *adaptor* placed in front of an existing service (GitHub, your database, etc.) which translates this service into the standard MCP language. **Trap #1 to avoid:** “server” does NOT mean “large machine in a data center”. An MCP server is often a **small local program** of a few hundred lines, launched on your own computer. The word designates a *role* in the protocol (the one that provides), not an infrastructure. **Pitfall #2:** The MCP server does not contain **an AI model. It exhibits capabilities; intelligence remains on the host side. **3. The two transports (2 min).** How do client and server actually talk to each other? - **stdio** (standard input/output, standard input/output): the server is a **local** process launched by the host, dialogue through the system input/output channels. Simple, fast, everything stays on the machine. Typical case: filesystem server on your workstation. - **HTTP+SSE** (HyperText Transfer Protocol + Server-Sent Events, events sent by the server): the server is **remote**, accessible via the network; SSE allows the server to push events to the client. Typical case: corporate MCP server shared by all teams. ⚠ Remote transport is evolving (“streamable HTTP” variants) — remember the idea: *stdio = local, HTTP = remote*. **4. The three primitives (6 min).** What a server can expose — click the three cards in the webpage: | Primitive | Who decides to use it? | What is it | Example (GitHub server) | |---|---|---|---| | **Tools** | **The model** (model-invoked) | Executable actions — Session 5 tool calling, standardized | `créer_issue(titre, corps)` | | **Resources** (resources) | **The application** (app-controlled) | Read data that the host injects into the context | the contents of `README.md` | | **Prompts** (prompts) | **The user** (via host) | Ready-to-use, customizable prompt templates | “analyze this pull request” | The point that differentiates everything: **who has the hand**. Tools → the model decides to act (with the safeguards of Sessions 5–6). Resources → the application decides what to show to the model (like the RAG, Session 4: we *give it to read*). Prompts → the user chooses a prompt template from a menu. Three primitives, three different “triggers”.**Complete loop to unfold orally (with NewsRoom):** the Researcher (in the host) wants to search → the host asks the client for the list of server tools "web search" → the model chooses `recherche_web(requête)` → the client transmits the call to the server → the server executes and returns the result → the result returns in the agent's loop (the "observe" step of the Session 6!). **Nothing new in the loop — only the connection is standardized.** --- ### Sequence F — Ecosystem & building your server (10 min) **Objective:** make MCP concrete and actionable tomorrow. **The existing ecosystem (4 min).** MCP servers available off the shelf ⚠ (the ecosystem grows every week): **filesystem** (read/write local files), **databases** (PostgreSQL, SQLite…), **web search**, **GitHub** (issues, PR, code), **Slack** (read/post), browser, calendars… The reflex to install: **before coding an integration, find out if it exists already an MCP server.** **Build your own (5 min).** When your business logic does not exist on the shelf (eg: your internal CRM - Customer Relationship Management), you write an MCP server that exposes it. Conceptual skeleton (no code to write in session, show the pseudo-code of slide 26):``` serveur = nouveau ServeurMCP("crm-interne") serveur.tool("chercher_client", description: "Recherche un client par nom ou e-mail", schéma: { requete: string }, exécution: (args) => crm.chercher(args.requete)) serveur.resource("crm://clients/actifs", description: "Liste des clients actifs", lecture: () => crm.listeActifs()) serveur.démarrer(transport: stdio) ```Three messages to hammer home: 1. Each `tool` = exactly the tool definition from Session 5 (name, description, input schema) — **you already know how to do this**. 2. Write the server **once** → all your hosts (Claude Desktop, your NewsRoom agents, the IDE) benefit. This is the N+M gain. 3. Security does not change: least privilege, human validation for the irreversible — the standard does not exempt from any safeguards. **Complete the loop (1 min):** “First hour: specialized agents who collaborate. Second hour: a universal socket for their tools. Complete NewsRoom is: 4 agents in a supervised pipeline, each connected to its MCP servers. You now have all the pieces of a professional multi-agent system. » --- ## 4. Attendee Frequently Asked Questions (and Answers) **“Multi-agent, is it several different models? »** No — often the same model with different prompt systems, tools and safeguards. We *can* vary the models (economy: small model for simple tasks), but that is not the definition. **“Why not put everything in one big prompt? »** It works…to a point. Conflicting instructions, saturated context, impossible debugging, overexposed tools. Multi-agent is to a giant prompt what functions are to a 3,000-line script. **“Does MCP replace tool calling? »** No, he **standardizes** it. Tool calling (Session 5) remains the mechanism; MCP standardizes how to discover and connect tools. Analogy: USB didn't replace keyboards — it standardized the socket. **“Is an MCP server a cloud service? »** Not necessarily — it's often even a small local process (stdio transport). “Server” refers to the role (capacity provider), not infrastructure. **“What is the difference between Resource and Read-only Tool?” »** The trigger. A tool `lire_fichier` is invoked *by the model* when it deems it useful. A resource is injected *by the application* (or chosen by the user). Same data, different control — and control is the whole issue in production. **“The debate multiplies the costs by two or three — is it worth it? »** Only for high-stakes decisions where the cost of a mistake far exceeds the cost of appeals. For a daily summary: no. To validate a regulatory analysis before sending it to a regulator: yes. **“Is MCP unique to Anthropic? »** The protocol was initiated by Anthropic (end of 2024 ⚠) but published in **open** standard; it is adopted beyond Anthropic ⚠. The point of a standard is precisely that it does not belong to anyone in practice. --- ## 5. Educational pitfalls to avoid 1. **Stack the 4 patterns without contrasting them.** What stays in mind is the comparative table “which decides the flow”. Spend time there. 2. **Present MCP as another technology.** It is a *standard* — the value is in the sharing (N+M), not in a functionality. Without the N×M problem first, MCP appears free. 3. **Let “server” refer to a data center.** Explicitly say: “an MCP server fits in a small local script”. Otherwise half the room imagines the cloud. 4. **Drown the room in the 3 primitives.** The essentials: Tools = the model decides, Resources = the app decides, Prompts = the user chooses. The rest is details. 5.**Sell multi-agent everywhere.** Symmetric of Session 6: one agent (or even a prompt) is often enough. A credible trainer says when NOT to multiply agents. 6. **Forget the bridge with Sessions 5–6.** Each new feature must be hung up: tool MCP = S5 tool definition; tool result = “observe” S6. Participants should feel continuity, not a new world. --- ## 6. Exit tickets (5) To be distributed in the last 5 minutes. One sentence response is enough. 1. **Why split a monolithic agent into several specialized agents? (one argument is enough)** *(Expected, one of: prompt systems without contradictions; tools limited to the needs of each person / least privilege; targeted safeguards; debugging by agent; controlled context.)* 2. **Name the 4 multi-agent patterns seen today.** *(Expected: pipeline, orchestrator/performers, debate/consensus, supervisor.)* 3. **What does MCP mean and what problem does it solve?** *(Expected: Model Context Protocol — a universal standard that avoids coding N×M integrations between models and tools: “the USB of AI.”)* 4. **In MCP architecture, who are the Host, Client and Server?** *(Expected: Host = the application where the model lives; Client = the connector in the host, one per server; Server = the program that exposes tools/resources/prompts.)* 5. **What is the difference between a Tool and an MCP Resource?** *(Expected: the Tool is invoked by the model (action); the Resource is controlled by the application (data injected on read).)* --- ## 7. Bridge to the sequel - **Acquired after this session:** the architecture of agent teams (4 bosses + 3 communication modes) and the universal standard for connection to tools (MCP: Host/Client/Server, Tools/Resources/Prompts, stdio/HTTP+SSE). - **Next session (Session 8):** according to the program — production, evaluation and observability of agentic systems. Suggested hook: “You now know how to *build* a multi-agent system. Next week: How to know if it *really* works — measure, monitor, improve. Until then, a challenge: identify a task in your profession that would merit a team of agents rather than just one, and note which boss you would choose. We will open the session with your cases. »