Huitième article de la série « Production Engineering, Evals & Security avec Claude ».

Ajouter plusieurs agents à une application Claude peut réduire le temps d’exécution de certaines tâches.

Cela peut aussi multiplier fortement le coût, la complexité et les points de défaillance sans améliorer réellement la qualité.

Le module Production Engineering, Evals & Security présente le pattern orchestrator-worker comme un tradeoff délibéré : il est pertinent lorsque le travail peut réellement être découpé en sous-tâches indépendantes exécutables en parallèle. Il est beaucoup moins adapté lorsque chaque étape dépend fortement de la précédente.

---

Le principe du pattern orchestrator-worker

L’architecture comporte généralement trois phases :

1. Planning
2. Parallel fan-out
3. Synthesis

Un agent principal, le lead agent, décompose la tâche.

Plusieurs workers exécutent ensuite les sous-tâches en parallèle.

Enfin, le lead compile leurs résultats.

                  User task
                      │
                      ↓
                 Lead agent
                   PLAN
                      │
          ┌───────────┼───────────┐
          ↓           ↓           ↓
       Worker 1    Worker 2    Worker 3
          │           │           │
          ↓           ↓           ↓
       Result 1    Result 2    Result 3
          └───────────┼───────────┘
                      ↓
                 Lead agent
                 SYNTHESIS
                      │
                      ↓
                 Final answer

Le document donne une structure conceptuelle proche de :

async def orchestrate(task):
    plan = await lead.plan(task)

    results = await gather(*[
        worker.run(subtask)
        for subtask in plan.subtasks
    ])

    return await lead.synthesize(results)

Chaque worker dispose de son propre context window et génère sa propre sortie.

---

Pourquoi utiliser plusieurs agents ?

La principale raison est le parallélisme.

Supposons une recherche nécessitant l’étude de cinq sources complètement indépendantes.

Avec un agent unique :

source A
   ↓
source B
   ↓
source C
   ↓
source D
   ↓
source E
   ↓
synthesis

Le travail est essentiellement séquentiel.

Avec plusieurs workers :

       ┌─ source A
       ├─ source B
lead ──┼─ source C
       ├─ source D
       └─ source E
              ↓
          synthesis

Les recherches peuvent être effectuées simultanément.

Le module donne précisément comme bon candidat une recherche large portant sur plusieurs sources séparées.

---

L’analogie des chercheurs

Le document propose une analogie utile.

Imaginez devoir réaliser une vaste enquête documentaire.

Avec une seule personne :

1 researcher
→ reads everything sequentially

Avec cinq :

5 researchers
→ explore separate areas simultaneously

Vous pouvez terminer plus rapidement.

Mais vous payez aussi cinq personnes.

C’est exactement le tradeoff du multi-agent :

Le parallélisme achète du temps et de la capacité d’exploration en échange d’une consommation supplémentaire de ressources.

---

Chaque subagent possède son propre coût

C’est le point central.

Un worker ne partage pas gratuitement le raisonnement du lead.

Chaque subagent consomme :

its own input tokens
+
its own output tokens
+
its own context

Puis le lead doit encore lire les résultats et effectuer la synthèse.

Architecture de coût :

Lead planning
+
Worker 1 context/output
+
Worker 2 context/output
+
Worker 3 context/output
+
Worker 4 context/output
+
Lead synthesis

Le fan-out multiplie donc rapidement les tokens consommés.

---

Le fameux « 15× » : comment l’interpréter correctement

Le module cite un résultat provenant des travaux de recherche d’Anthropic : dans un système de recherche multi-agent étudié par Anthropic, l’architecture utilisait environ 15 fois plus de tokens qu’une interaction chat normale.

Important :

15×
≠
règle universelle du multi-agent

Ce n’est pas :

« Tout système orchestrator-worker coûte exactement quinze fois plus cher. »

Il faut comprendre :

Anthropic a observé cet ordre de grandeur dans le système étudié.

Le multiplicateur réel dépend notamment :

number of workers
context size
task complexity
tool use
worker outputs
synthesis size

Le chiffre sert surtout à rappeler que le fan-out peut coûter très cher.

---

Exemple de coût

Le document donne un ordre de grandeur concret.

Supposons qu’un agent unique traite une recherche avec environ :

10 000 tokens

Une architecture :

1 lead
+
4 workers
+
final synthesis

peut, dans le cas de référence cité, approcher :

150 000 tokens

si l’on applique l’ordre de grandeur de 15× rapporté dans cette étude.

Encore une fois, ce n’est pas une formule générale.

Mais cela illustre le risque :

a little latency saved
+
almost no quality gain
+
massive token increase

---

Quand ce coût est-il justifié ?

Lorsque les workers accomplissent réellement du travail indépendant.

Exemple :

« Analyse cinq marchés régionaux indépendamment puis compare-les. »

On peut découper :

Worker 1 → Europe
Worker 2 → North America
Worker 3 → Asia
Worker 4 → Africa
Worker 5 → South America

Aucun worker n’a besoin d’attendre la réponse des autres pour commencer.

C’est donc un bon candidat.

---

Le test fondamental : les sous-tâches peuvent-elles être exécutées indépendamment ?

Avant d’utiliser orchestrator-worker, posez cette question :

Chaque worker peut-il faire son travail sans avoir besoin du résultat des autres workers ?

Si oui :

parallelism may help

Si non :

single-agent is probably better

C’est probablement le critère le plus important à retenir.

---

Mauvais candidat : tâche fortement séquentielle

Supposons une refactorisation de code :

1. comprendre l'architecture
2. modifier le modèle de données
3. adapter les appels
4. modifier les tests
5. corriger les erreurs

L’étape 3 dépend de l’étape 2.

L’étape 4 dépend du nouveau code.

L’étape 5 dépend de l’exécution des tests.

On a donc :

A
↓
B
↓
C
↓
D
↓
E

et non :

A B C D E
↓ ↓ ↓ ↓ ↓
parallel

Le document cite justement le coding tightly coupled comme cas où le multi-agent est moins efficace.

---

Pourquoi le multi-agent marche mal sur une tâche séquentielle

Imaginez quatre workers :

Worker A → architecture
Worker B → database changes
Worker C → API changes
Worker D → tests

Mais :

Worker B
needs A

Worker C
needs B

Worker D
needs C

Vous n’avez créé aucun parallélisme réel.

Vous avez seulement créé :

more agents
+
more contexts
+
more coordination
+
more tokens

Le document décrit précisément un cas où le coût avait fortement augmenté alors que la latence n’avait diminué que légèrement et que la qualité avait peu évolué.

---

Le fan-out n’est donc pas un objectif en soi

Un anti-pattern fréquent serait :

task is slow
→ add agents

Ce raisonnement est incomplet.

La vraie question est :

task is slow
      ↓
can it be decomposed
into independent work?

Si oui :

parallel workers

peuvent être utiles.

Sinon :

optimize single agent

est souvent préférable.

---

Single-agent reste le choix par défaut

Le document formule une recommandation forte :

Un single agent avec un bon contexte gère la plupart des tâches pour une fraction du coût.

C’est cohérent avec un principe général d’architecture :

use the simplest architecture
that meets the requirements

Il ne faut donc pas démarrer avec :

multi-agent

simplement parce que l’architecture paraît plus sophistiquée.

On commence par :

single agent

puis on mesure.

---

Workflow déterministe, single-agent ou multi-agent ?

Il faut distinguer trois architectures.

1. Workflow déterministe

L’application connaît déjà les étapes.

parse
→ retrieve
→ call model
→ validate
→ save

Le LLM n’a pas besoin de décider quoi faire ensuite.

C’est le choix le plus simple lorsque le processus est connu.

---

2. Single-agent

Claude décide dynamiquement des actions :

observe
→ decide
→ tool
→ observe
→ decide

C’est utile lorsque le chemin de résolution ne peut pas être totalement prédéfini.

---

3. Multi-agent

Un agent distribue le travail entre plusieurs agents.

lead
→ decompose
→ parallel workers
→ aggregate

C’est justifié lorsque :

dynamic reasoning
+
large task
+
independent subtasks

sont réellement nécessaires.

---

Arbre de décision

Can the workflow be predefined?
          │
     ┌────┴─────┐
    Yes         No
     │           │
     ↓           ↓
Deterministic   Need agentic
 workflow       decisions?
                    │
                    ↓
        Does work split into
        independent parallel parts?
              ┌─────┴─────┐
             No           Yes
              │             │
              ↓             ↓
        Single agent   Orchestrator-worker

Pour l’examen, cette logique est plus importante que de mémoriser un pattern.

---

Le coût de coordination

Le multi-agent n’ajoute pas uniquement le coût des workers.

Il ajoute également :

planning
+
dispatch
+
waiting
+
synthesis

Le lead doit :

1. comprendre la tâche ;
2. créer le plan ;
3. distribuer les sous-tâches ;
4. attendre les résultats ;
5. résoudre éventuellement les contradictions ;
6. compiler la réponse finale.

Le document note donc que des workers parallèles peuvent réduire le wall-clock time sur des travaux indépendants, tout en ajoutant une coordination latency pour la planification et la compilation.

---

Plus d’agents = plus de points de défaillance

Le coût n’est pas le seul problème.

Supposons :

Lead
+
5 workers

Il existe maintenant plusieurs appels susceptibles de rencontrer :

429
529
timeout
tool failure
invalid result

Le document insiste sur le fait que chaque subagent nécessite sa propre discipline de failure handling.

Chaque worker doit gérer :

retriable vs terminal
backoff
retry budget
fallback

Le multi-agent ne remplace pas la résilience.

Il multiplie les endroits où elle doit être appliquée.

---

Exemple : un worker bloque toute la synthèse

Supposons :

Worker 1 → success
Worker 2 → success
Worker 3 → rate limited
Worker 4 → success

Si Worker 3 n’a pas de bonne politique de retry :

Lead
→ waits for worker 3
→ synthesis blocked

Un seul worker peut donc ralentir l’ensemble du workflow.

Le document utilise précisément ce type de scénario pour rappeler que chaque subagent doit appliquer les mêmes stratégies retry/backoff/fallback qu’un agent unique.

---

Il faut instrumenter chaque agent

Le tracing doit permettre de voir :

request
│
├── lead planning
│
├── worker 1
│    ├── tokens
│    ├── latency
│    └── status
│
├── worker 2
│    ├── tokens
│    ├── latency
│    └── status
│
├── worker 3
│    └── ...
│
└── lead synthesis

Sinon vous voyez seulement :

request = expensive

sans savoir pourquoi.

Le module recommande de mesurer au minimum :

token cost
latency
error rate

par appel, puis de les agréger par requête et par flow.

---

Le worker le plus lent peut fixer la latence finale

Supposons :

Worker A = 1 s
Worker B = 1.2 s
Worker C = 6 s
Worker D = 900 ms

Si la synthèse nécessite tous les résultats :

parallel phase
≈ 6 seconds

et non :

≈ 1 second

C’est le problème classique du straggler.

Le parallélisme réduit la somme des durées, mais la latence dépend souvent du worker critique le plus lent, plus le temps de coordination.

---

Le lead n’a pas forcément besoin d’être le même modèle que les workers

Le document propose un levier d’optimisation intéressant :

more capable lead
+
cheaper workers

Pourquoi ?

Le lead doit généralement :

decompose correctly
coordinate
synthesize
resolve conflicts

Les workers peuvent parfois effectuer des tâches plus ciblées.

Architecture conceptuelle :

          capable lead
               │
      ┌────────┼────────┐
      ↓        ↓        ↓
  cheaper   cheaper   cheaper
  worker    worker    worker
      └────────┼────────┘
               ↓
          capable lead

Cela peut réduire le coût par rapport à l’utilisation du modèle le plus coûteux sur chaque worker.

---

Mais il faut toujours valider cette optimisation avec les evals

Remplacer les workers par un modèle moins coûteux n’est acceptable que si :

quality bar still holds

Le workflow devient :

current architecture
      ↓
baseline eval
      ↓
cheaper workers
      ↓
same eval
      ↓
quality acceptable?

Sinon, l’économie n’est pas valide.

---

Un exemple de bon orchestrator-worker

Question :

« Analyse les stratégies d’IA générative de dix entreprises différentes et identifie les tendances communes. »

Découpage possible :

Worker 1 → companies 1–2
Worker 2 → companies 3–4
Worker 3 → companies 5–6
Worker 4 → companies 7–8
Worker 5 → companies 9–10

Chaque worker peut travailler indépendamment.

Le lead synthétise ensuite :

common patterns
differences
recommendations

Ici, le fan-out est naturel.

---

Exemple de mauvais orchestrator-worker

Question :

« Corrige ce bug complexe dans un repository, adapte l’architecture, modifie les tests et vérifie que tout fonctionne. »

Le travail est probablement :

explore
→ understand
→ modify
→ test
→ inspect failure
→ modify again

Les étapes sont fortement liées.

Une architecture :

Worker 1 → architecture
Worker 2 → code
Worker 3 → tests

peut créer des incohérences car les workers raisonnent sur des états différents du code.

Le document recommande dans ce type de tâche un single agent avec un bon contexte plutôt qu’un fan-out artificiel.

---

Multi-agent et context windows

Chaque worker possède son propre contexte.

Cela offre un avantage :

Worker A
→ only needs sources A

Worker B
→ only needs sources B

Le contexte peut être spécialisé.

Mais cela implique également une duplication.

Par exemple, si chaque worker reçoit :

system prompt
tools
task description
shared background

ces tokens peuvent être consommés plusieurs fois.

Ainsi :

5 workers

ne signifie pas seulement cinq sorties.

Cela signifie plusieurs context windows distinctes à alimenter.

C’est une des raisons principales du multiplicateur de tokens décrit dans le document.

---

Limiter ce que reçoit chaque worker

Une conséquence logique du pattern présenté dans le cours est de ne transmettre à chaque worker que ce dont il a besoin.

Mauvais :

Worker 1
→ entire 200-page corpus

Worker 2
→ same entire corpus

Worker 3
→ same entire corpus

Meilleur :

Worker 1
→ relevant slice A

Worker 2
→ relevant slice B

Worker 3
→ relevant slice C

Le document source ne présente pas cette formulation comme une règle séparée, mais elle découle directement de son observation selon laquelle chaque worker paie les tokens de son propre contexte.

---

Ne pas utiliser un multi-agent pour un simple lookup

Question :

« Quel est le délai de remboursement dans cette documentation ? »

Mauvaise architecture :

Lead
├── Worker 1 search docs
├── Worker 2 search docs
├── Worker 3 search docs
└── Worker 4 search docs

La tâche nécessite probablement :

fetch once
→ answer

Le module oppose précisément :

single-fact lookup
→ single_agent + fetch_once

à :

broad research
→ orchestrator_worker

---

Ne pas confondre agentic search et multi-agent

Les deux ne sont pas synonymes.

Agentic search

Un seul agent peut :

search
→ read
→ refine query
→ search again

Il est agentique parce qu’il décide dynamiquement des prochaines recherches.

Multi-agent

Plusieurs agents travaillent :

worker 1
worker 2
worker 3

potentiellement en parallèle.

Donc :

agentic
≠
multi-agent

Une recherche complexe peut être :

single-agent + iterative search

sans orchestrator-worker.

---

La reliability floor s’applique aussi au multi-agent

Le document introduit un principe important :

Définir d’abord le niveau minimal acceptable de fiabilité, puis optimiser le coût sans passer sous cette limite.

Supposons :

latency ceiling = 4 s
retry budget = 3
eval baseline = X

Votre optimisation multi-agent doit respecter ces contraintes.

Si réduire les workers ou utiliser un modèle moins cher fait chuter l’eval sous le baseline :

optimization rejected

Le coût n’est donc jamais le seul critère.

---

Une architecture multi-agent doit gagner son surcoût

La comparaison doit porter sur :

quality
latency
cost
reliability

Par exemple :

Architecture	Quality	Latency	Tokens
Single-agent	8.7	12 s	10k
Multi-agent	8.8	9 s	80k

Ici, le gain est faible.

Le multi-agent est difficile à justifier.

Autre cas :

Architecture	Quality	Latency	Tokens
Single-agent	6.9	40 s	20k
Multi-agent	9.1	12 s	150k

Selon la valeur métier de la tâche, le surcoût peut cette fois être acceptable.

Les chiffres sont illustratifs ; le principe, lui, est celui du cours : mesurer le tradeoff plutôt que supposer que plusieurs agents sont meilleurs.

---

Architecture minimale avant multi-agent

Une démarche raisonnable est :

1. deterministic workflow if sufficient
          ↓
2. single agent if dynamic reasoning needed
          ↓
3. measure quality/latency
          ↓
4. identify independent bottlenecks
          ↓
5. introduce parallel workers only there

Cette progression limite la complexité inutile.

---

Tableau de décision

Tâche	Architecture
Lookup simple dans un corpus stable	Single-agent / fetch_once
Workflow entièrement connu	Workflow déterministe
Recherche itérative	Single-agent avec agentic search
Recherche large sur sources indépendantes	Orchestrator-worker
Refactorisation fortement dépendante	Single-agent
Plusieurs analyses indépendantes	Orchestrator-worker
User-facing réponse rapide simple	Single-agent + streaming
Gros job offline répétitif	Single-agent + Batch/cache

Ce mapping reprend directement les scénarios du module pour distinguer les leviers appropriés.

---

Ce qu’il faut retenir pour la certification

1. Pattern orchestrator-worker

lead plans
→ workers execute independently
→ lead synthesizes

---

2. Son avantage principal

parallel exploration

sur des sous-tâches réellement indépendantes.

---

3. Son coût principal

Chaque worker possède :

own context
+
own input tokens
+
own output tokens

Le coût total augmente donc fortement avec le fan-out.

---

4. Le « 15× » n’est pas une constante universelle

C’est un ordre de grandeur rapporté pour un système multi-agent de recherche Anthropic spécifique.

Pour l’examen :

Ne concluez jamais que « multi-agent = exactement 15× ».

Retenez plutôt :

multi-agent
→ potentially large token multiplier

---

5. Bon candidat

independent subtasks
+
parallel exploration

Exemple :

research across independent sources

---

6. Mauvais candidat

tightly coupled
+
sequential dependencies

Exemple cité :

coding

---

7. Chaque worker nécessite sa propre résilience

retry
backoff
fallback
error handling

Le multi-agent multiplie aussi les failure points.

---

8. Modèles différents possibles

Le document suggère :

more capable lead
+
cheaper workers

comme levier possible de coût, à condition que les evals valident la qualité.

---

Pièges d’examen

Scénario : une recherche nécessite l’analyse parallèle de 20 sources indépendantes.

→ Orchestrator-worker peut être approprié.

---

Scénario : une tâche de coding contient des étapes où chaque modification dépend du résultat de la précédente.

→ Préférer un single-agent avec bon contexte.

---

Scénario : le système est lent, donc vous ajoutez cinq agents.

→ Mauvais raisonnement si vous n’avez pas établi que les sous-tâches sont parallélisables.

---

Scénario : les workers sont exécutés en parallèle mais chacun reçoit le même contexte volumineux.

→ Le coût en tokens peut fortement augmenter car chaque worker possède son propre contexte.

---

Scénario : quatre workers réussissent mais un worker reste bloqué sur un 429.

→ Le workflow global peut être bloqué. Chaque worker nécessite son propre retry/backoff/fallback.

---

Scénario : un single-agent obtient la même qualité qu’un multi-agent avec un coût bien inférieur.

→ Garder le single-agent.

---

Scénario : une question nécessite une seule information dans un corpus stable.

→ fetch_once, pas orchestrator-worker.

---

Scénario : vous utilisez un lead puissant et des workers moins coûteux.

→ Architecture potentiellement pertinente pour réduire le coût, mais elle doit être validée par les evals.

---

À retenir en une phrase

Utilisez orchestrator-worker uniquement lorsque la tâche se décompose réellement en sous-tâches indépendantes qui bénéficient du parallélisme ; sinon, vous payez le coût du fan-out, multipliez les failure points et la consommation de tokens sans obtenir de gain proportionnel.