Architecture Multi-Agents : Construire des Systemes qui Pensent Ensemble

Pourquoi Plusieurs Agents Battent un Agent Unique

Voici quelque chose qu'on a appris a la dure : ajouter plus de capacites a un seul agent ne scale pas. A un moment, ton super-agent devient un bordel confus qui jongle avec trop de responsabilites.

Pense a comment les vraies equipes fonctionnent. Tu n'as pas une personne qui fait les ventes, l'ingenierie, le support et le juridique. Tu as des specialistes qui collaborent. Les systemes multi-agents fonctionnent pareil. Chaque agent se concentre sur ce qu'il fait le mieux, et ils se coordonnent pour resoudre des problemes complexes ensemble.

On a construit notre premier systeme multi-agents en production il y a deux ans pour une plateforme de due diligence. Un agent unique n'arretait pas de se melanger entre l'analyse financiere et la revue de documents juridiques. Quand on l'a divise en agents specialises, la precision a bondi de 40% et le temps de traitement a ete divise par deux.

La question n'est pas de savoir si tu as besoin de plusieurs agents. C'est quand tu as depasse un seul agent et comment architecturer la transition.

Patterns de Communication entre Agents

Avant que les agents puissent travailler ensemble, ils doivent se parler. Le pattern de communication que tu choisis definit fondamentalement ce que ton systeme peut faire.

Messages Directs (Point-a-Point)

Le pattern le plus simple. L'Agent A envoie un message directement a l'Agent B et attend une reponse.

// L'Agent de Recherche demande des infos a l'Agent de Donnees
const response = await dataAgent.query({
  from: 'research-agent',
  request: 'Recupere le CA trimestriel des entreprises du secteur sante',
  priority: 'high',
  timeout: 30000
});

Quand l'utiliser :

• Deux agents ont besoin d'une coordination serree
• Exigences de faible latence
• Workflows simples requete-reponse

L'inconvenient : Ca cree un couplage fort. Si l'Agent B tombe, l'Agent A est bloque. Ca scale mal aussi quand tu dois diffuser des informations.

Publish-Subscribe (Event-Driven)

Les agents publient des evenements sur des topics. Les autres agents s'abonnent aux topics qui les interessent. Personne n'a besoin de savoir qui ecoute.

// Quand un nouveau document arrive, publier un evenement
eventBus.publish('document.received', {
  documentId: 'doc-123',
  type: 'contract',
  source: 'client-upload',
  timestamp: Date.now()
});

// L'Agent Legal s'abonne aux evenements de contrats
eventBus.subscribe('document.received', async (event) => {
  if (event.type === 'contract') {
    await legalAgent.startReview(event.documentId);
  }
});

// L'Agent Compliance s'abonne aussi
eventBus.subscribe('document.received', async (event) => {
  await complianceAgent.checkRequirements(event.documentId);
});

Quand l'utiliser :

• Plusieurs agents ont besoin des memes informations
• Les agents doivent operer independamment
• Tu veux un couplage faible et de la scalabilite

L'inconvenient : Plus dur a debugger parce qu'il n'y a pas de call stack clair. Les evenements peuvent se perdre si les subscribers echouent.

Blackboard Partage

Tous les agents lisent et ecrivent dans un espace de travail partage. Pense a ca comme un tableau blanc dans une salle de reunion que tout le monde peut mettre a jour.

// Structure du blackboard pour une tache de recherche
const blackboard = {
  task: {
    goal: 'Analyser l opportunite de marche pour l IA dans la sante',
    deadline: '2025-05-20',
    status: 'in_progress'
  },
  findings: {
    marketSize: { value: '45 Mds EUR', source: 'ResearchAgent', confidence: 0.85 },
    competitors: { value: [...], source: 'CompetitorAgent', confidence: 0.9 },
    regulations: { value: [...], source: 'LegalAgent', confidence: 0.95 }
  },
  openQuestions: [
    'Quel est le paysage du remboursement ?',
    'Quels partenariats cles considerer ?'
  ]
};

Quand l'utiliser :

• Problemes complexes necessitant plusieurs perspectives
• Les agents doivent construire sur le travail des autres
• La structure du probleme emerge pendant la resolution

L'inconvenient : La concurrence devient delicate. Plusieurs agents ecrivant dans la meme zone peuvent creer des conflits.

Message Broker (Base sur les Queues)

Les agents communiquent via un broker de messages central. Les messages sont mis en queue et traites dans l'ordre.

On utilise typiquement une combinaison. Messages directs pour la coordination critique en temps. Pub-sub pour diffuser les mises a jour de statut. Queues de messages pour la distribution du travail.

Strategies de Coordination

Avoir des agents qui peuvent communiquer n'est que le debut. Tu as besoin de strategies pour comment ils travaillent ensemble.

Coordination Hierarchique

Un agent agit comme manager. Il recoit les taches, les decompose, assigne le travail aux sous-agents et agrege les resultats.

                    Agent Manager
                         |
        +----------------+----------------+
        |                |                |
   Agent Recherche  Agent Analyse   Agent Redaction

class ManagerAgent {
  async handleTask(task) {
    // Decomposer la tache
    const subtasks = await this.decompose(task);

    // Assigner aux specialistes
    const assignments = [
      { agent: this.researchAgent, task: subtasks.research },
      { agent: this.analysisAgent, task: subtasks.analysis }
    ];

    // Executer en parallele quand possible
    const results = await Promise.all(
      assignments.map(a => a.agent.execute(a.task))
    );

    // Agreger et synthetiser
    return this.synthesize(results);
  }
}

Ideal pour : Workflows bien definis, limites de taches claires, quand tu as besoin de previsibilite.

Coordination Basee sur le Marche

Les agents font des offres pour les taches selon leurs capacites et disponibilite. L'agent le plus adapte gagne le travail.

class TaskAuction {
  async assignTask(task) {
    // Annoncer la tache a tous les agents capables
    const bids = await Promise.all(
      this.agents.map(agent => agent.bid(task))
    );

    // Chaque offre inclut score de capacite, disponibilite, temps estime
    // {
    //   agent: 'legal-agent-2',
    //   capability: 0.95,
    //   availability: 0.8,
    //   estimatedTime: 120,
    //   price: 0.15  // cout en unites de calcul
    // }

    // Selectionner le gagnant selon fonction de scoring
    const winner = this.selectBest(bids, {
      weights: { capability: 0.5, time: 0.3, price: 0.2 }
    });

    return winner.agent.execute(task);
  }
}

Ideal pour : Charges de travail dynamiques, agents heterogenes, quand le load balancing compte.

Consensus Collaboratif

Les agents discutent et atteignent un accord avant d'agir. Personne ne prend de decisions unilateralement.

class ConsensusGroup {
  async decide(proposal) {
    // Chaque agent evalue la proposition
    const votes = await Promise.all(
      this.agents.map(agent => agent.evaluate(proposal))
    );

    // Verifier le consensus (ex: majorite 2/3)
    const approvals = votes.filter(v => v.approve).length;
    const threshold = Math.ceil(this.agents.length * 0.67);

    if (approvals >= threshold) {
      return { approved: true, confidence: approvals / this.agents.length };
    }

    // Si pas de consensus, les agents partagent leurs raisonnements et reessaient
    const reasoning = votes.map(v => v.reasoning);
    return this.deliberate(proposal, reasoning);
  }
}

Ideal pour : Decisions a enjeux eleves, quand plusieurs perspectives comptent, reduire les erreurs d'un seul agent.

Decomposition de Taches : Decouper les Problemes

Une bonne decomposition de taches est un art. Decoupe trop fin et tu te noies dans le overhead de coordination. Decoupe trop grossier et tu perds les benefices de la specialisation.

Decomposition Fonctionnelle

Separer par type de travail. Les taches de recherche vont aux agents de recherche. Les taches de redaction vont aux agents de redaction.

const decompositionRules = {
  'market-analysis': {
    subtasks: [
      { type: 'research', agent: 'market-research-agent' },
      { type: 'competitor-analysis', agent: 'competitor-agent' },
      { type: 'financial-modeling', agent: 'finance-agent' },
      { type: 'report-synthesis', agent: 'writing-agent', dependsOn: ['research', 'competitor-analysis', 'financial-modeling'] }
    ]
  }
};

Decomposition par Donnees

Separer par les donnees traitees. Chaque agent gere un sous-ensemble.

// Traitement de 10 000 documents pour revue de contrats
const documents = await getDocuments();
const chunks = chunkArray(documents, 1000);

// Distribuer aux agents
const results = await Promise.all(
  chunks.map((chunk, i) =>
    contractAgents[i % contractAgents.length].process(chunk)
  )
);

Decomposition Recursive

Laisse les agents decomposer leurs propres sous-taches. Ca gere les problemes complexes et imprevisibles.

class RecursiveAgent {
  async solve(problem) {
    // Evaluer si le probleme est resolvable directement
    if (this.canSolveDirectly(problem)) {
      return this.directSolve(problem);
    }

    // Decomposer en sous-problemes
    const subproblems = await this.decompose(problem);

    // Resoudre chacun (peut recursiver davantage)
    const solutions = await Promise.all(
      subproblems.map(sp => this.solve(sp))
    );

    // Combiner les solutions
    return this.combine(solutions);
  }
}

Matrice de Decision de Decomposition

Specialisation des Agents

Les agents specialises surpassent systematiquement les generalistes dans leur domaine. Voici comment on pense a la specialisation.

Tradeoff Profondeur vs. Largeur

Agent Generaliste
+------------------+
| Peut tout faire  |
| Moyen en tout    |
+------------------+

Agents Specialistes
+--------+ +--------+ +--------+
|Recherche| |Analyse| |Redaction|
|Expert  | |Expert | |Expert   |
+--------+ +--------+ +--------+

Designer des Agents Specialistes

Chaque specialiste a besoin de :

1. Prompts specifiques au domaine ajustes pour leur tache
2. Outils specialises dont les generalistes n'ont pas besoin
3. Connaissances curatees pertinentes pour leur domaine
4. Memoire focalisee stockant les apprentissages specifiques au domaine

const legalReviewAgent = {
  name: 'legal-review-agent',

  systemPrompt: `Tu es un specialiste de la revue de documents juridiques.
    Focus sur : termes contractuels, clauses de responsabilite, exigences de conformite.
    Signale : provisions inhabituelles, clauses standard manquantes, risques potentiels.
    Format de sortie : JSON structure avec notations de severite.`,

  tools: [
    'legal-database-search',
    'precedent-lookup',
    'clause-comparison',
    'regulatory-checker'
  ],

  knowledge: [
    'contract-law-embeddings',
    'company-legal-policies',
    'historical-contract-reviews'
  ],

  memory: {
    store: 'legal-agent-memory',
    retain: ['common-issues-found', 'client-preferences', 'jurisdiction-rules']
  }
};

Quand la Specialisation Deraille

On a vu des equipes sur-specialiser. Signes que tu es alle trop loin :

• Les agents passent plus de temps a se coordonner qu'a travailler
• Les taches simples rebondissent entre 5+ agents
• Ajouter de nouvelles capacites necessite de repenser tout le systeme
• Les limites de domaine deviennent floues

La solution : Commence avec moins d'agents, plus larges. Specialise seulement quand tu vois des gains de performance clairs en divisant.

Mecanismes de Consensus

Quand plusieurs agents analysent le meme probleme, ils sont souvent en desaccord. Tu as besoin de mecanismes pour resoudre ca.

Systemes de Vote

class MajorityVote {
  async decide(question, agents) {
    const answers = await Promise.all(
      agents.map(a => a.analyze(question))
    );

    // Grouper par reponse
    const votes = {};
    for (const answer of answers) {
      const key = this.normalize(answer.conclusion);
      votes[key] = votes[key] || { count: 0, supporters: [] };
      votes[key].count++;
      votes[key].supporters.push(answer);
    }

    // Trouver la majorite
    const sorted = Object.entries(votes).sort((a, b) => b[1].count - a[1].count);
    const [winner, data] = sorted[0];

    return {
      conclusion: winner,
      confidence: data.count / agents.length,
      dissent: sorted.slice(1).map(([conclusion, d]) => ({
        conclusion,
        count: d.count,
        reasoning: d.supporters[0].reasoning
      }))
    };
  }
}

Consensus Pondere

Tous les agents ne sont pas egaux. Donne plus de poids aux specialistes ou aux reponses a haute confiance.

class WeightedConsensus {
  async decide(question, agents) {
    const answers = await Promise.all(
      agents.map(a => a.analyze(question))
    );

    // Ponderer par expertise de l'agent et confiance auto-declaree
    const weighted = answers.map(a => ({
      conclusion: a.conclusion,
      weight: a.confidence * this.getAgentExpertise(a.agent, question.domain)
    }));

    // Agreger les scores ponderes
    return this.aggregateWeighted(weighted);
  }

  getAgentExpertise(agent, domain) {
    // Base sur la precision historique dans ce domaine
    return this.expertiseScores[agent.id]?.[domain] || 0.5;
  }
}

Debat et Deliberation

Les agents argumentent leurs positions et mettent a jour selon le raisonnement des autres.

class DebateConsensus {
  async decide(question, agents, maxRounds = 3) {
    let round = 0;
    let positions = await this.getInitialPositions(question, agents);

    while (round < maxRounds && !this.hasConsensus(positions)) {
      // Chaque agent voit les positions et raisonnements des autres
      const sharedContext = this.formatPositions(positions);

      // Les agents mettent a jour leurs positions
      positions = await Promise.all(
        agents.map(async (agent, i) => {
          const updated = await agent.reconsider(question, {
            myPosition: positions[i],
            othersPositions: sharedContext
          });
          return updated;
        })
      );

      round++;
    }

    return this.finalDecision(positions);
  }
}

Comparaison des Patterns de Consensus

Exemples d'Architectures Reelles

Regardons des systemes qu'on a vraiment construits.

Systeme de Support Client

                        Agent Routeur
                             |
        +--------------------+--------------------+
        |                    |                    |
   Agent Technique     Agent Facturation    Agent General
        |                    |                    |
   +----+----+          +----+----+              |
   |         |          |         |              |
 Debug    Docs      Remboursement Paiement     FAQ
 Agent   Agent       Agent        Agent       Agent

Communication : Requete-reponse pour le routage. Evenements pour l'escalade. Contexte client partage en base de donnees.

Coordination : Hierarchique avec fallback base sur le marche (si l'agent principal est surcharge, les autres peuvent faire des offres).

Resultats : 65% des tickets completement automatises. Temps de resolution moyen passe de 4 heures a 12 minutes pour les cas automatises.

Plateforme de Recherche et Analyse

   Orchestrateur
        |
   +----+----+----+----+
   |    |    |    |    |
  Web  Data Legal Fin  Synthese
  Agent Agent Agent Agent Agent

Communication : Blackboard partage pour les decouvertes. Queue de messages pour la distribution du travail.

Coordination : Consensus collaboratif pour les conclusions. Chaque agent contribue ses decouvertes, l'agent de synthese resout les conflits.

Decomposition : Fonctionnelle par domaine de recherche. Recursive quand la recherche initiale revele de nouveaux domaines a explorer.

Pipeline de Traitement de Documents

Ingestion -> Classification -> [Branche par type]
                                    |
             +----------------------+----------------------+
             |                      |                      |
       Flow Contrats          Flow Factures          Flow Rapports
             |                      |                      |
        [Agent Legal]          [Agent Finance]       [Agent Analyse]
             |                      |                      |
         Validation              Matching             Synthese
             |                      |                      |
        +----+                 +----+                  +----+
   Revue Humaine          Auto-Traitement          Distribution

Communication : Pipeline event-driven. Chaque etape publie des evenements de completion.

Coordination : Principalement sequentielle avec branches paralleles par type de document.

Specialisation : Agents specifiques au type de document avec connaissance profonde de leur domaine.

Gestion des Erreurs et Resilience

Les systemes multi-agents echouent de manieres interessantes. Voici ce qu'on a appris.

Modes de Defaillance

Construire la Resilience

class ResilientAgentSystem {
  async executeWithFallback(task, primaryAgent, fallbackAgents) {
    try {
      return await this.withTimeout(
        primaryAgent.execute(task),
        30000
      );
    } catch (error) {
      this.logger.warn(`Agent principal echoue : ${error.message}`);

      // Essayer les fallbacks dans l'ordre
      for (const fallback of fallbackAgents) {
        try {
          return await this.withTimeout(
            fallback.execute(task),
            30000
          );
        } catch (fallbackError) {
          this.logger.warn(`Fallback echoue : ${fallbackError.message}`);
        }
      }

      // Tous les agents ont echoue - escalader a un humain
      return this.escalateToHuman(task, error);
    }
  }
}

Circuit Breakers

Quand un agent commence a echouer de maniere repetee, arrete temporairement de lui envoyer du travail.

class CircuitBreaker {
  constructor(threshold = 5, resetTime = 60000) {
    this.failures = 0;
    this.threshold = threshold;
    this.resetTime = resetTime;
    this.state = 'closed'; // closed = normal, open = bloquant
  }

  async execute(fn) {
    if (this.state === 'open') {
      throw new Error('Le circuit breaker est ouvert');
    }

    try {
      const result = await fn();
      this.failures = 0;
      return result;
    } catch (error) {
      this.failures++;
      if (this.failures >= this.threshold) {
        this.state = 'open';
        setTimeout(() => {
          this.state = 'half-open';
        }, this.resetTime);
      }
      throw error;
    }
  }
}

Scaler les Systemes Multi-Agents

Quand ton systeme grandit, tu vas rencontrer des defis de scaling.

Scaling Horizontal

Lance plusieurs instances de chaque type d'agent. Utilise des load balancers pour distribuer le travail.

const agentPool = {
  'research-agent': {
    instances: ['research-1', 'research-2', 'research-3'],
    loadBalancer: 'round-robin'
  },
  'analysis-agent': {
    instances: ['analysis-1', 'analysis-2'],
    loadBalancer: 'least-connections'
  }
};

Metriques de Scaling a Surveiller

Pour Commencer

Si tu construis ton premier systeme multi-agents, voici nos conseils :

1. Commence avec deux agents. Manager et worker. Fais fonctionner la coordination avant d'ajouter de la complexite.

2. Utilise d'abord une communication simple. Les messages directs sont plus faciles a debugger que le pub-sub.

3. Instrumente tout. Log chaque decision d'agent, chaque message, chaque erreur. Tu en auras besoin.

4. Concois pour l'echec. Suppose que les agents vont crasher. Construis la resilience des le premier jour.

5. Mesure l'overhead de coordination. Si les agents passent plus de temps a parler qu'a travailler, simplifie.

Les patterns d'architecture ici ne sont pas theoriques. On a construit des systemes avec chacun d'entre eux. Le bon choix depend de ton probleme specifique, de l'expertise de ton equipe et de tes besoins en scaling.

Les systemes multi-agents sont plus difficiles a construire que les agents uniques. Mais pour les problemes complexes, c'est souvent la seule approche qui fonctionne. Commence simple, mesure tout et fais evoluer ton architecture selon ce que tu apprends.

Si tu explores les architectures multi-agents et tu veux discuter de ton cas d'usage, contacte-nous. On a beaucoup appris des systemes qu'on a construits, et on est contents de partager ce qu'on sait.