# Exercises — Session 7: Multi-agents & MCP

**Program:** Applied AI — Intermediate Level · Instructor: Yann Isola
**General instructions:** work in pairs. No code to write — we think like an agent systems architect. The corrections are at the end of the document: only read them after you have really tried.

---

## Exercise 1 — Choosing the right boss (≈ 15 min)

*Objective: know how to associate a business need with the appropriate multi-agent pattern, and justify it.*

For **each** of the following five needs, choose the most suitable pattern from:
**A. Single agent** (no multi-agent — Session 6 reminder) · **B. Pipeline (chain)** · **C. Orchestrator/performers** · **D. Debate/consensus** · **E. Supervisor** (in combination with another boss if necessary).

Justify each choice in one or two sentences. Several defensible answers exist: what matters is the justification.

1. **Processing of supplier invoices:** extract the fields from the PDF (Portable Document Format) → standardize the amounts and currencies → check consistency with the purchase order → record in accounting. The 4 steps are always the same, always in this order.

2. **Risk analysis before publication of a regulatory notice:** the error would be very costly (reputation, regulator). We want to reduce the risk of hallucination or forgetting as much as possible.

3. **“Prepare me a complete file on company

4. **“Rephrase this email in a more diplomatic tone. »**

5. **A system of assisted trading agents** (order preparation, never autonomous execution) operating within a strict compliance framework: each exit must be controlled, any deviation detected and stopped immediately.

**Bonus question:** for case 1, what should be planned if the “check consistency” step detects an inconsistency? How does this “twist” the chosen pattern?

---

## Exercise 2 — MCP Architect (≈ 20 min)

*Goal: Apply Model Context Protocol (MCP) architecture to a real business case.*

**Background.** You are in a brokerage firm. Three internal applications use AI (artificial intelligence):

- **AssistDesk** — customer service assistant (desktop application for call center agents)
- **RiskWatch** — risk monitoring agent (runs on a team server)
- **DevCopilot** — the IDE (Integrated Development Environment) augmented by developers

These applications need access to four systems:

- The **customer base** (CRM — Customer Relationship Management)
- The **compliance framework** (internal regulatory documents, read only)
- **GitHub** (source code, issues)
- **Team messaging** (post alerts)

**Questions:**

1. **Without MCP:** How many custom integrations would you need to code if each application connects directly to each system it needs? Detail who needs what (reasonable choice to justify) then count. Then give the theoretical maximum number (all applications × all systems).

2.**With MCP:** how many MCP servers should I write or install? Which ones probably already exist on the shelf ⚠, which ones will need to be developed internally?

3. For each MCP server, say which **transport** you would choose — stdio (standard input/output, local) or HTTP+SSE (HyperText Transfer Protocol + Server-Sent Events, remote) — and why. Hint: where does each application run, and does the server need to be shared?

4. Classify each of the following elements into the correct **MCP primitive** — Tool (tool, invoked by the template), Resource (resource, controlled by the application), or Prompt (prompt template, chosen by the user):
a. `chercher_client(nom_ou_email)` in CRM
b. The full text of the internal “complaints processing” procedure
c. A pre-written model “Analyzes this customer complaint according to our compliance grid”, which the telephone advisor selects from a menu
d. `poster_alerte(canal, message)` in messaging
e. The list of open GitHub issues, automatically injected into the context of DevCopilot when opening a project

5. **Security:** the `poster_alerte` tool publishes on a channel read by 200 people. What guardrail (Sessions 5–6) do you apply, and where do you place it—in the MCP server or in the host? Argue.

---

## Exercise 3 — Design the agent team (≈ 20 min)

*Objective: design a complete multi-agent system — agents, boss, communication, MCP connection.*

**Mission to be automated.** The legal department receives dozens of supplier contracts every week to review. The current human process:

1. Read the contract and extract the key clauses (duration, termination, liability, penalties).
2. Compare each clause to the company's internal contractual policy.
3. Write a summary note: compliant clauses ✅, clauses to negotiate ⚠, blocking clauses ⛔.
4. If at least one clause is blocking: immediately alert the referring lawyer by email.
5. Archive the note in the EDM (Electronic Document Management).

**Questions:**

1. **Breakdown:** propose a team of 3 to 5 specialized agents. For each: a name, its mission in one sentence (the essence of its prompt system), and the list of its tools. Respect least privilege: no agent should have a tool they do not need.

2. **Pattern:** which multi-agent pattern do you choose? Draw the flow (arrows between agents). Justify at least one alternative that you reject.

3. **Communication:** messages, shared memory or blackboard? Justify in one sentence.

4. **MCP connection:** list the necessary MCP servers (shelf or home) and say which agent connects to which.

5. **Guardrails:** identify the sensitive action(s) of the system and place the human control point(s) (human-in-the-loop). Should the alert to the lawyer (step 4) be subject to human validation? Defend your position — there is real debate.

6. **Critical question:** a colleague tells you “all this would fit into ONE agent with a good prompt”. Give two arguments to answer him… then a scenario where he would be right.

---
---

# Fixed

## Answer key — Exercise 1

**1. Supplier invoices → B. Pipeline.** The steps are known in advance, fixed, ordered: extraction → standardization → verification → recording. This is the typical assembly line.An orchestrator would be over-engineering: there is no decomposition to decide dynamically.

**2. High-stakes regulatory notice → D. Debate/consensus.** Two (or three) agents analyze **independently**; a judge compares. Convergences strengthen trust; the discrepancies trace back to a human — this is precisely information about risk. The additional cost (×2 or ×3 calls) is negligible compared to the cost of an error with the regulator. *(Answer E accepted in addition: a supervisor can add to the debate.)*

**3. Company file A fixed pipeline would sometimes be too much, sometimes not enough.

**4. Email reformulation → A. Single agent** — and even, strictly speaking, a **simple prompt** without tools (reminder Session 6: don't over-engineer). Any multi-agent architecture here is waste: cost, latency, complexity without benefit.

**5. Assisted trading under strict compliance → E. Supervisor** (combined, typically, with a pipeline or orchestrator for the work itself). The dominant need is **continuous control**: check each output, detect deviations, interrupt. To be distinguished from the orchestrator: the latter *distributes the work*, the supervisor *controls quality and safety*. In finance, the two almost always combine.

**Bonus (case 1).** A **rollback** is required: the verification fails → return to the extraction step or “human processing” queuing. The pure pipeline is strictly linear; as soon as we add feedback loops, we “twist” it – either we accept a pipeline with explicit looping, or we switch to an orchestrator who decides on the repeats. Lesson: the pattern is a starting point, not a dogma.

---

## Answer key — Exercise 2

**1. Without MCP.** Reasonable allocation of needs:

| Application | CRM | Compliance | GitHub | Messaging |
|---|---|---|---|---|
| AssistDesk | ✅ | ✅ | — | ✅ (internal alerts) |
| RiskWatch | ✅ | ✅ | — | ✅ |
| DevCopilot | — | — | ✅ | ✅ (team notifications) |

Or **8 tailor-made integrations** with this attribution (any justified attribution is accepted, generally 7 to 9). **Theoretical maximum: 3 × 4 = 12.** Each integration = code, authentication, maintenance, bugs — and each new application starts from scratch. This is the N×M problem.

**2. With MCP: 4 servers**, one per system — this is the N+M gain (3 hosts + 4 servers = 7 connectors instead of 8–12 integrations, and the gap widens with each addition).
- **GitHub**: exists on the shelf ⚠ (official/community MCP server).
- **Messaging**: most likely exists on the shelf ⚠ if it is Slack or a common equivalent.
- **Internal CRM**: to be developed internally — this is your business logic.
- **Compliance framework**: to be developed internally (or off-the-shelf filesystem/base server if the documents are in a standard format — response accepted if justified).

**3. Transportation.**
- **CRM** and **Compliance**: **HTTP+SSE** — servers shared by several applications on several machines (AssistDesk on the telephone advisors' workstations, RiskWatch on a server).A remote central server avoids installing and updating N local copies, and centralizes access control.
- **GitHub**: both defend themselves — local stdio launched by each developer's IDE (simple, authentication remains on the workstation) or centralized HTTP. The important thing is the argument.
- **Messaging**: HTTP+SSE if shared, stdio acceptable for an isolated station.
Expected mnemonic rule: **stdio = local to the machine, HTTP+SSE = shared/remote.**

**4. Primitives.**
- a. `chercher_client(...)` → **Tool**: action invoked by the model when it needs it.
- b. Text of the internal procedure → **Resource**: read data, injected under application control.
- c. “Analyze this complaint…” template selected from a menu → **Prompt**: prompt template chosen by the user.
-d. `poster_alerte(...)` → **Tool**: action (and sensitive action!).
- e. List of issues injected automatically upon opening → **Resource**: it is the application that decides to inject it, not the model. *(Batch trap: “issue list” sounds like GitHub-tool, but the trigger is application → Resource.)*

**5. Guardrail `poster_alerte`.** Expected: **human validation before publication** (human-in-the-loop) — the action is irreversible and has a wide audience. Where to place it? Both answers are defensible, the best copy combines them:
- **In the host**: it is he who knows the user and the context, and who can display “Confirm sending?” ". This is the natural place for the validation experience.
- **In MCP server** (defense in depth): hardcoded limits — allowed channels, message quota, logging. The server should not blindly trust its hosts.
Principle to remember: **security is layered; the MCP standard does not exempt from any safeguards of Sessions 5–6.**

---

## Answer key — Exercise 3

*(Model correction — any well-argued variation is valid.)*

**1. Proposed team (4 agents).**

| Officer | Mission (essence of prompt system) | Tools |
|---|---|---|
| 📄 **Extractor** | “Read the contract, extract the key clauses (duration, termination, liability, penalties) in structured format. Do not interpret, extract. » | reading documents (GED) |
| ⚖️ **Comparer** | “Compare each extracted clause to the internal contractual policy. Class: compliant ✅ / to be negotiated ⚠ / blocking ⛔. Quote the house rule every time. » | reading the internal policy framework |
| ✍️ **Editor** | “Write the summary note based on the comparison: clear, structured, intended for a lawyer. » | no external tools |
| 📣 **Notifier-Archiver** | “Archives the note in the GED; if at least one clause ⛔, alert the referring lawyer. » | GED writing, messaging |

Least privilege respected: the Extractor cannot post a message; the Editor has no tools; only the last agent touches messaging and writing.

**2. Boss: pipeline** Extractor → Comparator → Editor → Notifier-Archiver, **with optional supervisor** (legal context = welcome control). Justification: the steps are fixed and ordered, known in advance — exactly the textbook case of the pipeline. Alternative rejected: the orchestrator — useless, there is no dynamic decomposition to decide; it would add a central point of failure without benefit. *(A debate/consensus on the Comparator is a defensible refinement for high-stakes contracts.)***3. Communication: passing messages.** The flow is linear, each agent passes one structured deliverable to the next — traceable, journalable (valuable in a legal context: who produced what). Shared memory or blackboard: oversized for such a sequential flow.

**4. MCP servers.**
- **GED**: in-house server (or filesystem server on the shelf ⚠ if the GED exposes a file system) — connected to the Extractor (reading) and the Notifier-Archiver (writing). Best practice: two distinct access levels (read only for the Extractor).
- **Internal policy**: in-house server or documentary database on the shelf ⚠ — connected to the Comparator; its documents are an ideal candidate for **Resource** (controlled reading) format rather than Tool.
- **Messaging**: server on the shelf ⚠ — connected only to the Notifier-Archiver.

**5. Safeguards.** Sensitive actions: **writing in GED** (pollution of the archiving) and **alert to the lawyer** (disruption, credibility of the system). The expected debate on the alert:
- *For human validation*: a repeated false alarm ⛔ destroys trust (“boy who cried wolf” effect); the ranking ⛔ comes from a model that can be wrong.
- *Against*: the alert is not destructive, it is correctable (“false alarm, ignore”) — and requiring human validation to *alert a human* is almost circular: you might as well let it pass and let the lawyer judge.
- Solid middle position: **automatic alert, but with the cited clause and reasoning attached** (the lawyer can check in 30 seconds), plus tracking of the false alarm rate. Any argued position is accepted; the quality of the debate takes precedence.

**6. Response to colleague.**
- Argument 1 — *prompt contradictions*: “extract without interpreting” (Extractor) and “class and judge” (Comparator) pull in opposite directions; in a single prompt, these instructions interfere with each other.
- Argument 2 — *least privilege and debugging*: a single agent combines all the tools (including messaging — risk) and when the grade is bad, it is impossible to isolate the faulty step; in pipeline, each intermediate deliverable is inspectable.
- *(Also accepted: control of the context, targeted safeguards, reusability of agents.)*
- **Case where he would be right:** low volume and moderate stakes — p. ex. two simple contracts per month, reread in full by a lawyer in any case. A single agent (or even a simple prompt in one round) is then sufficient: the rule “the simplest architecture is sufficient” (Session 6) also applies to multi-agent.