Architecture
Une architecture fan-out parallèle qui exécute plusieurs agents simultanément sur des vérifications indépendantes (style, sécurité, performance) puis fusionne les résultats. C'est une approche standard de conception multi-agents pour le débit, s'appliquant bien au CI/CD, à la réponse aux incidents et à la recherche.
Trigger { # Trigger
n1: circle label:"Start"
n2: rectangle label:"PR submitted for review"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Coordinator.n3.handle(top) [label="PR payload"]
}
Coordinator { # Coordinator Agent
n3: rectangle label:"Fan out to reviewers"
n4: rectangle label:"Gather all reviews"
n5: diamond label:"All passed?"
n6: rectangle label:"Approve PR"
n7: rectangle label:"Request changes"
n8: circle label:"Done"
n3.handle(bottom) -> Reviewers.n9.handle(top) [label="Style check"]
n3.handle(bottom) -> Reviewers.n10.handle(top) [label="Security audit"]
n3.handle(bottom) -> Reviewers.n11.handle(top) [label="Perf analysis"]
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Yes"]
n5.handle(bottom) -> n7.handle(top) [label="No"]
n6.handle(right) -> n8.handle(left)
}
Reviewers { # Parallel Review Agents
n9: rectangle label:"Style Agent"
n10: rectangle label:"Security Agent"
n11: rectangle label:"Performance Agent"
n9.handle(top) -> Coordinator.n4.handle(bottom) [label="Style report"]
n10.handle(top) -> Coordinator.n4.handle(bottom) [label="Security report"]
n11.handle(top) -> Coordinator.n4.handle(bottom) [label="Perf report"]
}
Architecture
Une architecture IA agentique à agent unique où un seul agent gère tout : analyser les requêtes, raisonner, appeler les outils via MCP, et générer les réponses. C'est l'architecture par défaut pour les prototypes et automatisations simples—facile à déboguer mais atteint rapidement les limites de fenêtre de contexte et est difficile à paralléliser. Idéale pour les MVPs et les développeurs solo qui livrent vite.
Architecture
Une architecture pipeline séquentiel enchaînant plusieurs agents dans un ordre fixe (analyser → enrichir → analyser → formater), ce qui est une configuration 'microservices LLM' courante quand chaque étape peut être isolée. Cette structure est souvent utilisée dans le traitement de documents et les workflows de type ETL car chaque étape est testable et prévisible.
Architecture
Une architecture orchestrateur-travailleur où un agent orchestrateur décompose un objectif en sous-tâches, les distribue à des travailleurs spécialisés, puis synthétise une réponse finale. C'est l'architecture 'orchestration d'agents' la plus courante—puissante mais l'orchestrateur peut devenir un goulot d'étranglement à mesure que le nombre de travailleurs augmente.
Architecture
Une architecture multi-agents hiérarchique qui scalde l'orchestration en empilant superviseurs et chefs d'équipe (une structure arborescente), ce qui reflète les structures organisationnelles d'entreprise et aide à partitionner le contexte. C'est l'architecture 'IA agentique de niveau entreprise' quand un seul orchestrateur ne peut pas gérer tous les travailleurs directement.
Architecture
Une architecture IA agentique event-driven qui remplace l'orchestrateur central par des topics Kafka/PubSub : les agents s'abonnent, réagissent et publient de nouveaux événements. Cela aligne les systèmes multi-agents avec la chorégraphie microservices éprouvée et est idéale pour les systèmes temps réel, haut débit et les configurations 'maillage d'agents'.
Architecture
Une architecture compétitive / générateur-critique où plusieurs générateurs produisent des réponses indépendantes, puis un agent évaluateur note et sélectionne la meilleure sortie. Cette approche améliore la qualité et réduit la fragilité d'un modèle unique. C'est plus coûteux (plusieurs appels LLM) mais rentable quand la correction ou la créativité compte plus que la latence.