Gouvernance multi-agent : coordination, permissions et contrôle des escalades

L’idée en 30 secondes

Multi-agent governance est le contrôle runtime de la coordination entre agents : qui possède une subtask, qui peut déléguer, et quand il faut arrêter la chaîne de handoff.

Quand c’est nécessaire :
quand plusieurs agents travaillent dans un même workflow et qu’il existe un risque d’actions dupliquées, de conflits de rôles ou de fan-out incontrôlé.

Le problème

Sans gouvernance, un système multi-agent bascule vite en chaos : les agents se délèguent des tâches entre eux, dupliquent les appels et dépensent un budget partagé sans progrès final. En démo, cela paraît souvent "vivant". En production, cela devient des retards, des coûts inutiles et un résultat instable.

Conséquences typiques :

• une subtask a plusieurs owners
• la chaîne de handoff grandit sans fin
• le shared budget est dépensé en duplications

Analogie : c’est comme une équipe sans dispatcher. Les gens sont occupés, mais font la même chose, pendant que les tâches critiques restent bloquées dans les transferts.

Et chaque minute sans règles de coordination augmente le risque de panne en cascade entre agents.

La solution

La solution est d’ajouter une policy layer centralisée pour la multi-agent orchestration dans runtime. Chaque délégation passe des vérifications : role ownership, handoff limits, shared budgets et approval gate pour les actions risquées.

Runtime a besoin d’un modèle unique d’outcomes :

• allow
• stop
• approval_required

Stop reasons typiques dans la boucle multi-agent :

• ownership_conflict
• handoff_budget_exceeded
• delegation_depth_exceeded
• shared_budget_exceeded

Ce n’est pas un conseil du modèle, c’est un contrôle d’exécution imposé avant chaque nouvelle délégation.

Multi-agent governance ≠ orchestration

Ce sont deux couches différentes du système :

• Orchestration définit le routage des tâches entre agents.
• Governance contraint ce routage avec des règles policy.

L’un sans l’autre ne fonctionne pas :

• sans orchestration, pas de workflow piloté
• sans governance, orchestration dégénère vite en duplications, conflits et loops

Exemple :

• orchestration : planner -> researcher -> writer
• governance : max_handoffs=8, max_depth=3, ownership_lock=true

Composants de la multi-agent governance

Ces composants travaillent ensemble à chaque handoff entre agents.

Exemple d’alerte :

Slack: 🛑 Multi-Agent run run_742 stopped: ownership_conflict, handoff=planner -> researcher, task=refund_check.

À quoi ça ressemble dans l’architecture

La multi-agent policy layer se place dans l’orchestrator runtime loop entre la planification et la délégation de subtasks. Chaque décision (allow ou stop) est écrite dans l’audit log. C’est une couche policy logique dans runtime, pas un service séparé.

approval_required pour les write-actions risquées est traité dans un approval flow séparé au-dessus de cette boucle.

Chaque handoff passe ce flow avant exécution :

• orchestrator runtime prépare la subtask suivante
• policy vérifie owner, handoff budget, delegation depth et shared budgets
• allow -> la subtask est déléguée à un agent précis
• stop -> orchestrator runtime passe en fallback (single-agent ou constrained mode)
• les deux décisions sont écrites dans l’audit log

Exemple

planner délègue refund_check à researcher, mais cette subtask a déjà owner=billing_agent. Policy renvoie stop (reason=ownership_conflict).

Résultat :

• la délégation n’est pas exécutée
• le run ne part pas en fan-out de duplications
• les logs montrent le conflit d’owner et la raison d’arrêt

Multi-agent governance arrête l’incident avant fan-out, pas après perte de budget.

En code, ça ressemble à ça

Le schéma simplifié ci-dessus montre le flow principal. Point critique : la vérification doit être centralisée, sinon les agents contournent les limites via des handoffs parallèles.

Exemple de configuration policy :

multi_agent:
  max_agents_per_run: 4
  max_handoffs: 8
  max_delegation_depth: 3
  shared_max_usd: 30
  shared_max_tool_calls: 120
  require_approval_for:
    - billing.refund.create

task = orchestrator.next_task(state)
decision = multi_agent_policy.check(task, state)

audit.log(
    run_id,
    phase="pre_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    from_agent=task.from_agent,
    to_agent=task.to_agent,
    depth=state.delegation_depth,
)

if decision.outcome == "approval_required":
    # approve/resume flow est loggué en step séparé:
    # approval_required -> approval_granted -> allow
    return stop("approval_required")

if decision.outcome == "stop":
    return stop(decision.reason)

result = orchestrator.delegate(task)

shared_budget.consume(
    usd=result.cost_usd,
    tool_calls=result.tool_calls,
)

post_budget_decision = shared_budget.check()
if not post_budget_decision.ok:
    audit.log(
        run_id,
        phase="post_handoff",
        decision="stop",
        reason=post_budget_decision.reason,
        owner=decision.owner,
        handoff_status=result.status,
    )
    return stop(post_budget_decision.reason)

audit.log(
    run_id,
    phase="post_handoff",
    decision=decision.outcome,
    reason=decision.reason,
    owner=decision.owner,
    handoff_status=result.status,
)

return result

À quoi ça ressemble pendant l’exécution

Scénario 1 : ownership conflict

1. planner prépare délégation refund_check.
2. Policy voit que l’owner de la subtask est déjà verrouillé sur un autre agent.
3. Décision : stop (reason=ownership_conflict).
4. Le handoff est bloqué avant exécution.
5. Le conflit est écrit dans l’audit log.

Scénario 2 : handoff budget exceeded

1. Le run a déjà fait 8 transferts de subtasks.
2. La délégation suivante dépasse max_handoffs.
3. Décision : stop (reason=handoff_budget_exceeded).
4. Runtime passe en fallback mode.
5. Le système évite une delegation loop infinie.

Scénario 3 : handoff normal piloté

1. Runtime prépare une nouvelle subtask avec owner valide.
2. Policy vérifie toutes les limites : tout est dans les bornes.
3. Décision : allow.
4. La délégation s’exécute et renvoie un résultat.
5. Les événements pre_handoff et post_handoff sont écrits dans l’audit trail.

Erreurs typiques

• démarrer plusieurs agents sans role ownership map
• autoriser handoff sans limite de profondeur et de nombre
• compter les budgets par agent au lieu d’un shared budget du run
• ne pas avoir de fallback sur stop
• logguer seulement le résultat final sans historique des délégations
• mélanger règles d’orchestration et de governance dans le prompt

Résultat : le système semble scalable, mais sous charge perd vite le contrôle.

Auto-vérification

Vérification rapide de multi-agent governance avant lancement en production :

FAQ

Q : Quand l’approche multi-agent est-elle vraiment justifiée ?
A : Quand les subtasks sont réellement indépendantes et demandent des expertises différentes. Si le workflow est court et linéaire, un seul agent est souvent plus simple et plus fiable.

Q : Qui doit prendre la décision finale : orchestrator ou agent séparé ?
A : Mieux vaut un orchestrator/policy layer responsable unique. Sinon, le risque de conflit et de ping-pong augmente.

Q : Les agents peuvent-ils déléguer directement sans policy check ?
A : En production, non. Chaque handoff doit passer une vérification centralisée ownership, limites et budget.

Q : Comment compter le budget dans un multi-agent run ?
A : Comme un shared budget pour tous les agents ensemble. Sinon chaque agent est "dans la limite" mais le run total dépasse.

Q : Multi-agent governance remplace-t-il step limits et rate limiting ?
A : Non. Il les complète : il gouverne la coordination entre agents, tandis que les step/rate controls gouvernent le comportement d’exécution.

Où Multi-Agent Governance se place dans le système

Multi-agent governance est la couche Agent Governance pour des équipes d’agents orchestrées. Avec RBAC, budget controls, approval, rate limiting et audit, elle forme un runtime contrôlé pour les workflows complexes.

Pages liées

Suite du sujet :

• Vue d’ensemble Agent Governance — modèle de gouvernance de base en production.
• Step limits — comment arrêter les loops avant incident.
• Rate limiting pour agents — comment contrôler les pics d’appels externes.
• Human approval — comment approuver les actions risquées.
• Audit logs pour agents — comment reconstruire les chaînes de décisions handoff.