Idée en 30 secondes
Agent Everywhere est un anti-pattern où la logique agent est ajoutée à chaque tâche, même là où un simple appel API ou un workflow déterministe suffit.
Le système devient alors plus complexe, plus coûteux et moins prévisible. Des tâches qui pourraient être exécutées vite et précisément sont confiées au LLM avec toute son instabilité.
Règle simple : si une tâche peut être décrite comme une séquence claire d'étapes, un agent est superflu.
Exemple de l'anti-pattern
L'équipe veut créer un agent qui répond aux requêtes utilisateurs sur le statut de commande.
Au lieu d'un workflow simple, l'équipe ajoute un agent.
response = agent.run(
"User: Where is my order #18273?"
)
Dans ce schéma, l'agent décide lui-même :
- quel outil appeler
- comment interpréter le résultat
- comment formuler la réponse finale
Mais cette tâche est entièrement déterministe et ne nécessite pas de logique agent. Un workflow simple suffit :
order = get_order(order_id)
return f"Your order is currently {order.status}"
Dans ce cas, l'agent ajoute seulement :
- de la complexité inutile
- des coûts supplémentaires
- un risque d'erreur
Pourquoi cela arrive et ce qui se passe mal
Cet anti-pattern apparaît souvent au début du développement de systèmes agents. L'équipe voit qu'un agent peut traiter des tâches complexes et commence à l'utiliser partout.
Causes typiques :
- volonté de rendre le système "plus intelligent"
- copie d'architectures depuis des démos ou des blogs
- absence de séparation claire entre workflow et agents
- tentative de résoudre toutes les tâches via LLM
Cela crée des problèmes :
- complexité inutile - des tâches simples passent par la boucle de reasoning
- coût plus élevé - LLM est appelé là où ce n'est pas nécessaire
- instabilité - l'agent peut choisir le mauvais tool ou mal interpréter le résultat
- vitesse réduite - les opérations déterministes deviennent plus lentes
Au final, des tâches simples et déterministes passent par la boucle de reasoning du LLM, ce qui ajoute latency, coût et instabilité sans bénéfice réel.
Bonne approche
Il faut utiliser un agent seulement là où la tâche demande vraiment reasoning, choix d'outils ou gestion d'incertitude.
Si la tâche a un workflow déterministe, il vaut mieux l'implémenter comme code classique ou workflow, pas comme agent.
Une bonne architecture ressemble souvent à ceci :
- workflow gère les opérations déterministes
- agent est utilisé seulement pour les décisions complexes
order = get_order(order_id)
if order.requires_review:
result = agent.run(order_context)
else:
result = format_order_status(order)
Dans ce schéma, l'agent est utilisé uniquement là où c'est vraiment nécessaire.
Test rapide
Si ces questions ont la réponse "oui", un agent est superflu :
- Peut-on décrire la tâche en 3-5 étapes claires ?
- Y a-t-il un seul résultat correct ?
- N'y a-t-il pas besoin de planification ou de reasoning ?
Différence avec les autres anti-patterns
Overengineering Agents vs Agent Everywhere Problem
| Overengineering Agents | Agent Everywhere Problem |
|---|---|
| Problème principal : couches d'architecture et composants superflus. | Problème principal : l'agent est utilisé même pour des tâches déterministes. |
| Quand il apparaît : quand on complexifie le système avec des couches supplémentaires sans métriques de bénéfice. | Quand il apparaît : quand même les workflows de base passent en mode agent. |
Multi-Agent Overkill vs Agent Everywhere Problem
| Multi-Agent Overkill | Agent Everywhere Problem |
|---|---|
| Problème principal : excès d'agents et coordination complexe entre eux. | Problème principal : même une tâche simple lance un agent sans nécessité. |
| Quand il apparaît : quand une requête passe par trop de handoffs entre rôles. | Quand il apparaît : quand un scénario déterministe lance directement le reasoning LLM au lieu du code. |
Single-Step Agents vs Agent Everywhere Problem
| Single-Step Agents | Agent Everywhere Problem |
|---|---|
| Problème principal : l'agent tourne en un seul model call sans boucle, recovery ni stop reasons. | Problème principal : l'agent est appliqué là où il n'est pas nécessaire du tout. |
| Quand il apparaît : quand des tâches avec tools ou side effects (changements d'état) tournent en appel unique. | Quand il apparaît : quand des scénarios simples déterministes ne sont pas séparés dans un workflow classique. |
Auto-vérification : avez-vous cet anti-pattern ?
Vérification rapide de l'anti-pattern Agent Everywhere.
Cochez les points pour votre système et regardez le statut ci-dessous.
Vérifiez votre système :
Progression: 0/3
⚠ Il y a des signes de cet anti-pattern
Essayez de déplacer les étapes simples dans un workflow et de garder l'agent uniquement pour les décisions complexes.
FAQ
Q : Est-ce que cela veut dire qu'il ne faut jamais utiliser d'agents ?
R : Non. Les agents sont utiles pour les tâches avec incertitude - par exemple recherche d'information, analyse de données, planification ou travail avec plusieurs outils. Le problème commence quand un agent est utilisé pour des opérations déterministes simples.
Q : Comment savoir qu'une tâche n'a pas besoin d'agent ?
R : Si le résultat est toujours déterminé par des règles claires ou un appel API, un agent est généralement inutile.
Q : Peut-on combiner workflow et agents ?
R : Oui, c'est l'une des meilleures approches. workflow gère les parties déterministes du système, et l'agent n'est utilisé que pour les tâches complexes ou ouvertes.
Et ensuite
Pour mieux comprendre comment éviter l'anti-pattern Agent Everywhere en production :
- Multi-Agent Overkill - quand le système ajoute trop d'agents sans rôle clair pour chacun.
- Too Many Tools - comment un excès d'outils rend le choix d'action instable.
- ReAct Agent - pattern de base où l'agent est utilisé seulement là où le reasoning est vraiment nécessaire.
- Routing Agent - comment laisser les tâches simples au workflow et router les tâches complexes vers le chemin agent.
- Agent Runtime - où séparer techniquement workflow déterministe et logique d'exécution agent.