# 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 → reflect → act → observe.*

**Background.** The **SupportBot** agent is assisting a 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)` — issues a refund. **Irreversible action.**
- ✉️ `envoyer_email(destinataire, texte)` — sends an email.

**Mission received:** “Customer paul@example.fr complains that his order C-4812 never arrived. Check, refund if justified, and warn him. »

**Questions:**

1. 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.
2. At what iteration do you place a **human-in-the-loop** checkpoint? Why this one and not another?
3. 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)

*Goal: Identify missing guardrails and correct error recovery behavior.*

**Context.** Here is the actual 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:**

1. Describe the malfunction precisely. Which step of the loop is the agent missing, in the sense that it is not exploiting it correctly?
2. Name **three safeguards missing** from this system, and for each, the value or concrete rule that you would choose for this monitoring agent.
3. “Error 429 (too many requests)” means that the service temporarily refuses too frequent requests. What would an agent with good **error recovery** have done from iteration 2? Suggest two different strategies.
4. 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 suffices, from:
**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 mandatory safeguard**.

1. “Rephrase this paragraph in simpler language. »
2. “What is the current Airbus share price?” » ⚠ (volatile data)
3. “Every Monday at 9 a.m.: retrieve the sales for the week 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. »
4. “Find me a one-hour meeting slot this week that suits Marie, Karim and I's schedules, offer it to them by email, and if anyone refuses, find an alternative until agreed. »
5. “Translate this contract into English. »
6. “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.

---
---

# Fixed

## Answer key — Exercise 1

**1. Expected sequence** (“Observer” results are plausible, other variants are acceptable):

| It. | Perceive | Think | Act | Observe |
|---|---|---|---|---|
| 1 | Mission: complaint from 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 reached, **the agent stops** |Scoring points: the order verify **before** reimbursing (an agent reimbursing at 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 this is the only **irreversible and financial** action of the mission. Neither before the readings (`chercher_client`, `statut_commande`: without risk, the 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 reasoned, but reimbursement remains a priority).

**3. End of execution:** at iteration 5, the agent rereads the mission (“checks, reimburses, warns”) and notes that the three parts are accomplished. **It's the model that makes the shutdown decision** — technically, it responds without requesting 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 retries **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 **exploit** it in the “reflect” step: observation never modifies his strategy. The loop has become a *dead* loop: 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 limit** | ⚠ p. ex. €0.30 API calls or 5 minutes per execution (orders of magnitude; prices change) — weekly monitoring does not justify 40 minutes |
| **Repetition detection** | Rule: “same tool + same arguments + same error 2 times in a row → prohibited from trying the same thing again” (accepted variant: alert to a human after N consecutive failures) |

*(The logging 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 report 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 it changes everything: the model can only adapt its strategy based on what it **reads** in the context.`"429"` does not indicate the cause or the action to take; the rich message literally contains the recovery strategy. The robustness of an agent is conceived **on the tools side** as much as on the model side.

---

## Answer key — Exercise 3

| # | Answer | Rationale |
|---|---|---|
| 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 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 demonstrates 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 < single 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.