Qu’est-ce qu’un agent IA : cinq types classiques, deux définitions rivales

L’exemple le plus ancien du domaine est un aspirateur dans un monde de deux cases, A et B, chacune propre ou sale.¹ Il survit dans tous les manuels parce que c’est le plus petit monde dans lequel un agent peut avoir raison ou tort.

Le percept est une paire — où je suis, et si c’est sale ici — et les actions sont SUCK, LEFT et RIGHT. Le programme entier tient en une ligne.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Exécutez-le contre chaque configuration de départ du monde à deux cases :

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

C’est un agent réflexe simple : il agit uniquement sur le percept courant, sans mémoire de ce qui l’a précédé. Ce n’est pas une catégorie jouet — un thermostat en est un, et un appel unique à un modèle de langage sans conversation attachée aussi.

Maintenant, cassez-le comme la réalité le fait. Un vrai robot aspirateur a un capteur de saleté et un pare-chocs, pas une case étiquetée A sous le tapis. Retirez la position du percept et ne changez rien d’autre :

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

Le même programme, deux cases. Depuis un état de départ, il termine en trois étapes ; depuis un autre, il fonce cinq cents fois dans le mur de droite et continuerait jusqu’à épuiser la batterie. Il ne peut pas percevoir la différence entre les deux situations, donc il ne peut pas y agir différemment. Russell et Norvig donnent le résultat général en une ligne : les boucles infinies sont souvent inévitables pour les agents réflexes simples dans des environnements partiellement observables.¹

Il existe une correction qui coûte une ligne et aucune mémoire, et qu’il vaut la peine de mesurer avant de chercher quelque chose de plus malin.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Deux mille exécutions d’un couloir entièrement sale, à trois tailles, avec un seul générateur seedé d’un bout à l’autre :

La randomisation élimine entièrement la boucle. Elle coûte aussi : huit pièces nécessitent quinze déplacements si vous savez ce que vous faites, et cet agent en moyenne 68,7, avec un pic à 306. C’est tout le chapitre en miniature. Chaque capacité que nous ajoutons achète de la correction dans un cas que l’agent précédent ne pouvait pas gérer, et la facture dans une devise qu’il faut d’abord nommer.

Un agent perçoit son environnement via des capteurs et agit via des actionneurs. Le programme de l’agent est la fonction qui associe des percepts à des actions — chaque listing ci-dessus en est un. La séquence de percepts est tout ce qui a été perçu jusqu’ici, et un agent réflexe simple ignore tout sauf le dernier élément.

La rationalité est le mot que la plupart des articles emploient mal, et le remettre à sa place rend le reste de ce chapitre utilisable. Un agent n’est pas rationnel ou irrationnel en soi. Russell et Norvig définissent un agent rationnel comme un agent qui, pour chaque séquence de percepts possible, choisit l’action censée maximiser sa mesure de performance, compte tenu des éléments fournis par cette séquence et de toute connaissance intégrée dont il dispose.¹ La mesure de performance n’est pas dans l’agent : elle appartient au concepteur, et la rationalité n’est définie que par rapport à elle.

La spécification s’écrit traditionnellement en quatre éléments, PEAS : performance measure, environment, actuators, sensors.

Remarquez quelle ligne détonne. Presque toutes les équipes qui construisent des agents en 2026 écrivent E, A et S — les schémas d’outils, les intégrations, le format des messages — parce que le code ne s’exécutera pas sans eux. Presque personne n’écrit P. Sans lui, « notre agent se débrouille bien » n’a aucune signification vérifiable, et « rationnel » ne peut pas s’appliquer au système, seulement à une démonstration. Le Chapitre 29 explique comment transformer P en nombre, et voilà pourquoi il existe.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Les environnements de tâche se classent en outre selon sept axes, dont cinq déterminent l’essentiel de la difficulté ici : entièrement ou partiellement observable, déterministe ou non, épisodique ou séquentiel, statique ou dynamique, connu ou inconnu.¹ Un agent qui parle à de vrais outils sur un vrai réseau se trouve dans le coin difficile des cinq — non déterministe même à température zéro (Chapitre 17) et, point sous-estimé, inconnu, parce que vous n’avez pas de modèle fiable de ce que vos propres outils font au monde. C’est pourquoi la boucle du Chapitre 23 a davantage besoin de gestion d’erreurs que de planification.

Les vrais sols ne sont pas unidimensionnels, alors promouvons le monde en plan. Les dièses sont des murs, les astérisques sont de la saleté, et le robot démarre dans la pièce centrale :

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

L’amélioration évidente est la mémoire. L’agent garde une carte : chaque case sur laquelle il s’est tenu et chaque case où le pare-chocs s’est déclenché. Sa règle est d’entrer dans une case adjacente qu’il n’a pas visitée — à droite, puis en bas, puis à gauche, puis en haut — et de reculer quand tout ce qui l’entoure est connu. C’est un agent réflexe basé sur un modèle : il maintient un état interne à partir de l’historique des percepts, de sorte qu’il peut agir sur ce qu’il ne voit pas actuellement.

C’est une vraie amélioration, et ce n’est toujours pas suffisant :

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Cinq mille déplacements, la moitié du sol jamais vue. La carte est correcte et les règles sont correctes. Ce que l’agent ne peut pas faire, c’est utiliser la carte pour aller quelque part : ses règles répondent seulement à « lequel de mes quatre voisins dois-je rejoindre », donc une fois qu’il n’a plus de cases non visitées à côté de lui, il n’a aucun moyen d’exprimer la pensée il y a une case non visitée à huit déplacements d’ici et j’aimerais m’y tenir. Il sait où il est. Il ne sait pas où il veut être.

Un agent basé sur un objectif possède, en plus de son modèle du monde, une description de la situation qu’il veut provoquer, et choisit ses actions en cherchant parmi des séquences jusqu’à en trouver une qui y mène. Les objectifs transforment la sélection d’action d’une consultation en recherche.

L’objectif est « aucune case sale ne reste ». La recherche est un parcours en largeur vers la case sale la plus proche, et le chemin qu’elle renvoie est le plan.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Vingt-sept déplacements, sol propre. Mais regardez la colonne batterie et la dernière étape du plan. La colonne 0 est recouverte de moquette : traverser une case avec moquette coûte six unités de batterie, une case carrelée en coûte une. L’agent est rentré par la colonne 0 parce que cela fait quatre déplacements au lieu de huit, et ces quatre déplacements sur moquette ont coûté 24, là où le détour de huit déplacements aurait coûté 13.

Il ne peut pas faire autrement. Un objectif est un test binaire : le sol est propre ou il ne l’est pas. Tout plan qui se termine avec un sol propre le satisfait également, donc quand plusieurs réussissent, l’agent n’a aucun critère pour choisir entre eux. Préférer une réussite à une autre nécessite un nombre sur les résultats, et ce nombre est une fonction d’utilité. Un agent qui la maximise est un agent basé sur l’utilité.

Le changement dans le code tient à un terme dans la recherche. La recherche en largeur compte les déplacements ; faites-lui compter le coût à la place et vous obtenez l’algorithme de Dijkstra et un agent différent :

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Quatre déplacements de plus, onze unités de batterie en moins : vingt et un pour cent moins cher. Même objectif, même carte, même code à un terme près. Les deux agents ne diffèrent que par ce qu’ils essaient d’optimiser, et ils prennent des routes différentes pour rentrer.

C’est aussi le premier moment où l’agent a besoin de quelque chose qu’il ne peut pas produire. Quelqu’un doit décider ce que vaut une unité de batterie par rapport à un déplacement. L’utilité est la mesure de performance écrite sous une forme avec laquelle l’agent peut calculer, et l’écrire est le travail du concepteur. Quand on dit qu’un agent a « optimisé la mauvaise chose », on parle presque jamais d’un bug. On veut dire que cette ligne a été écrite négligemment.

Maintenant, laissez la saleté revenir. Quatre pièces se salissent à nouveau à quatre rythmes différents, et l’agent ne les connaît jamais. Il visite une pièce par tick et ne voit que cette pièce. La mesure de performance est le nombre de room-ticks passés sales sur 4 000 ticks — plus c’est bas, mieux c’est.

Un agent apprenant, dans la décomposition du manuel, est n’importe lequel des agents ci-dessus plus trois éléments : un élément d’apprentissage qui modifie l’agent, un critique qui lui dit comment l’agent se comporte face à un standard de performance fixe, et un générateur de problèmes qui propose des actions à essayer pour ce qu’elles enseigneraient.¹ Trois politiques dans le même environnement. La première n’apprend pas ; la deuxième et la troisième apprennent la même chose et l’utilisent différemment.

Les taux cachés étaient 0,35 pour la cuisine, 0,05 pour le couloir, 0,02 pour le bureau et 0,01 pour le grenier — et l’apprenant A les a trouvés. Il a correctement identifié la cuisine comme la pièce la plus sale de la maison, puis il est allé à la cuisine à chaque tick pour le reste de la simulation tandis que les trois autres restaient sales à jamais. Il est cinq fois pire que l’absence totale d’apprentissage, et il n’est pas cassé.

La leçon est celle de la section sur l’utilité. L’apprenant A maximisait « probabilité que la pièce que je vais visiter soit sale ». La mesure de performance était « room-ticks passés sales ». Des nombres différents ; le second est ce que le critique notait, et personne ne l’a dit à l’agent. L’apprenant B multiplie le même taux appris par le temps écoulé depuis la dernière visite — la saleté qu’il s’attend à trouver plutôt que la chance d’en trouver — et bat la patrouille dont il était parti.

Un détail d’implémentation a décidé du résultat. Dans la première version de l’apprenant B, une pièce où aucune saleté n’était apparue en trois visites obtenait un taux exactement égal à zéro — et zéro fois quoi que ce soit fait zéro, donc elle n’était plus jamais visitée et l’estimation ne pouvait plus être corrigée. Lisser la fraction, succès plus un sur essais plus deux, a transformé 11 895 en 1 576. « Pas encore observé » et « mesuré et obtenu zéro » sont deux affirmations différentes, et un système qui les stocke dans le même champ prend des décisions qu’il ne peut pas annuler.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Chacun des cinq est en production aujourd’hui sous un autre nom.

Deux lignes sont plus proches qu’une analogie, d’une façon qui coûte de l’argent.

Le chat est un agent réflexe basé sur un modèle dont le modèle n’est pas interne. Dans le manuel, l’état est une variable dans le programme de l’agent. Dans un chat, c’est la transcription : elle vit de votre côté, est renvoyée en entier à chaque appel, et est reconstruite de zéro dans le modèle à chaque fois. C’est la facture quadratique du Chapitre 16, et c’est le même objet que le manuel dessinait comme une boîte étiquetée « état ». Voici la différence, mesurée sur une question de suivi avec et sans les deux messages qui la précédaient :

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

Le même modèle, les trois mêmes mots d’entrée utilisateur, et le second est le robot de couloir qui fonce dans le mur. Il n’y avait aucun outil dans cette exécution, donc le 15 est inventé — mais l’état est ce qui rend la relance intelligible. Vous le reconstruisez à chaque fois et payez 2,3× les tokens d’entrée pour cela sur une conversation de deux tours. Le Chapitre 16 mesurait jusqu’où ce multiplicateur monte au tour quarante.

Reflexion est un agent apprenant qui modifie son entrée plutôt que son programme. Dans la décomposition du manuel, l’élément d’apprentissage modifie l’élément de performance. Reflexion laisse les poids intacts et écrit du texte réflexif dans un buffer épisodique que la tentative suivante lit.³ L’élément d’apprentissage est un prompt, la mémoire une ligne de base de données, l’élément de performance un modèle figé — et le schéma est celui du manuel, inchangé.

Et voici la limite honnête de la correspondance. Les cinq types classent le programme de l’agent. En 2026, ce programme est fendu en deux : une partie est votre code, une partie se trouve dans des poids que vous n’avez pas entraînés. Quand un modèle décide de lui-même d’appeler un outil, le test d’objectif se trouve-t-il dans votre programme ou dans le modèle ? La taxonomie n’a pas de réponse, parce que lorsqu’elle a été écrite, il ne pouvait être nulle part ailleurs — et cette question est exactement l’endroit où les deux définitions modernes se séparent.

Les définitions sont des arguments sur le comportement, et il est beaucoup plus facile de les juger avec une trace sous les yeux.

La boucle ci-dessous envoie la conversation à un modèle ; si la réponse contient un appel d’outil, elle exécute l’outil, ajoute le résultat et renvoie le tout. Elle tourne contre un Qwen2.5-0.5B-Instruct local derrière un endpoint au format OpenAI sur cette machine — la couture du Chapitre 14, donc la boucle ne sait pas et ne se soucie pas de ce qui se trouve derrière le port.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Deux lignes portent toute l’idée, et toutes deux sont marquées ; le reste est de la tenue de comptes. Les trois comportements sont visibles dans une seule exécution. Quand on lui demande quelque chose qu’il peut faire lui-même, le modèle répond. Quand on lui demande quelque chose qu’il ne peut pas faire, il appelle :

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

Et il s’arrête — le troisième comportement, et le plus facile à manquer, parce qu’il ressemble à rien. La boucle se termine parce que le tour 2 est revenu sans appel d’outil. Personne n’a décidé cela ; le modèle l’a fait, en émettant de la prose. La condition de terminaison de ce programme est le signe d’une absence.

Deux autres exécutions méritent l’espace. Lorsqu’on lui demande de comparer deux villes, le modèle émet les deux appels d’outils en un seul tour, récupère les deux relevés, et se trompe dans la comparaison :

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Les outils ont fonctionné. L’appel parallèle a fonctionné. La boucle a fonctionné. La réponse est fausse, avec les deux bons nombres dans la transcription. Envelopper un modèle dans une boucle ne le fait pas raisonner ; cela donne à un modèle qui se trompe la capacité d’agir sur son erreur — ce qui annonce le Chapitre 30, et la moitié du Chapitre 29.

Maintenant, supprimez le return marqué et laissez la boucle aller jusqu’à son plafond. Même question, même modèle :

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Quatre fois les tokens d’entrée, quatre fois le temps d’horloge, et une fin dans laquelle l’agent a oublié ce qu’on lui avait demandé et interroge l’utilisateur sur une question à laquelle celui-ci a répondu au premier tour. La bonne réponse était à l’écran au tour 2, et chaque tour suivant a détérioré la transcription.

Donc un agent n’est pas une boucle. C’est une boucle plus une règle pour en sortir, et celle-ci a exactement une telle règle. Le Chapitre 23 en trouve cinq, et montre ce qui casse quand chacune manque.

Les deux sont citées plutôt que paraphrasées, parce que les paraphrases sont l’endroit où la confusion est fabriquée.

La première définition place la frontière sur celui qui contrôle le flux. Building effective agents d’Anthropic nomme l’ambiguïté et tranche :

« Chez Anthropic, nous classons toutes ces variations comme des systèmes agentiques, mais nous traçons une distinction architecturale importante entre workflows et agents : les workflows sont des systèmes où les LLMs et les outils sont orchestrés par des chemins de code prédéfinis. Les agents, en revanche, sont des systèmes où les LLMs dirigent dynamiquement leurs propres processus et leur usage des outils, en gardant le contrôle sur la façon dont ils accomplissent les tâches. »⁴

Le test est une question sur votre code source : qui a choisi l’étape suivante ? Un switch dans votre programme : workflow. Le modèle : agent. Le même document dit que les agents « sont généralement simplement des LLMs utilisant des outils à partir du feedback de l’environnement dans une boucle » — ce qui est exactement le listing ci-dessus.

La seconde définition place la frontière sur l’indépendance vis-à-vis de l’utilisateur. A practical guide to building agents d’OpenAI ouvre sa page de définition ainsi :

« Alors que les logiciels conventionnels permettent aux utilisateurs de rationaliser et d’automatiser des workflows, les agents peuvent exécuter ces mêmes workflows au nom des utilisateurs avec un haut degré d’indépendance. Les agents sont des systèmes qui accomplissent indépendamment des tâches en votre nom. »⁵

Deux phrases plus loin, sur la même page, il exclut :

« Les applications qui intègrent des LLMs mais ne les utilisent pas pour contrôler l’exécution du workflow — pensez aux chatbots simples, aux LLMs en un seul tour ou aux classifieurs de sentiment — ne sont pas des agents. »⁵

Lisez ces citations dans l’ordre. Les phrases d’ouverture tracent la ligne à l’indépendance : est-ce que cette chose part faire le travail sans moi et le termine ? La quatrième la trace au contrôle de l’exécution, exactement la ligne d’Anthropic. Des tests différents, sur la même page, et il existe de vrais systèmes sur lesquels ils divergent.

Il y a dessous une collision de vocabulaire, et elle provoque des disputes dans de vraies réunions. Dans le premier document, un workflow est une architecture, et c’est précisément ce qui n’est pas un agent. Dans le second, un workflow est « une séquence d’étapes qui doit être exécutée pour atteindre l’objectif de l’utilisateur » — le travail lui-même, dont chaque agent possède un exemplaire. « Nous avons remplacé le workflow par un agent » est cohérent avec la première définition et presque vide de sens avec la seconde.

Trois systèmes qui existent en 2026, selon les deux définitions.

Deux des trois changent de camp. Ce n’est pas un échec de l’un ou l’autre document. C’est un avertissement sur un type de réunion où deux personnes entièrement d’accord sur ce qu’un système fait passent une heure à se disputer sur son nom.

Les définitions se heurtent parce que chacune écrase deux questions indépendantes dans un seul mot. Séparez-les et le désaccord devient un tableau, plus utile qu’un verdict.

Chaque définition conteste une cellule différente, et les deux autres ne sont pas du tout contestées. Donc quand l’étiquette compte — dans un contrat, une revue de risque, un postmortem — les deux phrases qui valent la peine d’être écrites ne sont pas « est-ce un agent », mais qui a choisi l’étape suivante et qui regardait. Les deux trouvent leur réponse en lisant le code, aucune n’a besoin de la définition de quiconque, et ensemble elles portent toutes les conséquences que l’étiquette remplaçait.

Rien de tout cela n’est nouveau. Wooldridge et Jennings ont recensé les sens concurrents de « agent » en 1995 ;⁶ Franklin et Graesser ont posé la question de ce chapitre en 1996, rassemblé les définitions alors en circulation et constaté qu’elles divergeaient.⁷ Une enquête de 2023 définit encore les agents depuis les premiers principes — « des entités artificielles qui perçoivent leur environnement, prennent des décisions et agissent »⁸ — parce qu’il n’existait rien de stabilisé à citer, et CoALA décrit des composants plutôt que de tracer une frontière.⁹ Trente ans de refus de s’accorder indiquent que le mot fait plus d’un travail.

Passons maintenant à la conséquence qui arrive avant la philosophie : la facture.

Chaque mesure ici a la même forme. L’appel unique a coûté 39 tokens d’entrée ; la même question avec un outil a coûté 420 sur deux appels ; la boucle sans règle d’arrêt a coûté 1 688 sur six. La croissance est pire que linéaire, parce que le tour n transporte tous les tours précédents avec lui : la colonne prompt de cette exécution en six tours affiche 187, 238, 261, 302, 327, 373. Le Chapitre 16 a dérivé que le total est $\Theta(n^2)$ et ajusté la courbe sur une vraie conversation. Un agent transforme chaque tâche en cette conversation, qu’un humain la voie ou non.

Si ces nombres de tokens mesurés avaient été envoyés à un endpoint commercial aux tarifs que le Chapitre 16 a relevés le 6 septembre 2026 — 2,00 $ par million de tokens d’entrée et 12,00 $ par million de sortie — les quatre exécutions donneraient ceci :

La ligne deux face à la ligne un est le nombre à retenir. Sept fois et demie le coût, pour une réponse pire à une question que le modèle connaissait déjà. Rien n’était mal configuré : un outil existait, donc le modèle l’a utilisé — et la conclusion du Chapitre 18, selon laquelle c’est le prix d’un catalogue et non son exactitude qui fait mal, trouve ici sa démonstration la moins chère avec un catalogue de un.

C’est pourquoi la moitié utile des deux documents est celle qui explique de ne pas construire cela. Anthropic est direct : trouvez la solution la plus simple possible et n’ajoutez de la complexité que lorsque c’est nécessaire, ce qui « pourrait signifier ne pas construire du tout de systèmes agentiques », puisque les systèmes agentiques « échangent latence et coût contre une meilleure performance de tâche » et que « pour beaucoup d’applications, optimiser des appels LLM uniques avec retrieval et exemples in-context suffit généralement ».⁴ Son cas pour un agent est étroit : des problèmes ouverts où vous ne pouvez pas prédire le nombre d’étapes et ne pouvez pas hardcoder un chemin, dans un environnement auquel vous faites confiance, en acceptant « des coûts plus élevés et le risque d’erreurs composées ».⁴ L’écran d’OpenAI est l’image miroir — jugement complexe, ensembles de règles impossibles à maintenir, données non structurées — et se termine de la même façon : « sinon, une solution déterministe peut suffire ».⁵

Donc, dans la taxonomie de ce chapitre : un nombre fixe d’étapes dans un ordre fixe est un pipeline, et l’appeler agent ne le rendra pas plus rapide. Si le nombre d’étapes dépend de ce que vous trouvez en chemin, vous voulez une boucle — et vous achetez cette flexibilité avec N appels, une transcription quadratique, et un système qui peut se tromper N fois au lieu d’une.

Vous avez maintenant la taxonomie, les deux définitions modernes, les deux axes qui les rendent compatibles, et une courte boucle qui répond, appelle et s’arrête.

Cette boucle a une seule façon de finir : le modèle cesse de demander des outils. Le Chapitre 23 la casse exprès, sept fois, et chaque casse ajoute une pièce. Une tâche impossible, et elle ne se termine jamais — un plafond de tours. Une nuit d’exécution, et la facture arrive — un budget en dollars. Un outil qui échoue — une erreur sur laquelle le modèle peut agir. Le même appel deux fois — une clé d’idempotence. Un fichier qu’il n’aurait pas dû toucher — une approbation humaine. Un redémarrage à mi-chemin — persistance de session. Un outil qui prend trois minutes dans le silence — progression et annulation. Ce qui en sort est un harness, le fichier sur lequel tourne le reste de ce cours.

Ce qui laisse la question que la diagonale contestée de ce chapitre posait vraiment. Une boucle qui décide elle-même de son étape suivante doit décider quand s’arrêter, et nous venons de voir ce qui se passe quand elle n’y arrive pas : six tours, quatre fois la facture, et un agent qui interroge l’utilisateur sur une question à laquelle il avait déjà répondu. L’arrêt n’est pas une seule condition. Combien y en a-t-il, et laquelle se déclenche en premier ?

LLM Powered Autonomous Agents (2023) de Lilian Weng est la décomposition la plus connue d’un language agent en planification, mémoire et usage d’outils, et constitue la bonne lecture suivante avec les deux documents fournisseurs ; ses trois composants sont les Chapitres 23, 24 et 18 de ce cours, dans cet ordre.

Chaque nombre de ce chapitre a été produit sur cette machine et rien n’a été estimé. Le couloir, le plan d’étage, les quatre agents qui le parcourent et les trois politiques de patrouille sont le TypeScript ci-dessus, exécuté sur Node 22 ; les chiffres de l’agent randomisé sont des moyennes sur 2 000 exécutions seedées chacune et les chiffres de patrouille sont des exécutions seedées uniques de 4 000 ticks. Les traces modèle viennent de Qwen2.5-0.5B-Instruct en float32 sur CPU avec décodage greedy, servi en loopback par un petit endpoint Python local qui charge les poids et parle le format OpenAI chat-completions — encore la couture, avec les tenseurs côté Python et la boucle côté TypeScript — donc les nombres de tokens sont ceux du tokenizer de ce modèle et les latences celles de cette machine. Les seuls chiffres venus d’ailleurs sont les deux prix du tableau de coûts, qui sont les tarifs que le Chapitre 16 a lus sur la page de prix d’OpenAI le 6 septembre 2026, appliqués ici aux nombres de tokens mesurés localement comme illustration et non comme facture observée.