Habr AI décrit l'architecture d'un agent réflexif : moins de pilote automatique, plus d'autovérification

Habr AI a publié une analyse de l'architecture d'un agent d'IA réflexif : un système où le modèle ne se contente pas d'appeler des outils, mais passe par un cycle de vérification obligatoire avant chaque action importante. L'idée centrale est simple : quand l'erreur coûte cher, il vaut mieux qu'un agent soit prévisible plutôt que rapide.

Pourquoi la vitesse ne suffit pas

Un agent classique suit le schéma think → do : il comprend vite la tâche, puis plonge aussitôt dans les fichiers, le CRM, la messagerie ou le terminal. En démo, l'effet est spectaculaire, mais en environnement réel ce mode se heurte vite à des défaillances système. Une hallucination devient une action, une imprécision entraîne une cascade d'erreurs et un objectif mal compris pousse le modèle à ignorer les effets de bord. Le système paraît sûr de lui jusqu'au premier contact avec des données incomplètes, bruitées ou contradictoires.

L'auteur propose de voir le problème non comme un manque d'« intelligence » du modèle, mais comme un manque d'architecture. Même un LLM performant se trompe s'il n'a pas de pause intégrée pour revérifier, de limites d'accès claires ni de mécanisme de retour arrière. Il ne s'agit donc pas d'un nouveau prompt, mais d'une nouvelle boucle d'exécution qui impose la réflexion entre la perception, la décision et l'action. C'est pourquoi la vitesse seule n'est plus considérée comme un avantage suffisant.

Comment fonctionne le cycle

Au lieu de l'enchaînement direct « comprendre puis faire », Habr AI décrit un cycle en sept étapes. À chaque tour, l'agent rassemble un contexte frais, construit un plan, rédige un brouillon de l'action, se vérifie et n'arrive qu'ensuite au commit. Si des données manquent, il peut s'arrêter, poser une question de clarification ou attendre la réponse d'un humain sans perdre l'état de la session. Le mode agent se rapproche ainsi moins d'un pilote automatique que d'un assistant soigneux, capable de mettre une tâche en pause.

L'architecture repose sur plusieurs briques clés :

• Contexte dynamique — avant chaque étape, l'agent rassemble de nouveau les objets, outils, contraintes et l'historique de session disponibles.
• Brouillons de modifications — toute modification vit d'abord dans une couche temporaire au lieu de partir directement en production.
• Phase de réflexion — avant de conclure, l'agent doit vérifier qu'il n'a pas sauté d'étapes, enfreint le format ou laissé des contradictions.
• Porte de confirmation — les opérations risquées restent bloquées jusqu'à l'accord explicite d'un humain.
• Commit et retour arrière — après validation, les changements sont appliqués de façon atomique et, en cas d'échec, l'état peut être restauré depuis un snapshot.

L'idée d'un protocole d'outils universel compte aussi. Via une interface unique, on peut connecter à l'agent le système de fichiers, le terminal, des bases de données, des CRM, des navigateurs, des services de paiement ou des référentiels sectoriels. La logique ne change pas : d'abord rassembler le contexte, puis planifier, ensuite vérifier, et seulement après agir. Le même schéma passe ainsi du développement au droit, à la médecine, à l'analyse et au support sans refonte du noyau.

Où se trouvent les garde-fous

L'article place la sécurité non dans un « filtre de sortie », mais au cœur de la boucle d'exécution. Les actions sont classées par niveau de risque : les lectures sans danger passent automatiquement, les modifications créent des brouillons et les opérations destructrices exigent une confirmation distincte. C'est important pour les publications, les envois en masse, la suppression de données, les transactions financières et toute étape qu'on ne peut plus annuler d'un simple bouton retour. Dans ce schéma, l'humain n'est pas un spectateur, mais le détenteur du droit de veto final.

Des garde-fous techniques s'ajoutent à cette couche : Scope Jail empêche de sortir des ressources autorisées, un détecteur de boucles arrête les actions répétitives, des limites d'itérations et de tokens coupent les scénarios qui s'emballent et les snapshots permettent de ramener la session à son état antérieur. Même si le modèle propose une manœuvre dangereuse, la décision finale ne revient pas au texte, mais à la couche d'exécution, qui contrôle chaque appel d'outil. Cela réduit le coût de l'erreur et rend la boucle de l'agent plus adaptée à la production.

« L'agent le plus intelligent n'est pas celui qui fait tout lui-même »

Le schéma convient aux domaines où l'erreur coûte cher : droit, médecine, finance, support, marketing, infrastructure. Le même motif s'y retrouve partout : d'abord une hypothèse, puis une confrontation aux règles, puis l'action dans le cadre de l'autorisation. L'agent peut préparer une conclusion, un brouillon de réponse, un plan de travail ou un ensemble de modifications, mais la dernière étape reste toujours consciente et vérifiable. C'est ce qui distingue un assistant d'un exécutant inconditionnel.

Ce que cela signifie

L'architecture de l'agent réflexif est une tentative de faire passer l'IA du mode démo spectaculaire au mode outil de travail. Pour le marché, c'est un signal important : les gagnants ne seront pas seulement les modèles les plus « intelligents », mais aussi les systèmes dotés d'une pause d'autovérification, d'un journal d'actions transparent, d'un retour arrière et d'un human-in-the-loop. Ces agents ont une vraie chance de bien fonctionner en production, et pas seulement d'impressionner par leur vitesse lors de présentations. Ce n'est plus de la magie dans l'interface, mais une approche d'ingénieur de l'autonomie.