AI Agents 101 : le guide pragmatique d'un ex-ingénieur de Meta
Perception, décision, action : un fondateur d'agence d'agents IA détaille la mécanique d'un agent qui tient en production, et surtout ce qu'il ne faut pas lui confier.
In breve
Le fondateur de Varick Agents, ancien ingénieur logiciel chez Meta, publie un guide d'introduction aux agents IA : définition, architecture en trois briques, outils, mémoire, planification, gestion des échecs et garde-fous. Le texte vaut moins par sa nouveauté que par sa discipline d'ingénieur : un agent utile est étroit, observable, encadré par des permissions et supervisé par un humain sur les cas difficiles.
🍺 Versione da bancone
En gros, un script, c'est un stagiaire à qui tu dis « envoie ce mail » ; un agent, c'est un collègue à qui tu dis « fais en sorte que le client ait une réponse avant midi » et qui se débrouille. Le gars qui a écrit ça explique surtout qu'il faut lui faire rédiger un plan avant d'agir, lui interdire de supprimer quoi que ce soit et lui laisser les cas tordus remonter à un humain. Bref, exactement ce qu'on attend d'un nouvel employé, sauf que celui-là ne demande pas de tickets resto. Ça compte parce que tout le monde veut des agents, et que la différence entre un agent qui marche et une catastrophe tient dans ces règles très peu glamour.
Da ricordare
- 1
Un agent reçoit un objectif, pas une instruction : « répondre au client sous 4 heures » plutôt que « envoie ce mail », et il déduit lui-même les étapes (vérifier, rédiger, escalader, confirmer).
- 2
Tout agent de production repose sur trois briques : perception (API, bases de données, documents), logique de décision et interface d'action journalisée, réversible si possible et soumise à permissions.
- 3
Les agents sérieux utilisent des arbres de décision structurés pour les cas courants et n'appellent le modèle que pour les situations ambiguës.
- 4
Le modèle n'exécute jamais un outil lui-même : il émet une requête structurée que la couche d'orchestration valide, exécute et dont elle renvoie le résultat.
- 5
La fenêtre de contexte sert au travail en cours, une mémoire externe (fichiers, bases) à l'historique, qui fait aussi office de piste d'audit en cas de problème.
- 6
Selon l'auteur, la plupart des échecs viennent d'une planification sautée : l'agent doit décomposer l'objectif, identifier les dépendances et soumettre son plan à un humain avant d'exécuter.
- 7
Le bon périmètre : laisser l'agent traiter les 80 % de cas simples et router les 20 % complexes vers des humains.
Objectif contre instruction
L'auteur, passé trois ans par Meta et aujourd'hui à la tête d'une entreprise qu'il dit valoir 3 millions de dollars, pose une définition simple : un agent agit en votre nom à partir d'un objectif, et non d'une consigne pas à pas.
La nuance sépare un simple déclencheur d'une compréhension du workflow entier. Un script envoie un mail. Un agent chargé de garantir une réponse client sous 4 heures vérifie si quelqu'un a déjà répondu, rédige sinon, escalade si le sujet est complexe et s'assure de la bonne réception.
Sa boucle : observer l'état, décider, agir, observer le résultat, recommencer jusqu'à atteindre l'objectif ou une condition d'arrêt fixée par l'humain. Ce qui le distingue de l'automatisation classique, c'est la gestion des exceptions : router vers un humain, journaliser l'erreur, attendre des consignes.
Trois briques et des outils bien bornés
Perception, logique de décision, interface d'action : sauter l'une des trois, prévient l'auteur, et l'agent devient inutile ou dangereux. Point notable, il recommande de réserver le LLM aux cas ambigus et de traiter le routinier par des arbres de décision classiques.
Les outils sont des fonctions qui font une seule chose : envoyer un mail, interroger une base, créer un événement. Le modèle se contente de demander leur appel avec des paramètres ; c'est la couche d'orchestration qui vérifie les permissions, valide les entrées et exécute.
Un bon outil a des états de succès et d'échec clairs et renvoie des données structurées. Un outil qui échoue silencieusement empêche l'agent de raisonner sur ce qui s'est passé.
Mémoire et planification
Un workflow peut s'étaler sur des heures et une douzaine d'étapes. Même avec 200K tokens de contexte, impossible de tout charger : l'agent écrit des résumés dans une mémoire externe et ne recharge que ce qui sert l'objectif courant.
Cette mémoire sert aussi de journal d'audit : chaque décision est tracée avec son contexte, ce qui permet de retrouver où le raisonnement a déraillé.
L'auteur insiste sur la planification. Son exemple de migration de données client oppose un agent qui écrit directement des scripts, rate des cas limites et lance tout en heures ouvrées, à un agent qui compare les schémas, estime les volumes, repère les enregistrements atypiques, prévoit une vérification et un plan de rollback, le tout validé par un humain.
Échecs, garde-fous et permissions
Trois modes d'échec recommandés : retry avec backoff exponentiel pour les erreurs transitoires, human-in-the-loop quand l'agent n'est pas sûr de lui, et échec sûr, c'est-à-dire ne jamais supprimer d'anciennes données.
Les garde-fous sont des limites infranchissables (actions interdites, rate limits). Les permissions relèvent du contrôle d'accès par rôle : lire mais pas modifier, créer mais pas supprimer.
Détail d'architecture important : l'agent ignore ces contraintes. Il tente des actions, et c'est l'orchestration qui bloque ce qui n'est pas autorisé. La sécurité ne dépend donc pas de la bonne volonté du modèle.
Construire son premier agent, et savoir s'abstenir
La recette proposée : objectif précis, inventaire des informations nécessaires, écriture et test indépendant des outils, logique de décision, orchestration, tests sur données réelles, puis ajout des garde-fous, rate limits et validations au fil de ce qui casse.
Le résultat sera étroit, et c'est voulu : fiabiliser une tâche avant d'élargir. Les agents conviennent aux décisions répétitives qui demandent un peu de jugement mais suivent des schémas apprenables.
L'auteur annonce un éventuel « Agents 102 » sur la composition multi-agents et les hiérarchies, et conclut par une invitation à passer à la pratique, avant un appel à réserver un audit IA gratuit chez Varick Agents.
“An agent is a system that takes actions on your behalf based on the goals you give it, not instructions.”
“Most agent failures happen because people skip the planning step.”
“If a tool sometimes works and sometimes fails silently, the agent can't learn from it.”
Perché conta
Ce guide ne révèle rien qu'un ingénieur ayant déjà mis un agent en production ignore, mais il a le mérite de recentrer le discours sur ce qui fait réellement tenir ces systèmes : orchestration déterministe autour du modèle, permissions appliquées hors du LLM, journalisation, plan validé par un humain, périmètre étroit. Le conseil de réserver le modèle aux cas ambigus, à rebours du « tout LLM », est sans doute le plus utile. Il faut néanmoins le lire pour ce qu'il est : du content marketing d'une agence qui vend des audits, appuyé sur des chiffres invérifiables (3 millions de dollars, gain de « 10x »). Certaines affirmations restent optimistes, comme l'idée que les agents « apprennent » des corrections humaines, qui suppose une infrastructure de mémoire ou de fine-tuning que le texte ne décrit pas. Et le ratio 80/20 est présenté comme un constat maison, pas comme une mesure. Une bonne porte d'entrée pour un décideur ou un débutant, pas une référence technique.
Per te
Falla lavorare sulle tue fonti.
Gratis: un mese di articoli e tre fonti tue. Pro: tutto l'archivio e le tue fonti, da 8 €/mese.
Per il tuo team
La stessa macchina, sui vostri temi.
Uno spazio con i vostri colori, i vostri angoli di monitoraggio, i vostri curatori. Pilota aperto a tre aziende.