Blog · Guide · 28 octobre 2026

Donner une étape d'approbation à un orchestrateur : un modèle, avec AEGIS comme exemple concret

Aussi en: English, Español, Português, 日本語, Deutsch · Tous les guides en français

Transparence : 100monkeys.ai développe AEGIS, l'exemple concret de ce guide ; lisez donc les passages sur AEGIS comme le récit du fabricant. Le modèle lui-même est général et vaut pour tout orchestrateur. Ce guide a été rédigé par l'un de nos agents d'IA à partir de la documentation publique d'AEGIS et relu par l'entreprise ; cette version française est une traduction du guide original en anglais.

Une étape d'approbation est un point d'une exécution automatisée où le travail s'arrête, où une personne lit exactement ce qui va se passer, et où l'exécution ne reprend que sur sa réponse. Presque tous les orchestrateurs savent faire une pause. Moins nombreux sont ceux qui la font tenir. Voici le modèle que nous utilisons, étape par étape, avec AEGIS by 100monkeys.ai, in beta, comme exemple concret.

Le modèle en un paragraphe

Placez la porte après que l'agent a préparé l'acte et avant que l'acte n'ait lieu. Montrez à la personne qui relit la chose préparée elle-même, pas un résumé. Décidez à l'avance de ce que vaut le silence. Routez explicitement les deux réponses. Laissez la personne répondre depuis l'endroit où elle se trouve déjà, et gardez la réponse dans l'historique de l'exécution. Bornez les nouvelles tentatives pour qu'un brouillon refusé ne tourne pas en boucle sans fin.

Étape 1. Lister les actes qui demandent une personne

Toutes les étapes n'ont pas besoin d'une porte ; une porte partout apprend aux gens à valider sans lire. Placez une porte devant les actes qui sortent du bac à sable et ne peuvent pas être annulés : envoyer un message à quelqu'un d'extérieur, fusionner dans une branche protégée, dépenser de l'argent, supprimer des données, publier. Tout le reste peut s'exécuter sous une politique écrite à l'avance. Notre article Red levers (en anglais) appelle cela les deux sortes d'arrêt : des limites fixées avant l'exécution, appliquées par le runtime, et une approbation au moment de l'acte, liée à un seul acte.

Étape 2. Couper le travail de l'agent à l'acte

Un agent qui rédige et envoie en une seule étape ne peut pas être arrêté au milieu. Coupez-le en un état qui prépare et un état qui agit, pour que la porte ait sa place. Dans AEGIS, un workflow est une machine à états déclarative, et la porte est un état à part entière, kind: Human :

spec:
  initial_state: DRAFT
  states:
    DRAFT:
      kind: Agent
      agent: draft-agent
      transitions:
        - condition: on_success
          target: APPROVE
    APPROVE:
      kind: Human
      prompt: |
        About to send:
        {{DRAFT.output}}

        Approve? (yes/no)
      timeout: 86400s
      transitions:
        - condition: input_equals_yes
          target: SEND
        - condition: input_equals_no
          target: DISCARD

La forme suit la page Building Workflows de la documentation d'AEGIS ; draft-agent, SEND et DISCARD représentent votre propre agent et vos propres états.

Étape 3. Mettre sous les yeux de la personne la chose exacte

Le prompt est tout ce que voit la personne qui relit, alors rendez-y la sortie préparée. Les prompts d'AEGIS acceptent les modèles du Blackboard : {{DRAFT.output}} ci-dessus est la sortie de l'état précédent, et la documentation montre aussi des scores d'états antérieurs, comme {{QUALITY_CHECK.output.score}}. Qui voit « l'agent veut envoyer un e-mail » approuve une description ; qui voit l'e-mail approuve l'e-mail.

Étape 4. Décider de ce que vaut le silence

Chaque porte a besoin d'un délai et d'une règle pour le moment où il expire. Sur la page Human Approvals, timeout_seconds vaut 3600 par défaut. Avec reject_on_timeout: false, la valeur par défaut, une porte sans réponse fait échouer l'exécution avec human_input_timeout. Avec reject_on_timeout: true, le silence compte comme un non et l'exécution prend la route du refus. Choisissez la seconde option quand une réponse absente doit être un non net plutôt qu'une erreur. Ne faites jamais du silence un oui.

Une remarque sur les champs : la page Human Approvals utilise timeout_seconds et les conditions approved et rejected ; la page Building Workflows utilise timeout ainsi que input_equals_yes et input_equals_no. Utilisez une seule forme de façon cohérente et vérifiez la Workflow Manifest Reference de la version que vous exécutez.

Étape 5. Router les deux réponses et borner la boucle

Un non est une réponse, pas un échec à traiter plus tard. Donnez-lui un état cible : abandonner, ou renvoyer le brouillon à l'agent avec les remarques de la personne qui relit. Si vous renvoyez un refus vers l'état de rédaction, l'exécution a désormais une boucle. AEGIS la borne : max_state_visits par état (5 par défaut, plafond 20) et max_total_transitions par exécution (50 par défaut, plafond 100). Réglez-les sur le nombre d'essais que la personne est prête à tolérer.

Étape 6. Laisser la personne répondre là où elle est

Une porte que personne ne voit est un délai dépassé. Dans AEGIS, la même porte peut recevoir une réponse de trois façons :

• En ligne de commande : aegis workflow signal <execution-id> --response yes.
• Depuis votre propre client : listez les portes en attente avec GET /v1/workflow-gates?status=pending et répondez à l'une d'elles avec POST /v1/workflows/executions/{id}/signal, avec un corps comme { "response": "yes", "feedback": "Keep the flag name short." }.
• Dans Zaru Web : la porte d'une exécution que vous avez lancée apparaît parmi vos approbations en attente, avec un bouton par mot autorisé. La documentation ajoute qu'aucun outil permettant de répondre à une porte n'est proposé au compagnon de Zaru, dans aucun mode ; le modèle qui a préparé l'acte ne peut donc pas l'approuver.

Cette dernière propriété est celle à rechercher dans tout orchestrateur : l'agent ne doit pas détenir la clé de sa propre porte.

Étape 7. Garder la réponse

Une approbation est une preuve. Une fois qu'une porte a reçu sa réponse ou a expiré, AEGIS la garde dans la liste : ?status=answered renvoie chaque porte avec le mot choisi, les remarques, le moment où elle s'est fermée et ce que l'exécution a fait ensuite. Consignez aussi qui a répondu ; le point d'accès d'approbation de la page Human Approvals accepte un champ approved_by, et un refus exige un reason.

Étape 8. Tester la porte avant de s'y fier

Exécutez le workflow trois fois : répondez oui, répondez non, et laissez le délai expirer. Vérifiez que chaque route arrive là où vous le vouliez, et que rien après la porte ne s'est exécuté avant la réponse. Modifiez ensuite le brouillon une fois la porte posée et vérifiez que la personne voit ce qui va réellement s'exécuter. Si votre orchestrateur lie l'approbation à une description plutôt qu'au contenu, c'est ici que vous le découvrez.

Pour aller plus loin

Pour essayer le modèle de bout en bout sur votre propre serveur, suivez Installer AEGIS sur un VPS Ubuntu neuf et lancer votre première tâche approuvée. Pour savoir quoi journaliser et signer autour de chaque porte, lisez la Liste de traçabilité pour agents d'IA en production. Pour la même idée d'approbation dans un assistant personnel, voyez Configurer un assistant Zaru qui gère votre e-mail et votre agenda avec approbations.

Installer AEGIS depuis 100monkeys.ai