Anti-Pattern Overengineering Agents : architecture trop complexe

Idée en 30 secondes

Overengineering Agents est un anti-pattern où une tâche simple reçoit une architecture agent trop complexe : trop de couches, rôles, routeurs et checks sans bénéfice réel.

Le système devient plus coûteux, plus lent et plus difficile à maintenir. L'équipe passe plus de temps à maintenir l'architecture qu'à créer de la valeur utilisateur.

Règle simple : si une tâche peut être gérée de façon stable avec un workflow ou un seul agent, ne construisez pas un système multi-couches.

Exemple de l'anti-pattern

L'équipe veut répondre à des questions typiques sur le retour produit.

Au lieu d'un scénario simple, l'équipe construit une cascade de plusieurs agents et couches intermédiaires.

response = gateway_agent.run(
    "User: Comment retourner un article de la commande #7342 ?"
)

En pratique, une requête simple passe par cette chaîne :

plan = planner_agent.run(user_message)
routed = router_agent.run(plan)
draft = faq_agent.run(routed)
checked = policy_agent.run(draft)
final = critic_agent.run(checked)
return final

Pour ce cas, un workflow court suffit :

policy = get_return_policy(order_id)
return format_return_answer(policy)

Dans ce cas, l'architecture surchargée ajoute seulement :

• des couches inutiles entre requête et réponse
• davantage de points de défaillance
• un coût plus élevé par run

Pourquoi cela arrive et ce qui se passe mal

Cet anti-pattern apparaît souvent quand l'équipe essaie de construire tout de suite une "solution enterprise", même pour des scénarios de base.

Causes typiques :

• peur qu'une architecture simple "ne passe pas à l'échelle"
• copie de schémas complexes venant d'autres cas sans valider sa propre tâche
• envie d'ajouter un composant "au cas où"
• absence de métriques prouvant l'utilité de chaque couche

Cela entraîne des problèmes :

• latency plus élevée - la réponse passe par des étapes inutiles
• debug difficile - l'erreur peut se cacher dans n'importe quelle couche
• coût plus élevé - plus d'appels LLM et d'étapes techniques intermédiaires
• contexte gonflé - les agents se transmettent historique et résultats intermédiaires
• fiabilité plus faible - plus de composants = plus de pannes potentielles

Signaux production typiques indiquant que le système est déjà overengineered :

• changer une règle de policy demande des modifications dans plusieurs couches
• l'équipe ne peut pas montrer rapidement où la décision finale est prise
• une requête utilisateur typique lance 4-6 étapes LLM/tool là où 1-2 suffiraient
• retirer une couche intermédiaire casse déjà un scénario de base

Au final, l'équipe n'arrive plus à expliquer rapidement quelle couche est vraiment nécessaire, et tout changement sur un scénario simple touche plusieurs composants en même temps. Quand un système devient complexe, sans trace ni visualisation d'exécution, le debugging devient très difficile. C'est pourquoi les systèmes de production ont généralement une couche d'observabilité dédiée aux runs d'agents.

Bonne approche

Commencez par le chemin le plus simple qui couvre de façon stable la majorité des requêtes aujourd'hui. Ajoutez de nouvelles couches seulement s'il existe un échec mesurable, un risque ou une limite du design actuel.

Cadre pratique :

• workflow pour les scénarios déterministes
• un agent pour les cas complexes ou non standards
• nouvelle couche uniquement avec une raison mesurable (par exemple amélioration de success rate ou réduction d'erreurs sans forte hausse de latency et de cost per request)

def answer_return_question(order_id: str, user_message: str) -> str:
    policy = get_return_policy(order_id)

    if policy.is_standard_case:
        return format_return_answer(policy)

    return agent.run(
        f"Explique ce cas de retour non standard : {policy.context}"
    )

Dans ce schéma, le système reste simple, et l'agent n'est utilisé que là où c'est vraiment nécessaire.

Test rapide

Si ces questions ont la réponse "oui", vous avez un risque d'overengineering :

• Avez-vous 4+ couches sans pouvoir montrer la métrique d'utilité de chacune ?
• Une erreur simple exige-t-elle de traverser de nombreux composants pour le debug ?
• La plupart des requêtes passent-elles aujourd'hui par des cascades d'étapes agent supplémentaires alors qu'un chemin plus simple suffirait ?

Différence avec les autres anti-patterns

Multi-Agent Overkill vs Overengineering Agents

Giant System Prompt vs Overengineering Agents

Agent Everywhere Problem vs Overengineering Agents

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

Vérification rapide de l'anti-pattern Overengineering Agents.
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 qu'une architecture complexe est toujours mauvaise ?
R : Non. La complexité est justifiée quand elle résout un problème réel et que cela se voit dans les métriques. Le problème est la complexité inutile sans valeur.

Q : Quand ajouter un nouvel agent ou une nouvelle couche ?
R : Quand il existe un signal concret : incidents, erreurs de qualité, dépassement de limites ou nouvelle classe de tâches que le design actuel ne couvre pas sans croissance disproportionnée de latency, cost ou complexité de debugging.

Q : Faut-il retirer toutes les couches tout de suite ?
R : Non. Mieux vaut avancer par étapes : retirer les composants sans effet mesurable, puis vérifier les métriques après chaque simplification.

Et ensuite

Anti-patterns proches :

• Agent Everywhere Problem - quand un agent est ajouté même là où un workflow classique suffit.
• Multi-Agent Overkill - quand le système a trop d'agents sans séparation claire des rôles.
• Too Many Tools - comment un excès d'outils rend le comportement de l'agent instable.

Ce qu'il faut construire à la place :

• Hybrid Workflow + Agent - manière pratique de combiner workflow simple et chemin agent.
• Production-Ready Agent - principes de base pour garder une architecture pilotable en environnement réel.