Anti-Pattern Multi-Agent Overkill : trop d’agents

Idée en 30 secondes

Multi-Agent Overkill est un anti-pattern où trop d'agents sont lancés pour une tâche sans limites de rôles claires.

Résultat : le bruit de coordination augmente : handoffs inutiles, actions dupliquées, et décisions conflictuelles entre agents. Cela augmente latency, cost et le risque de régressions sur des scénarios simples.

Règle simple : ajoutez un nouvel agent seulement s'il a un rôle clair, une valeur mesurable et une limite de responsabilité explicite.

Exemple de l'anti-pattern

L'équipe construit un système support pour des demandes de paiement, de remboursement et de statut de commande.

Au lieu d'un routeur et de 1-2 agents spécialisés, l'équipe ajoute une cascade de nombreuses rôles.

response = orchestrator_agent.run(
    "User: Où est ma commande #18273 ?"
)

Dans ce schéma, une requête simple passe par trop de handoffs :

plan = planner_agent.run(user_message)
route = router_agent.run(plan)
facts = retrieval_agent.run(route)
draft = responder_agent.run(facts)
checked = policy_agent.run(draft)
final = critic_agent.run(checked)

Dans cette chaîne, plusieurs agents commencent souvent à faire des fonctions similaires : par exemple, planner et router dupliquent la classification, tandis que policy et critic vérifient les mêmes règles.

Pour ce cas, une architecture plus simple suffit :

order = get_order(order_id)
return format_order_status(order)

Ici, l'excès d'agents ajoute :

• des handoffs inutiles entre rôles
• des vérifications et décisions dupliquées
• une maintenance difficile après changements

Pourquoi cela arrive et ce qui se passe mal

Cet anti-pattern apparaît souvent quand l'équipe conçoit à l'avance à grande échelle et ajoute des agents "par précaution".

Causes typiques :

• volonté de rendre l'architecture "enterprise-ready" avant besoin réel
• copie de schémas multi-agent de démo sans adaptation aux tâches réelles
• absence de limites claires entre rôles d'agents
• tentative de couvrir chaque cas non standard avec un agent séparé

Cela crée des problèmes :

• latency plus élevée - chaque handoff ajoute une étape
• cost plus élevé - plus d'appels LLM/tool par requête
• conflits de décision - les agents peuvent donner des interprétations différentes du même contexte
• fragilité des changements - modifier un rôle casse des scénarios voisins
• debug difficile - difficile d'identifier quel agent a pris la décision critique

Contrairement à une simple architecture surchargée, la panne principale ici apparaît précisément aux frontières entre agents : pendant les handoffs, la duplication des rôles et la perte du propriétaire de la décision.

Signaux production typiques indiquant qu'il y a déjà trop d'agents :

• une requête utilisateur typique déclenche 4+ agent handoffs alors que 1-2 suffiraient
• le même cas passe par des chaînes différentes selon les runs
• l'ajout d'un agent dégrade success rate ou P95 sur des routes existantes
• l'équipe ne peut pas expliquer clairement qui est le "owner" de la réponse finale

Point important : chaque handoff signifie généralement un nouveau prompt et une nouvelle LLM inference. Quand ces transitions sont trop nombreuses, le nombre d'interprétations possibles augmente et le comportement du système devient moins stable.

Quand ce schéma grossit, sans trace ni visualisation d'exécution, il devient difficile de comprendre quel agent a pris la décision finale et où la chaîne a échoué.

Bonne approche

Commencez avec un schéma multi-rôle minimal : une couche de routage et seulement les agents qui ont une valeur unique. Ajoutez de nouveaux rôles uniquement après des métriques ou des incidents.

Cadre pratique :

• gardez workflow pour les tâches déterministes
• ajoutez des handoffs entre agents seulement quand il y a une vraie spécialisation
• définissez le propriétaire de chaque étape explicitement (qui prend la décision finale)
• mesurez l'effet d'un nouveau rôle (par exemple, amélioration de success rate sans forte hausse de latency et de cost per request)

Si un schéma multi-agent est vraiment nécessaire, commencez au minimum : un coordinator et un specialist, pas une cascade complète de rôles.

def run_support_flow(user_message: str):
    route = classify_intent(user_message)  # simple classifier or rules

    if route == "order_status":
        return run_order_status_workflow(user_message)

    response = specialist_agent.run(user_message)

    if not validate_output(response):  # format, required fields, no empty answer
        return stop("invalid_output")

    return response

Dans ce schéma, les scénarios simples n'entrent pas dans une cascade multi-agent inutile, et les cas complexes sont traités avec le nombre minimal de rôles nécessaires.

Test rapide

Si vous répondez "oui" à ces questions, vous avez un risque multi-agent-overkill :

• Une requête typique passe-t-elle régulièrement par 4+ agent handoffs ?
• Un même cas passe-t-il par des chaînes d'agents différentes selon les runs ?
• Après l'ajout d'un rôle, latency et cost augmentent-ils plus souvent que la qualité ?

Différence avec les autres anti-patterns

Overengineering Agents vs Multi-Agent Overkill

Agent Everywhere Problem vs Multi-Agent Overkill

Too Many Tools vs Multi-Agent Overkill

Auto-vérification : avez-vous cet anti-pattern ?

Vérification rapide de l'anti-pattern Multi-Agent Overkill.
Cochez les points pour votre système et regardez le statut ci-dessous.

Vérifiez votre système :

FAQ

Q : Est-ce que cela veut dire que l'approche multi-agent est toujours mauvaise ?
R : Non. Elle est utile quand les rôles sont vraiment différents, que le handoff a un but clair et que le propriétaire de la réponse finale est explicitement défini. Le problème commence quand il y a plus d'agents que de besoin réel.

Q : Quand ajouter un nouvel agent ?
R : Quand il existe un signal concret : gain de qualité, nouvelle classe de tâches, ou incidents que le schéma actuel ne couvre pas sans croissance disproportionnée de latency, de cost ou de complexité de debug.

Q : Comment simplifier un système multi-agent déjà surchargé ?
R : Commencez par cartographier les rôles : fusionnez les doublons, renvoyez les cas déterministes vers workflow et gardez les handoffs agents seulement là où il existe une spécialisation unique.

Et ensuite

Anti-patterns proches :

• Overengineering Agents - quand le système ajoute des couches sans bénéfice mesurable.
• Agent Everywhere Problem - quand des agents sont ajoutés même pour des tâches simples.
• Too Many Tools - quand l'excès d'outils rend le choix d'action instable.

Ce qu'il faut construire à la place :

• Routing Agent - comment envoyer les cas simples vers workflow et router les cas complexes vers le bon rôle.
• Orchestrator Agent - comment construire une couche de coordination sans handoffs inutiles.
• Hybrid Workflow + Agent - comment combiner branches déterministes et décisions agents sans surcharger le système.