Exercises — Session 6: The agentic loop
Program : Applied AI — Intermediate Level · Instructor: Yann Isola General instructions: work in pairs. No code to write - we reason on paper, like an agent architect. The corrections are at the end of the document: only read them after you have really tried.
Exercise 1 — Unwind the loop by hand (≈ 15 min)
Objective: know how to decompose an agent execution into iterations perceive → think → act → observe.
Context. The agent SupportBot help customer service. Its tools:
- 🗄️
chercher_client(email)— returns the customer file (name, subscription, history). - 📦
statut_commande(numero)— returns the status of an order. - 💶
rembourser(numero, montant)— makes a refund. Irreversible action. - ✉️
envoyer_email(destinataire, texte)— send an email.
Mission received: “The customer paul@example.fr complains that his order C-4812 never arrived. Check, reimburse if justified, and warn him. »
Questions :
- Display the expected execution in table form, one row per iteration, with 4 columns: Perceive / Think / Act (exact tool call) / Observe (plausible result). Aim for 4-5 iterations.
- In which iteration do you place a human checkpoint (human-in-the-loop, validation by a human)? Why this one and not another?
- How does the agent know, at the last iteration, that it can stop? Who makes this decision?
Exercise 2 — Diagnosis of a derailing agent (≈ 15 min)
Objective: Identify missing guardrails and correct error recovery behavior.
Context. Here is the real log (simplified) of a monitoring agent responsible for: “Find the 3 most relevant articles of the week on stablecoins and send a summary to the team. »
It. 1 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429 (too many requests)
It. 2 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429
It. 3 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429
It. 4 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429
...
It. 27 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429
It. 28 AGIR: recherche_web("stablecoins actualité") → OBSERVER: erreur 429
[interruption manuelle par l'administrateur au bout de 40 minutes]
Questions :
- Describe the malfunction precisely. Which step of the loop is the agent missing, in the sense that it is not using it correctly?
- Quote three missing safeguards of this system, and for each, the value or concrete rule that you would choose for this monitoring agent.
- “Error 429 (too many requests)” means that the service temporarily refuses too frequent requests. What would an agent with good error recovery from iteration 2? Suggest two different strategies.
- Bonus question: the error message returned to the model was exactly
"429". Suggest better wording for this error message, and explain why it changes the behavior of the agent.
Exercise 3 — Agent or not agent? (≈ 15 mins)
Objective: apply the decision tree and avoid over-engineering.
For each of the following six requests, choose the simplest architecture that is sufficient, among: A. Simple prompt (one call to the model, zero tools) · B. Single tool call (Session 5) · C. Fixed workflow (sequence of steps coded in advance) · D.Agent (autonomous loop).
Justify in one sentence, and for each answer D, indicate at least one safeguard OBLIGATORY.
- “Rephrase this paragraph in simpler language. »
- “What is the current Airbus share price? » ⚠ (volatile data)
- “Every Monday at 9 a.m.: retrieve the week's sales from the database, calculate the total, generate the PDF report (Portable Document Format), send it to management. Always these 4 steps, always in this order. »
- “Find me a one-hour meeting slot this week that suits the schedules of Marie, Karim and me, offer it to them by email, and if anyone refuses, find an alternative until agreement. »
- “Translate this contract into English. »
- “My site has been slow since this morning. Diagnose the cause and correct it if it is safe to do so; If not, tell me what to do. »
Summary question: state the general rule that guided you, in one sentence.
Corrected
Answer key — Exercise 1
1. Expected course (“Observer” results are plausible, other variants are acceptable):
| It. | Perceive | To reflect on | Act | Observe |
|---|---|---|---|---|
| 1 | Mission: complaint of paul@example.fr, order C-4812 not delivered | I first need to verify that the customer and order exist | chercher_client("paul@exemple.fr") |
File: Paul Durand, subscriber since 2023, 1 previous complaint |
| 2 | Confirmed customer | Check the actual status of the order before any refund | statut_commande("C-4812") |
“Lost by the carrier, last trace 12 days ago” — amount €89 |
| 3 | Lost order: refund is justified | Irreversible action → request human validation | (human checkpoint: “Refund €89 to Paul Durand?”) | Validation granted |
| 4 | Refund allowed | Execute refund | rembourser("C-4812", 89) |
{"statut": "ok", "ref": "R-2291"} |
| 5 | Reimbursement made, it remains to notify the customer | Write and send the email, then the mission will be complete | envoyer_email("paul@exemple.fr", "…remboursement de 89 € effectué, réf. R-2291…") |
{"statut": "envoyé"} → objective achieved, the agent stops |
Scoring points: order check Before to reimburse (an agent who reimburses in iteration 1 based solely on the complaint is a design error); each “Observe” feeds the following “Perceive”.
2. Human checkpoint: Before rembourser (iteration 3/4), because it is the only action irreversible and financial of the mission. Nor before the readings (chercher_client , statut_commande : without risk, validation would slow down for nothing), nor before envoyer_email (reversible in practice: we can send a correction; certain pairs can defend validation of the text of the e-mail — acceptable if justified, but reimbursement remains a priority).
3. End of execution: in iteration 5, the agent rereads the mission (“checks, reimburses, warns”) and notes that the three parts are accomplished. It is the model that makes the stopping decision — technically, it responds without asking for a new tool, which closes the loop. This is the key distinction with a chatbot, which would have stopped after its first response no matter what.
Answer key — Exercise 2
1. Malfunction: the agent tries again 28 times exactly the same action despite 28 identical failures. He executes the “observe” step well in the mechanical sense (he receives the error), but he does not exploits not in the “think” stage: observation never modifies its strategy. The loop has become a loop dead : act → fail → start again the same. This is the classic anti-pattern of identical repetition.
2. Three missing safeguards (indicative values — any reasonable and justified value is accepted):
| Guardrail | Concrete rule for this monitoring agent |
|---|---|
| Max iterations | 10 loop turns maximum; beyond, stop + report “mission not accomplished, here’s why” |
| Budget/time ceiling | ⚠ p. ex. €0.30 API calls or 5 minutes per execution (orders of magnitude; prices change) — weekly monitoring does not justify 40 minutes |
| Repeat detection | Rule: “same tool + same arguments + same error twice in a row → prohibited from trying the same thing again” (accepted variant: alert to a human after N consecutive failures) |
(Journaling already existed - it's thanks to it that we diagnose. A bonus point if the pair notices it.)
3. Two recovery strategies valid from iteration 2:
- Wait then try again (backoff, increasing wait between attempts): error 429 is temporary by nature; wait 30–60 s before trying again, doubling the time for each failure, with a maximum of 3 attempts.
- Change means : use another available tool (another search engine, RSS feed - Really Simple Syndication, news feed format - internal, documentary base), or degrade properly: produce the synthesis from what is accessible by pointing out the limit, or trace it to a human.
4. Bonus — better error message: instead of "429" :
"Erreur : quota de requêtes dépassé (429). Le service refusera les appels pendant environ 60 secondes. Ne réessayez pas immédiatement : attendez, ou utilisez une source alternative."
Why does it change everything: the model can only adapt its strategy based on what it bed in context. "429" indicates neither the cause nor the course of action to take; the rich message literally contains the recovery strategy. The robustness of an agent can be conceived tools side as much as on the model side.
Answer key — Exercise 3
| # | Answer | Justification |
|---|---|---|
| 1 | A — Simple prompt | Pure text transformation: no external data, no actions, just one round. |
| 2 | B — Single tool call | Living data ⚠ (the model alone does not know the current price), but ONE call to a stock market API is enough; no loops needed. |
| 3 | C — Fixed workflow | The steps and their order are known in advance and invariable. An agent would provide flexibility that no one needs — and unpredictability that no one wants. Pitfall of the statement: “several tools” does not mean “agent”. |
| 4 | D — Agent | The number of steps is unknown in advance (it depends on the refusals), the order depends on the intermediate results, you have to adapt. Mandatory safeguards (at least one): max iterations (e.g. 10 round trips), human validation before sending final invitations, time limit. |
| 5 | A — Simple prompt | Translation: one lathe, zero tools. (A pair offering human proofreading for a legal contract is showing common sense — but it’s quality control, not a reason to agentify.) |
| 6 | D — Agent | Exploratory diagnosis: the following steps depend on what the previous ones reveal (logs? database? network?). Mandatory safeguards: human validation before any corrective action on production (“correct if it is without risk” must be strictly regulated — ideally, only reading is autonomous), max iterations, complete logging. |
Expected summary rule: “Always choose the simplest architecture that accomplishes the mission: prompt < unique tool < fixed workflow < agent. We only move to the next level if the number of steps or their order depends on the intermediate results. » Any equivalent formulation is correct.