Essence du pattern
Multi-Agent Collaboration est un pattern ou plusieurs agents travaillent vers un seul objectif, echangent des resultats, se verifient entre eux et produisent un output final commun.
Quand l'utiliser : quand une tache demande plusieurs roles ou expertises, avec validation mutuelle.
Au lieu du modele "un agent fait tout", le systeme :
- repartit les roles entre agents
- organise un contexte partage
- lance plusieurs rounds d'interaction
- collecte un resultat aligne

Probleme
Imagine qu'il faut preparer un rapport d'investissement.
Il faut en meme temps :
- evaluer le marche et les concurrents
- calculer le modele financier
- verifier les risques juridiques
- assembler le tout en une conclusion coherente
Quand un seul agent fait tout, il change sans cesse de role et perd le focus.
Un agent unique donne souvent soit de la profondeur sur une partie, soit la vue globale, mais rarement les deux bien.
Cela produit souvent :
- des details importants manques
- des roles melanges : analyste, juriste et redacteur dans une seule reponse
- des contradictions entre sections du document
- un texte final qui semble coherent mais reste peu verifie
Voila le probleme : pour une tache complexe multi-domaines, un seul agent est souvent insuffisant.
Solution
Multi-Agent Collaboration repartit le travail entre agents specialises et consolide le resultat en rounds.
Analogie : comme un comite d'experts. Chaque personne gere sa partie, puis l'equipe aligne les conclusions. Le resultat final apparait apres alignement, pas depuis une seule opinion.
Principe cle : ce n'est pas le nombre d'agents qui compte, mais des roles clairs, l'echange des resultats intermediaires, et des regles d'alignement.
Chaque agent produit un resultat partiel, pendant que la collaboration layer pilote le processus :
- Assign Roles : repartir les responsabilites par domaine
- Work : obtenir les resultats de chaque agent
- Exchange/Review : verifier mutuellement et affiner
- Resolve : retirer les conflits entre conclusions
- Synthesize : construire l'output final commun
Cela donne :
- plus de profondeur dans chaque domaine
- verification croisee entre agents
- moins d'aspects oublies
- une conclusion finale alignee
Fonctionne bien si :
- les roles et limites de responsabilite sont clairs
- le shared state et le message format sont structures
- le nombre de rounds est limite (
max_rounds) - les regles de resolve et le critere de fin sont definis
Le modele peut "vouloir" raffiner sans fin, mais collaboration-policy termine le processus dans des limites definies.
Comment ca fonctionne
Les agents ne sont pas isoles entre eux.
Ils interagissent via shared state : blackboard, shared memory, ou file de messages structuree.
Description du flow complet : Assign Roles → Work → Exchange → Synthesize
Assign Roles
Le systeme definit qui fait quoi : recherche, analyse, verification, synthese.
Work
Chaque agent ajoute sa contribution dans l'etat partage.
Exchange
Les agents lisent les resultats des autres, ajoutent des remarques, clarifient les contradictions et ameliorent l'etat partage.
Synthesize
Apres plusieurs rounds, le systeme assemble un output final aligne.
En code, cela ressemble a ceci
agents = [research_agent, finance_agent, risk_agent]
board = {"goal": goal, "draft": {}, "notes": []}
def find_conflicts(draft):
# Exemple simplifie : si les conclusions d'agents divergent, c'est un conflit.
summaries = {str(value).strip().lower() for value in draft.values()}
return [] if len(summaries) <= 1 else ["alignement des conclusions necessaire"]
for round_no in range(1, max_rounds + 1):
# 1) Chaque agent ajoute sa partie dans le board partage
board["draft"]["research"] = research_agent.work(board)
board["draft"]["finance"] = finance_agent.work(board)
board["draft"]["risk"] = risk_agent.work(board)
# 2) Verifier ou les conclusions se contredisent
conflicts = find_conflicts(board["draft"])
# 3) S'il n'y a pas de conflits - on termine
if not conflicts:
break
# 4) S'il y a des conflits - on les garde et on lance le round suivant
board["notes"].append(conflicts)
final_report = build_final_report(board)
return final_report
En bref : les agents ne travaillent pas "chacun dans son coin", mais via un board partage ou contributions et conflits sont visibles pour tous.
A quoi cela ressemble pendant l'execution
Goal: preparer un rapport final de due-diligence d'entreprise
Round 1:
- Research Agent: a ajoute l'analyse de marche
- Finance Agent: a ajoute les calculs financiers
- Risk Agent: a ajoute les risques juridiques
- Le systeme detecte un conflit : "prevision de croissance optimiste" vs "contraintes reglementaires"
- Entre rounds: conflit ajoute dans board["notes"] et renvoye pour refinement
Round 2:
- Finance Agent recalcule le modele avec les contraintes de risque
- Research Agent precise les donnees concurrentielles
- Risk Agent valide les hypotheses mises a jour
- Le systeme detecte un nouveau conflit : "entree rapide sur le marche" vs "besoin de conformite reglementaire supplementaire"
- Entre rounds: points de desaccord renvoyes pour une nouvelle revision
Round 3:
- Les agents alignent les dernieres contradictions
- Plus de conflits
- Le systeme assemble le rapport final
Exemple complet de Multi-Agent Collaboration
Quand c'est adapte - et quand ca ne l'est pas
Adapte
| Situation | Pourquoi ce pattern est adapte | |
|---|---|---|
| ✅ | Tache multi-domaines demandant des expertises differentes | Chaque agent apporte sa specialisation, puis le resultat est reuni en une seule decision. |
| ✅ | La qualite compte plus que la latence minimale | Des rounds d'alignement supplementaires augmentent la qualite, meme si le temps de reponse augmente. |
| ✅ | Validation mutuelle des resultats necessaire | Les agents peuvent trouver les manques des autres via cross-review. |
| ✅ | Un agent unique oublie souvent des aspects | La collaboration reduit les blind spots grace a des roles et perspectives differents. |
Non adapte
| Situation | Pourquoi ce pattern n'est pas adapte | |
|---|---|---|
| ❌ | Tache simple et repetitive | Le surcout de coordination (overhead) est plus grand que le benefice reel. |
| ❌ | Contrainte de temps de reponse minimale | Plusieurs rounds d'echange entre agents augmentent la latence. |
| ❌ | Pas d'infrastructure pour shared state et synchronisation | Sans contexte partage et coordination, les resultats d'agents sont difficiles a aligner. |
Parce que la collaboration ajoute des rounds de communication supplementaires et du surcout de coordination (overhead).
Difference avec Orchestrator
| Orchestrator | Multi-Agent Collaboration | |
|---|---|---|
| Structure | Coordinateur central | Travail partage de plusieurs agents en rounds |
| Type d'interaction | Surtout delegation de sous-taches | Echange intermediaire et verification mutuelle (review) |
| Optimisation | Vitesse d'execution et controle du flux | Qualite de decision et alignement multi-domaines |
| Risque | Mauvais dispatch | Conflits entre reponses d'agents |
Orchestrator repond : "comment repartir le travail".
Multi-Agent Collaboration repond : "comment aligner ensemble une decision commune".
Quand utiliser Multi-Agent Collaboration (vs autres patterns)
Utilisez Multi-Agent Collaboration quand plusieurs agents doivent fournir un output commun et que leurs conclusions peuvent diverger.
Test rapide :
- si vous devez "aligner des avis differents dans une conclusion finale" -> Multi-Agent Collaboration
- s'il suffit de "faire passer des taches par etapes et collecter le resultat" -> Orchestrator Agent
Comparaison avec d'autres patterns et exemples
Aide-memoire rapide :
| Si la tache ressemble a ca... | Utilisez |
|---|---|
| Choisir un seul meilleur executant | Routing Agent |
| Il y a une sequence d'etapes et l'ordre est important | Orchestrator Agent |
| Un policy-check est necessaire avant resultat | Supervisor Agent |
| Plusieurs agents doivent arriver a une conclusion commune | Multi-Agent Collaboration |
Exemples :
Routing : "Le client demande un remboursement - envoyer a Billing, pas a Sales".
Orchestrator : "Preparer un release : d'abord changelog, puis QA, puis deploy".
Supervisor : "Avant envoi d'un email, verifier policies, compliance et promesses interdites".
Multi-Agent Collaboration : "Marketing, Legal et Product doivent aligner un texte final de campagne".
Comment combiner avec d'autres patterns
- Collaboration + Supervisor: les regles de securite sont verifiees pour chaque agent et chaque round.
- Collaboration + Orchestrator: Orchestrator synchronise l'ordre et les dependances entre groupes d'agents.
- Collaboration + RAG: tous les agents utilisent la meme base de connaissance validee pour limiter les contradictions.
En bref
Multi-Agent Collaboration:
- Repartit les roles entre agents
- Organise l'echange des resultats intermediaires
- Lance plusieurs rounds d'alignement
- Produit un output final commun
Avantages et Inconvenients
Avantages
repartit le travail entre agents specialises
resout plus vite les taches complexes
processus plus facile a scaler
resultat verifiable a plusieurs etapes
Inconvenients
coordination entre agents plus complexe
plus de cout en tokens et infrastructure
plus difficile de trouver la cause racine d'une erreur
FAQ
Q: Les agents doivent-ils communiquer directement ?
A: Non. Le plus souvent, ils interagissent via shared state ou message bus.
Q: Comment eviter le "bruit" entre agents ?
A: Definir roles clairs, message format, limite de rounds (max_rounds) et criteres de fin.
Q: Que faire si les agents ne sont pas d'accord ?
A: Ajouter un mecanisme de conflict resolution : vote, lead-agent, Supervisor policy-check, ou human approval.
Et ensuite
Multi-Agent Collaboration aide a aligner le travail de plusieurs agents.
Mais d'ou tous les agents prennent-ils une base de connaissance unique et validee pendant l'execution ?