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 pattern if necessary).
Justify each choice in one or two sentences. Several defensible answers exist: what matters is the justification.
-
Processing 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.
-
Risk analysis before publication of a regulatory notice: the error would be very costly (reputation, regulator). We want to minimize the risk of hallucination or forgetting.
-
“Prepare me a complete file on company X before my meeting on Thursday” : depending on the company, it will be necessary to dig into the press, financial data, social networks, the commercial register... The exact breakdown is not known in advance.
-
“Rephrase this email in a more diplomatic tone. »
-
A system of assisted trading agents (preparation of orders, 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)
Objective: apply the Model Context Protocol (MCP) architecture to a real business case.
Context. You are in a brokerage firm. Three internal applications use AI (artificial intelligence):
- AssistDesk — customer service assistant (desktop application for telephone advisors)
- 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:
- There customer base (CRM — Customer Relationship Management)
- THE compliance framework (internal regulatory documents, read only)
- GitHub (source code, issues)
- There team messaging (post alerts)
Questions :
-
Without MCP: how many custom integrations would need to be coded 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).
-
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?
-
For each MCP server, say which transportation 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?
-
Classify each of the following items correctly 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 the 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 -
Security : the tool
poster_alertepublishes 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 automate. The legal department receives dozens of supplier contracts each week to review. The current human process:
- Read the contract and extract the key clauses (duration, termination, liability, penalties).
- Compare each clause to the company’s internal contractual policy.
- Write a summary note: compliant clauses , clauses to negotiate ⚠, blocking clauses ⛔.
- If at least one clause is blocking: immediately alert the referring lawyer by email.
- Archive the note in the EDM (Electronic Document Management).
Questions :
-
Cutting: 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.
-
Boss : which multi-agent boss do you choose? Draw the flow (arrows between agents). Justify at least one alternative that you reject.
-
Communication : messages, shared memory or blackboard? Justify in one sentence.
-
MCP connection: List the MCP servers needed (shelf or home) and say which agent plugs into which.
-
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.
-
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.
Corrected
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 X → C. Orchestrator/executors. The decomposition depends on the company (listed or not, media presence, etc.): it is not known in advance, it is the orchestrator who decides on execution, then delegates in parallel (press, finance, register, etc.) and assembles. 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 (Session 6 reminder: do not 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 monitoring : check each output, detect deviations, interrupt. To be distinguished from the orchestrator: the latter distribute the work , the supervisor quality control and safety . In finance, the two almost always combine.
Bonus (case 1). It takes a go back : verification fails → return to the “human processing” extraction or enqueue step. 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) |
Either 8 integrations tailor-made 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 widespread 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 — answer 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 machine, HTTP+SSE = shared/remote.
4. Primitives.
- has.
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 automatically injected upon opening → Resource : it is the application that decides to inject it, not the model. (Batch pitfall: “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 the MCP server (defense in depth): hard-coded 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
(Standard answer key — any well-argued variation is valid.)
1. Proposed team (4 agents).
| Agent | Mission (essence of the prompt system) | Tools |
|---|---|---|
| 📄 Extractor | “Read the contract, extract the key clauses (duration, termination, liability, penalties) in structured format. Do not interpret, extract. » | document reading (GED) |
| ⚖️ Comparator | “Compare each extracted clause to the internal contractual policy. Class: compliant / to negotiate ⚠ / 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. Pattern: pipeline Extractor → Comparator → Editor → Notifier-Archiver, with supervisor optional (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, logable (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 EDM 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 the format Resource (controlled reading) rather than Tool.
- Messaging : server on the shelf ⚠ — connected only to the Notifier-Archiver.
5. Guardrails. Sensitive actions: writing in GED (pollution of archiving) and alert to the lawyer (disturbance, credibility of the system). The expected debate on the alert:
- For human validation : a repeated false alarm ⛔ destroys confidence (“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 require 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 monitoring 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 turn) is then sufficient: the rule “the simplest architecture is sufficient” (Session 6) also applies to multi-agent.