Agent superviseur : contrôle des actions et des risques

Essence du pattern

Supervisor Agent est un pattern dans lequel un agent separe controle l'execution : il verifie les actions proposees, applique des regles et decide si on peut continuer.

Quand l'utiliser : quand des actions critiques doivent etre approuvees separement par policy avant de continuer.

Au lieu de faire confiance au worker sans condition, Supervisor :

• verifie chaque action critique
• la compare aux policies
• renvoie une decision : approve, revise, block ou escalate
• enregistre la raison de la decision dans les logs

Probleme

Imagine qu'un worker agent execute une tache en production et ait acces aux outils.

Il propose une action techniquement valide qui viole une policy :

• email a la mauvaise audience
• SQL query avec risque de modification des donnees
• depense au-dessus du budget
• acces a des donnees sensibles sans access scope requis

Une etape techniquement possible n'est pas toujours autorisee ni sure pour le business.

Sans controle separe, cela peut passer directement en execution.

Consequences :

• incidents en production
• violations de securite et de compliance
• pertes financieres imprevues
• audit faible et postmortem difficile

Voila le probleme : un worker peut proposer une action qui "fonctionne techniquement", mais qui est inacceptable selon policy.

Solution

Supervisor ajoute une policy-control layer entre proposition d'action et execution.

Analogie : c'est comme une revue technique avant un lancement en production. Le worker propose une etape, et le supervisor verifie si elle est sure et autorisee. Seulement apres cela, l'action peut etre executee.

Principe cle : d'abord verification et decision du supervisor, ensuite execution.

Le worker propose une action, et supervisor-policy renvoie :

• approve
• revise
• block
• escalate

Processus pilote :

1. Observe : recevoir la proposition d'action du worker
2. Evaluate : verifier avec policy + execution runtime state
3. Decide : approve/revise/block/escalate
4. Enforce : executer, renvoyer pour revision, ou arreter
5. Log : enregistrer decision et raison

Cela apporte :

• moins de risque d'actions dangereuses avant execution
• impossibilite de contourner policy
• escalade controlee vers un humain
• audit transparent des decisions

Cela fonctionne bien si :

• worker n'a pas de bypass direct de la execution layer
• policy verifie intent + runtime context
• les decisions du supervisor sont vraiment appliquees
• les actions high-risk ne sont pas auto-approuvees

Le modele peut "vouloir" executer tout de suite, mais c'est supervisor-policy qui decide si l'action est autorisee.

Comment ca fonctionne

Supervisor n'execute pas la tache metier lui-meme.

Il controle si l'etape suivante peut etre executee en verifiant :

• securite
• budget
• permissions
• compliance
• stop conditions

En code, cela ressemble a ceci

proposal = worker.next_action(context)

decision = supervisor.review(
    action=proposal,
    budget_state=budget_state,
    policy=policy,
)

if decision.type == "approve":
    result = execute(proposal)
    context.append(result)
elif decision.type == "revise":
    context.append(f"Supervisor feedback: {decision.reason}")
elif decision.type == "escalate":
    wait_for_human_approval(proposal)
else:
    stop(reason=decision.reason)

Supervisor ne remplace pas Worker Agent. Il ajoute une verification entre planification et execution.

A quoi cela ressemble pendant l'execution

Goal: traiter un remboursement client

Worker proposal:
- refund 5000 USD
- send confirmation email

Supervisor:
- policy check: auto-refund autorise seulement jusqu'a 1000 USD
- decision: escalate, confirmation humaine necessaire

Human approval (approve with changes):
- approved_refund_amount: 800 USD
- comment: "J'approuve le remboursement seulement dans la limite de 800 USD"

Execution:
- refund 800 USD (montant issu de la decision humaine)
- send confirmation email

Status: termine

Quand c'est adapte - et quand ca ne l'est pas

Adapte

Non adapte

Parce que Supervisor ajoute une etape de verification supplementaire et peut ralentir l'execution.

Difference Avec Guarded-Policy

En bref : Supervisor est une couche de supervision pour les decisions complexes.

Guarded-Policy est une barriere automatique basee sur des regles.

Quand Utiliser Supervisor (vs Autres Patterns)

Utilisez Supervisor quand une supervision et un policy-check sont necessaires avant resultat final ou action risquee.

Test rapide :

• si vous devez "verifier policies, compliance et risques" -> Supervisor
• si vous devez "seulement gerer l'ordre des etapes" -> Orchestrator Agent
• si vous devez "bloquer/reecrire automatiquement les actions avant execution" -> Guarded-Policy Agent

Comment combiner avec d'autres patterns

• Supervisor + ReAct: Supervisor verifie chaque etape Act avant appel d'outil.
• Supervisor + Routing: on controle non seulement l'action, mais aussi vers qui la tache a ete routee.
• Supervisor + Orchestrator: policies et limites s'appliquent a chaque branche parallele, pas seulement au resultat final.

En bref

Avantages et Inconvenients

FAQ

Q : Supervisor remplace-t-il les permissions d'infrastructure (RBAC, ACL) ?
A: Non. C'est un controle logique supplementaire. Les restrictions techniques de base doivent rester dans l'infrastructure.

Q : Que faire si Supervisor bloque trop souvent des actions utiles ?
A: Affiner les policies : ajouter exceptions, niveaux de risque et regles de human approval pour scenarios gris.

Q : Supervisor peut-il devenir un single point of failure ?
A: Oui, si aucun fallback n'est prevu. Donc on ajoute en general timeout, safe default policy et mode graceful degradation.

Et ensuite

Supervisor controle que les agents individuels restent dans les limites des policies.

Mais que faire quand plusieurs agents doivent collaborer sur une tache commune ?