Human-in-the-Loop Architecture : Quand un humain valide les décisions de l’agent

Idee en 30 secondes

Human-in-the-Loop Architecture est un schema gouverne ou le systeme implique un humain avant d executer une action risquee.

L agent peut proposer une action, mais la decision finale pour les etapes critiques est prise par un humain: approve, reject ou revise.

Ce n est pas une gestion manuelle de chaque etape. Un humain intervient seulement la ou le risque est vraiment eleve.

Quand c est utile: quand les actions de l agent peuvent changer l etat, depenser de l argent, toucher des donnees sensibles ou creer un risque juridique.

Le LLM ne doit pas executer seul des side effects critiques (changements d etat). Il propose seulement une action, et le systeme la fait passer dans un processus d approbation controle.

Probleme

Sans Human-in-the-Loop, le systeme tombe souvent dans l un des deux extremes:

• soit l agent agit avec trop d autonomie;
• soit l equipe verifie presque tout manuellement et perd en vitesse.

Echecs typiques sans couche HITL claire:

• une action risquee est executee sans approbation;
• on ne voit pas qui a approuve l action ni pourquoi;
• il est difficile de revenir en arriere ou d expliquer les consequences d une erreur;
• le processus d escalade differe selon les equipes et devient chaotique.

En production, cela se transforme en incidents, releases lents ou audit faible.

Solution

Ajouter Human-in-the-Loop Architecture comme frontiere d approbation explicite (approval boundary) entre la decision de l agent et l execution reelle de l action.

Cette couche definit:

• quelles actions passent sans approbation;
• quelles actions exigent une confirmation humaine;
• comment traiter approve, reject, revise et timeout.

Analogie: comme la double signature dans les operations financieres.

Le systeme peut preparer un paiement, mais un montant eleve exige la confirmation d une personne responsable.

Human-in-the-Loop fonctionne de la meme facon: les etapes importantes ne sont pas executees automatiquement.

Comment fonctionne Human-in-the-Loop Architecture

Human-in-the-Loop Architecture est une couche gouvernee entre Agent Runtime et l execution des actions, qui bascule les etapes critiques vers une approbation humaine.

Ce cycle permet de conserver la vitesse d automatisation et le controle sur les actions critiques.

En code, cela ressemble a ceci

class HumanInTheLoopArchitecture:
    def __init__(self, policy, approval_queue, tool_execution):
        self.policy = policy
        self.approval_queue = approval_queue
        self.tool_execution = tool_execution

    def execute_action(self, action, context):
        decision = self.policy.check(action=action, context=context)
        mode = decision.get("mode")

        if mode == "allow":
            return self.tool_execution.execute(action=action, context=context)

        if mode == "require_approval":
            ticket_id = self.approval_queue.create(
                action=action,
                context=context,
                reason_code=decision.get("reason_code", "approval_required"),
            )

            # Simplified synchronous example for illustration.
            review = self.approval_queue.wait(ticket_id=ticket_id, timeout_s=300)
            if review is None:
                return {"ok": False, "reason_code": "approval_timeout"}

            status = review.get("status")
            if status == "approved":
                approved_action = review.get("action_override", action)
                return self.tool_execution.execute(action=approved_action, context=context)

            if status == "revise":
                return {
                    "ok": False,
                    "reason_code": "approval_revision_required",
                    "feedback": review.get("feedback", ""),
                }

            return {"ok": False, "reason_code": "approval_rejected"}

        return {"ok": False, "reason_code": decision.get("reason_code", "policy_denied")}

Dans cet exemple, wait(..., timeout_s=300) est montre pour clarifier.
En production, HITL fonctionne souvent en asynchrone: le systeme cree un approval ticket, termine le run courant avec le statut pending_approval, puis reprend apres la decision humaine.

Ce que cela donne a l execution

Demande: "Exporte la base clients vers un CRM externe et envoie un email a tous les contacts"

Step 1
Agent Runtime: forme action -> export_customers + send_campaign_email
HITL Gate: classify -> require_approval (high_risk_data_export)

Step 2
Le systeme cree un approval ticket avec contexte et raison
Human: revise -> autoriser seulement le segment "active_customers", sans envoi massif

Step 3
Tool Execution Layer: execute seulement l action approuvee
Runtime: renvoie resultat + reason_code dans la trace

Human-in-the-Loop ne bloque pas completement l automatisation. Il ajoute du controle aux points de risque reel.

Quand cela convient - et quand non

Human-in-the-Loop Architecture est utile la ou le cout d erreur est eleve et ou un humain responsable est requis sur les etapes critiques.

Convient

Ne convient pas

Dans ces cas, des policy-gates sans approbation manuelle suffisent souvent:

decision = policy.check(action, context)
if decision["mode"] == "allow":
    execute(action)

Problemes et echecs typiques

Une couche HITL stable demande plus qu un bouton "Approve"; elle demande une discipline operationnelle claire.

Comment cela se combine avec d autres patterns

Human-in-the-Loop Architecture fonctionne comme une couche de controle gouvernee au-dessus des mecanismes d execution de base.

• Agent Runtime - Runtime pilote la boucle, et HITL decide quelles etapes demandent un humain.
• Tool Execution Layer - apres approbation, l action est executee via un tool gateway controle.
• Policy Boundaries - policy rules definissent quand require_approval est active.
• Hybrid Workflow Agent - HITL est souvent integre aux etapes de commit workflow pour haut risque.
• Orchestration Topologies - dans les systemes multi-agent, HITL s applique a certaines branches ou a l etape finale de merge.

Autrement dit:

• Policy Boundaries definissent ce qui est risque
• Human-in-the-Loop Architecture definit comment exactement un humain confirme ou bloque cette action

Difference avec Supervisor Agent

Supervisor Agent et HITL peuvent etre combines: le supervisor fait un pre-filtrage, et un humain approuve seulement les etapes les plus risquees.

En bref

FAQ

Q: HITL signifie-t-il que chaque action doit etre approuvee par un humain?
A: Non. Approche pratique: seules les actions high-risk passent en approbation, le reste s execute automatiquement.

Q: Qu est-ce qui est mieux pour fail-safe: timeout = allow ou timeout = deny?
A: Pour les actions write risquees, on utilise en general fail-closed: timeout => deny ou fallback sur.

Q: En HITL, peut-on non seulement approuver mais aussi modifier une action?
A: Oui. Le mode revise permet a un humain d approuver une action avec des contraintes (montant, segment, scope).

Q: Quand vaut-il mieux choisir Supervisor Agent plutot que HITL?
A: Quand il faut un controle policy automatise rapide sans intervention manuelle a chaque etape risquee.

Et Ensuite

Human-in-the-loop reduit le risque. L etape suivante est de voir comment cela se relie aux frontieres techniques du systeme:

• Policy Boundaries - quelles actions autoriser, bloquer ou envoyer en approbation.
• Hybrid Workflow Agent - ou placer le workflow deterministe et ou placer les decisions agent bornees.
• Orchestration Topologies - comment repartir les decisions entre plusieurs agents.
• Production Stack - comment assembler cela en architecture production maitrisee.