D1 · Agentic Architecture and Orchestration

C’est le domaine le plus lourd de l’examen Architect — environ 16 des 60 items — et c’est là que les dix anti-patterns mordent le plus fort. Il évalue votre capacité à examiner un système décrit et à choisir l’architecture correcte la plus simple : un prompt unique, un flux de travail fixe ou un véritable agent ; et, s’il s’agit d’un agent, quel patron d’orchestration, comment il se termine, comment il escalade et comment il échoue sans danger. Presque chaque item est un piège entre une réponse sur-conçue et une réponse aveugle aux contraintes.

Objectifs d’apprentissage

À la fin de cette page, vous devriez savoir :

1. Appliquer le cadre de décision workflow vs agent (flux de travail vs agent) et le justifier au regard des contraintes.
2. Choisir parmi les six patrons d’orchestration (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, autonomous agent) et décrire les modes de défaillance de chacun.
3. Mettre en œuvre la boucle agentique et piloter la terminaison depuis stop_reason — non par l’analyse du langage naturel (anti-pattern 1) ni par des plafonds d’itérations arbitraires (anti-pattern 2).
4. Concevoir des hiérarchies coordinateur/sous-agents avec passage de contexte explicite, agrégation des résultats et gestion des défaillances partielles.
5. Concevoir l’escalade sur demande explicite (immédiate) ou par capacité (résoudre d’abord) — jamais sur le sentiment ni la confiance auto-déclarée (anti-patterns 4-5).
6. Choisir entre hooks et prompts pour l’application des règles (anti-pattern 3) et entre Managed Agents et Agent SDK/Tool Runner pour l’hébergement.
7. Propager des erreurs structurées (catégorie, réessayable, résultats partiels) avec idempotence et réessais (anti-patterns 6-7).
8. Trancher entre conversation, fichiers, base de données et memory tool pour l’état, et modéliser le coût et la latence des systèmes multi-agents avec une observabilité par agent.

1.1 Workflow vs agent : la première décision

Un agent est un système où le modèle dirige dynamiquement son propre processus et son usage des outils, décidant de la prochaine action dans une boucle jusqu’à ce qu’il estime la tâche terminée. Un workflow (flux de travail) est un système où le code orchestre le modèle par des chemins prédéfinis — le flux de contrôle est écrit par vous, non décidé par le modèle.

La posture par défaut de l’examen, directement issue des recommandations d’Anthropic, est la suivante : trouver la solution la plus simple et n’augmenter la complexité que lorsqu’elle améliore les résultats de façon démontrable. Un prompt unique bien conçu bat un flux de travail ; un flux de travail bat un agent ; un agent bat un système multi-agents. N’ajoutez de l’autonomie que lorsque la tâche exige réellement une prise de décision ouverte à l’exécution.

1.2 Les six patrons d’orchestration

L’examen attend une aisance complète sur les six. Pour chacun : ce dont il s’agit, un diagramme ASCII, quand l’utiliser et ses modes de défaillance.

Pattern 1 – Prompt chaining

Décomposer une tâche en une séquence fixe d’étapes, chaque appel au modèle consommant la sortie précédente. Ajouter des barrières programmatiques (« checks ») entre les étapes.

Input ──► [Call 1] ──► gate ──► [Call 2] ──► gate ──► [Call 3] ──► Output
                        │                     │
                     fail→fix               fail→stop

À utiliser quand : la tâche se découpe proprement en sous-tâches fixes et vous échangez un peu de latence contre une bien meilleure précision par étape (par ex. plan → ébauche → finition).

Modes de défaillance : cumul d’erreurs le long de la chaîne ; une première étape erronée empoisonne tout ce qui suit ; la latence est la somme de tous les appels.

Pattern 2 – Routing

Classifier l’entrée, puis l’aiguiller vers un prompt/modèle/flux spécialisé.

                 ┌─► [Billing prompt · Haiku]
Input ─► [Router]─┼─► [Technical prompt · Sonnet]
                 └─► [Escalation flow]

À utiliser quand : les entrées se répartissent en classes distinctes mieux traitées séparément, et où une erreur de classification coûte moins cher qu’une approche uniforme. Permet d’envoyer les classes faciles vers des modèles moins chers.

Modes de défaillance : une erreur de classification du routeur se propage en cascade ; trop de classes fragilisent le routeur ; une classe non gérée est traitée à tort en silence.

Pattern 3 – Parallelization (sectioning et voting)

Exécuter des sous-tâches indépendantes en parallèle (sectioning) ou exécuter la même tâche plusieurs fois et agréger (voting).

Sectioning                         Voting
        ┌─►[Worker A]─┐                    ┌─►[Run 1]─┐
Input ──┼─►[Worker B]─┼─►[Merge]   Input ──┼─►[Run 2]─┼─►[Vote]─► Output
        └─►[Worker C]─┘                    └─►[Run 3]─┘

À utiliser quand : les sous-tâches sont indépendantes (sectioning) et la latence compte, ou lorsque plusieurs tentatives augmentent la confiance (voting) — par ex. un garde-fou (guardrail) en plus de la réponse principale, ou une revue de code au vote majoritaire.

Modes de défaillance : un sectioning qui suppose l’indépendance alors que les tâches interagissent en réalité ; un voting qui masque un biais systématique partagé par toutes les exécutions ; un coût multiplié par le fan-out.

Pattern 4 – Orchestrator-workers

Un modèle central (orchestrateur) décompose dynamiquement une tâche, lance des appels de workers et synthétise. Contrairement à la parallelization, les sous-tâches ne sont pas prédéfinies — l’orchestrateur les décide à l’exécution.

Input ─► [Orchestrator] ─┬─► [Worker: search docs]
             ▲           ├─► [Worker: read files]
             │           └─► [Worker: summarise]
             └────────────── synthesise ◄────────┘

À utiliser quand : vous ne pouvez pas prédire les sous-tâches à l’avance (par ex. modifications de code multi-fichiers, recherche où les sous-questions dépendent des découvertes).

Modes de défaillance : les anti-patterns coordinateur/sous-agents — compter sur l’auto-héritage du contexte, absence de gestion des défaillances partielles, coût de fan-out non borné. Voir §1.5.

Pattern 5 – Evaluator-optimizer

Un appel génère, un second évalue au regard de critères explicites et renvoie un retour, puis la boucle se répète jusqu’à ce que les critères passent.

        ┌───────────────────────────┐
Input ─►[Generator]─► draft ─►[Evaluator]─► pass? ─► Output
        ▲                              │ fail
        └────────── feedback ◄─────────┘

À utiliser quand : vous disposez de critères de réussite clairs et vérifiables et l’itération améliore mesurablement le résultat (qualité de traduction, code devant passer des tests, rédaction contre un barème).

Modes de défaillance : l’évaluateur et le générateur partagent une session et donc un biais (anti-pattern 9 — auto-revue dans la même session) ; aucun critère d’arrêt objectif, donc la boucle tourne indéfiniment ou s’arrête arbitrairement ; des critères vagues produisent un retour inutile.

Pattern 6 – Autonomous agent

Un modèle unique exécute une boucle ouverte : il décide d’une action, appelle un outil, observe le résultat et répète jusqu’à ce qu’il estime la tâche terminée ou qu’une condition d’arrêt se déclenche.

              ┌─────────────────────────────┐
User goal ─► [Claude] ─► tool_use ─► [Env] ──┘
                 ▲          result
                 └── loop while stop_reason == "tool_use"
                     stop when end_turn / gate / human

À utiliser quand : la tâche est réellement ouverte, l’environnement fournit un retour fiable, et les erreurs sont récupérables ou barrées par une approbation humaine pour les actions irréversibles.

Modes de défaillance : boucler indéfiniment (mauvaise terminaison) ; agir sur un état périmé ou halluciné ; prendre des actions irréversibles sans barrière ; les deux anti-patterns de boucle ci-dessous.

1.3 La boucle agentique et la terminaison pilotée par stop_reason

Tout agent est une boucle. La seule manière correcte de la piloter est le champ stop_reason de l’API. Les deux anti-patterns les plus testés se trouvent ici.

Valeurs de stop_reason : end_turn, tool_use, max_tokens, stop_sequence, pause_turn, refusal.

from anthropic import Anthropic

client = Anthropic()
messages = [{"role": "user", "content": "Investigate the failing test and fix it."}]

while True:
    resp = client.messages.create(
        model="claude-opus-5",
        max_tokens=4096,
        tools=TOOLS,
        messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason == "tool_use":
        results = run_tools(resp.content)          # exécute les outils demandés
        messages.append({"role": "user", "content": results})
        continue                                    # boucle : le modèle a vu les résultats
    elif resp.stop_reason == "end_turn":
        break                                       # le modèle a terminé
    elif resp.stop_reason == "max_tokens":
        raise OutputTruncated()                     # ne PAS traiter comme un achèvement
    elif resp.stop_reason == "pause_turn":
        continue                                    # server tool long ; reprendre
    elif resp.stop_reason == "refusal":
        escalate_to_human(resp)                     # le modèle a décliné ; stopper la boucle
        break

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();
const messages: Anthropic.MessageParam[] = [
  { role: 'user', content: 'Investigate the failing test and fix it.' },
];

while (true) {
  const resp = await client.messages.create({
    model: 'claude-opus-5',
    max_tokens: 4096,
    tools: TOOLS,
    messages,
  });
  messages.push({ role: 'assistant', content: resp.content });

  if (resp.stop_reason === 'tool_use') {
    const results = await runTools(resp.content);
    messages.push({ role: 'user', content: results });
    continue;
  } else if (resp.stop_reason === 'end_turn') {
    break;
  } else if (resp.stop_reason === 'max_tokens') {
    throw new Error('Output truncated – not a completion signal');
  } else if (resp.stop_reason === 'refusal') {
    await escalateToHuman(resp);
    break;
  }
}

Une conception de terminaison correcte combine : stop_reason comme signal principal, un plafond d’itérations/tokens/coût comme filet de sécurité, et des barrières explicites (approbation humaine pour les actions irréversibles).

1.4 Managed Agents vs Agent SDK / Tool Runner : la décision d’hébergement

1.5 Hiérarchies coordinateur/sous-agents

Lorsqu’un seul agent ne peut pas porter toute la tâche, un coordinateur la décompose et délègue à des sous-agents, chacun avec sa propre fenêtre de contexte isolée. C’est le patron orchestrator-workers à l’échelle du système (le scénario Multi-Agent Research System).

                 ┌──────────────┐
   User goal ───►│ Coordinator  │  holds plan, aggregates, decides done
                 └──────┬───────┘
        explicit context│ (never rely on inheritance)
        ┌───────────────┼────────────────┐
   ┌────▼────┐     ┌────▼────┐      ┌────▼────┐
   │Subagent1│     │Subagent2│      │Subagent3│  isolated context each
   └────┬────┘     └────┬────┘      └────┬────┘
        └── structured result ──────────┘
                 aggregate + handle partial failure

Passage de contexte explicite

Les sous-agents ont des fenêtres de contexte isolées. Ils n’héritent pas automatiquement de la conversation, des fichiers ou des découvertes du coordinateur. Le coordinateur doit passer explicitement tout ce dont le sous-agent a besoin dans son prompt de tâche.

# CORRECT : le sous-agent reçoit exactement ce dont il a besoin, explicitement.
subagent_task = {
    "role": "user",
    "content": (
        f"Objective: {objective}\n"
        f"Context you must use:\n{relevant_findings}\n"
        f"Constraints: {constraints}\n"
        f"Return: a JSON object {{'finding': str, 'sources': [str], 'confidence': str}}."
    ),
}

Agrégation des résultats et gestion des défaillances partielles

Les sous-agents échouent indépendamment. Le coordinateur doit agréger des résultats structurés et décider quoi faire lorsque certains échouent.

results, failures = [], []
for sub in subagents:
    try:
        r = run_subagent(sub, timeout=SUB_TIMEOUT)
        if r.status == "ok":
            results.append(r)
        else:
            failures.append((sub, r.error))     # erreur structurée, non avalée
    except TimeoutError as e:
        failures.append((sub, {"category": "timeout", "retryable": True}))

# Décider : continuer avec des résultats partiels, réessayer les réessayables, ou escalader.
if len(results) >= MIN_QUORUM:
    answer = coordinator_synthesise(results, note_missing=failures)  # provenance des lacunes
else:
    escalate("insufficient subagent results", partial=results, failures=failures)

La conception correcte fait remonter la défaillance partielle au coordinateur avec un détail structuré, puis prend une décision explicite (continuer avec un quorum en notant la lacune, réessayer les réessayables, ou escalader). Écarter en silence un sous-agent en échec et présenter le reste comme complet est l’anti-pattern 7.

1.6 Conception de l’escalade

L’escalade est l’un des sujets les plus régulièrement testés, car trois des dix anti-patterns sont des pièges d’escalade. Le jeu de règles :

def should_escalate(turn) -> bool:
    if turn.user_explicitly_requested_human:
        return True                              # immédiat
    if turn.requires_capability_agent_lacks and turn.resolution_attempts_exhausted:
        return True                              # fondé sur la capacité, après avoir essayé
    # PAS : turn.sentiment == "angry"
    # PAS : turn.model_confidence < 0.7
    return False

1.7 Hooks vs prompts pour l’application des règles

Certaines règles sont critiques — elles doivent toujours tenir (ne jamais supprimer des données de production, ne jamais valider de secrets, toujours exécuter les tests avant un commit). Faites-les respecter par du code déterministe : les hooks de Claude Code ou des gardes programmatiques dans votre boucle. N’appliquez jamais une règle critique par une instruction de prompt.

1.8 Propagation d’erreurs avec contexte structuré

Les erreurs doivent porter assez de structure pour qu’un appelant (ou le modèle) puisse décider quoi faire : catégorie, indicateur réessayable, et tout résultat partiel.

class AgentError(Exception):
    def __init__(self, category, message, retryable, partial=None):
        self.category = category        # e.g. "rate_limit", "validation", "timeout", "auth"
        self.message = message          # specific, diagnostic
        self.retryable = retryable      # drives backoff vs. escalate
        self.partial = partial          # data gathered before failure

# À la frontière, renvoyer un contenu d'erreur structuré sur lequel le modèle peut raisonner :
tool_result = {
    "type": "tool_result",
    "tool_use_id": tu_id,
    "is_error": True,
    "content": json.dumps({
        "category": "rate_limit", "retryable": True, "retry_after": 12,
        "partial": partial_rows,
    }),
}

Idempotence et réessais

Réessayez 429, 5xx et 529 avec un backoff exponentiel + jitter, et respectez retry-after. Mais ne réessayez sans danger que les opérations idempotentes — donnez aux opérations d’écriture une clé d’idempotence pour qu’un « create order » réessayé ne crée pas deux commandes.

def with_retry(fn, *, max_attempts=5):
    for attempt in range(max_attempts):
        try:
            return fn()
        except RetryableError as e:
            if attempt == max_attempts - 1:
                raise
            sleep(min(2 ** attempt + random.random(), 30))   # backoff + jitter

1.9 État et mémoire vs conversation

L’historique de conversation n’est pas un état durable. Il est réduit par l’édition de contexte, résumé par la compaction et perdu d’une session à l’autre. Tout ce qui doit survivre appartient à un état explicite.

1.10 Modélisation du coût et de la latence des systèmes multi-agents

Chaque agent et sous-agent, ce sont des appels au modèle, et le fan-out multi-agents multiplie à la fois le coût et la consommation de tokens. Modélisez cela avant de construire.

• Coût ≈ Σ sur les appels de (tokens d’entrée × prix-entrée + tokens de sortie × prix-sortie). Chaque sous-agent porte son propre system prompt et ses outils en entrée — un fan-out de 5 signifie ~5× le surcoût fixe. Le prompt caching (0,1× sur les lectures de cache) et des modèles moins chers pour les sous-tâches simples (Haiku pour la classification) réduisent cela fortement.
• Latence : le chaining ajoute les latences en série ; la parallelization borne la latence par la branche la plus lente ; les arbres coordinateur/sous-agents profonds ajoutent des allers-retours.
• Le compromis : un système de recherche multi-agents peut coûter 10 à 15× le coût en tokens d’un appel unique. Ne le justifiez que lorsque le gain de qualité ou d’ampleur est réel. Si un flux de travail atteint la barre, utilisez le flux de travail.

Single agent:      1 system + N tool round-trips              (cheapest, serial)
Parallel workers:  1 orchestrator + K×(system+tools)          (fast, K× fixed cost)
Deep hierarchy:    coordinator + Σ subagents + aggregation    (most capable, most $$)

1.11 Observabilité

On ne peut pas opérer ce qu’on ne voit pas. Un système multi-agents a besoin de :

• Traces par agent — chaque agent/sous-agent émet un span avec ses entrées, appels d’outils, stop_reason, tokens et coût.
• Identifiants de corrélation — un ID de requête unique tissé à travers le coordinateur et chaque sous-agent pour reconstruire une tâche unique de bout en bout.
• Métriques — latence par agent (p50/p95), taux d’erreur par catégorie, nombre de réessais, tokens et coût par tâche, taux de succès du cache.
• Journaux structurés sans secrets.

1.12 Variantes d’orchestration et leurs modes de défaillance

Au-delà des six patrons de base, les rédacteurs d’items les combinent en variantes nommées. Reconnaître la variante vous indique le mode de défaillance à surveiller.

Hierarchical (hiérarchique : coordinateur → sous-coordinateurs → workers)

                 [Root coordinator]
                  /            \
        [Sub-coord A]        [Sub-coord B]
         /       \             /       \
    [W1]        [W2]       [W3]        [W4]     isolated contexts throughout

À utiliser quand une tâche se décompose en grands sous-domaines qui ont eux-mêmes besoin d’être décomposés. Modes de défaillance : la perte de contexte s’aggrave à chaque palier (chaque niveau doit passer le contexte explicitement) ; le coût et la latence se cumulent (chaque palier ajoute des allers-retours) ; une défaillance en milieu de palier peut orphelin un sous-arbre entier.

Pipeline with feedback (pipeline avec retour : chaining + evaluator-optimizer)

[Extract] ─► [Transform] ─► [Load] ─► [Evaluate]
    ▲                                    │ fail
    └──────────── targeted retry ◄───────┘

À utiliser quand un pipeline fixe a besoin d’une barrière de qualité en fin de course capable de renvoyer le travail à une étape spécifique. Modes de défaillance : un retour vers la mauvaise étape ; des boucles de retour non bornées sans arrêt objectif ; l’évaluateur partageant la session du générateur (#9).

Blackboard / shared-state coordination (tableau noir : coordination par état partagé)

   [Agent A] ─┐          ┌─► reads/writes
   [Agent B] ─┼─► [Shared state store] ◄─┼─ [Agent C]
   [Agent D] ─┘          └─► reads/writes

À utiliser quand plusieurs agents contribuent à un artefact commun en évolution (un document de recherche, un plan). Modes de défaillance : conditions de course et pertes de mises à jour sur le stockage partagé ; aucun propriétaire unique du « done » ; lectures périmées. Corrigez par des écritures transactionnelles, du versionnage et un seul coordinateur qui décide de l’achèvement.

1.13 Le calcul de coût et de latence que l’on peut vous demander

L’examen peut vous donner des comptes de tokens et des prix, et vous demander le coût relatif de deux topologies. Utilisez les prix de septembre 2026 (entrée/sortie par million de tokens) : Opus 5 $5/$25, Sonnet 5 $2/$10, Haiku 4.5 $1/$5, Fable 5.1 $10/$50. Lectures de cache ≈ 0,1× entrée ; Batch ≈ 0,5×.

Exemple travaillé — agent unique vs fan-out à 5 workers. Chaque appel porte un préfixe stable de 10k tokens (system + outils) et produit 1k de sortie. Sur Opus 5 :

Per call input  = 10,000 tokens × $5 / 1,000,000  = $0.050
Per call output =  1,000 tokens × $25 / 1,000,000 = $0.025
Per call total  = $0.075

Single agent, 4 tool round-trips  ≈ 4 × $0.075          = $0.300
5-worker fan-out (each 1 call) + 1 synthesis           = 6 × $0.075 = $0.450
   ...but each worker re-sends the 10k prefix, so the fixed overhead
   is paid 6× instead of being amortised — fan-out is ~1.5× here,
   and grows with prefix size and worker count.

Deux leviers qui changent la réponse :

• Prompt caching. Si le préfixe de 10k est mis en cache, chaque lecture coûte 10,000 × $0.50/1,000,000 = $0.005 au lieu de $0.050 — le surcoût fixe du fan-out s’effondre et la pénalité multi-agents diminue drastiquement.
• Mix de modèles. Aiguillez les workers simples vers Haiku ($1/$5) et réservez Opus à la synthèse ; une conception à 5 workers Haiku + synthèse Opus peut passer sous le coût d’un agent unique tout-Opus tout en ajoutant de l’ampleur.

1.14 Les barrières human-in-the-loop comme architecture de premier plan

L’autonomie est un spectre. L’architecte choisit où un humain se place dans la boucle et rend cette barrière déterministe, non une requête de prompt.

La barrière se place sur l’irréversibilité et le rayon d’impact, non sur la confiance du modèle ni le ton de l’utilisateur. Un remboursement au-dessus d’un seuil, un déploiement en production, un e-mail sortant vers une liste de clients — ceux-ci reçoivent une barrière dure, quel que soit le degré de certitude que le modèle prétend avoir.

Idées reçues fréquentes

Étude de scénario — un système de recherche qui « perd le fil »

Situation. Une équipe livre un assistant d’étude de marché. Un coordinateur découpe une question en sous-questions et dispatche des sous-agents qui recherchent et résument chacun. En production, deux problèmes apparaissent : (1) les sous-agents contredisent parfois des découvertes que le coordinateur avait déjà établies, et (2) lorsque l’API de recherche d’un sous-agent expire, le rapport final est livré comme s’il était complet, omettant parfois un concurrent entier. La direction se plaint aussi que le système coûte 12× un appel Opus unique et demande s’il faudrait le simplifier. La barre de précision a été atteinte en test par une conception en deux étapes « plan → résumé-parallèle → synthèse ».

Trace de raisonnement d’expert.

1. Nommer le patron. Les sous-questions sont décidées à l’exécution à partir des découvertes → c’est orchestrator-workers, donc attendez-vous aux modes de défaillance coordinateur/sous-agents, non à un correctif de routing ou de chaining.

2. Diagnostiquer le problème (1). Des sous-agents « contredisant des découvertes connues » est le symptôme classique du contexte isolé : les sous-agents n’ont jamais reçu les faits établis par le coordinateur. Le correctif est le passage de contexte explicite dans le prompt de tâche de chaque sous-agent avec une forme de retour fixe — non une fenêtre plus grande (option tentante mais aveugle aux contraintes) et non un meilleur modèle.

3. Diagnostiquer le problème (2). Présenter un rapport partiel comme complet après un timeout est une suppression silencieuse (#7). Le correctif est une erreur structurée (category:"timeout", retryable:true) remontée au coordinateur, qui réessaie alors le réessayable, continue avec un quorum en notant la lacune, ou escalade — jamais un rejet silencieux et jamais un générique « research failed » (#6).

4. Traiter la question du coût/de la simplification. La conception en deux étapes atteignait déjà la barre de précision. La topologie profonde et coûteuse est de la sur-conception. La décision correcte est d’utiliser la conception plus simple et de n’ajouter de la complexité que là où elle améliore les résultats de façon démontrable — tout en mettant en cache le préfixe stable et en aiguillant les résumés simples vers Haiku pour réduire le coût restant. Rejeter « utiliser un modèle plus gros » et « ajouter plus de sous-agents » est essentiel.

5. Rendre les défaillances observables. Ajoutez des spans de trace par agent + un identifiant de corrélation pour que le prochain timeout soit attribuable, en rejetant « ajouter plus de réessais » comme correctif d’observabilité.

Décision correcte à l’examen : passage de contexte explicite + gestion structurée des défaillances partielles avec un quorum + repli sur la conception en deux étapes + caching/mix de modèles pour le coût + traces par agent. Chaque option rejetée correspond à un anti-pattern nommé (ignorance de l’isolation, #7, #6, sur-conception, escalade sur confiance/sentiment) — ce qui est exactement la façon dont les distracteurs sont construits.

Pièges d’examen dans ce domaine

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Tentez-le avant de révéler.

Points clés à retenir

• Préférez l’architecture la plus simple qui atteint l’exigence : prompt unique < workflow < agent < multi-agents.
• Connaissez les six patrons et leurs modes de défaillance ; associez le patron à qui — vous ou le modèle — décide du flux de contrôle.
• Pilotez la terminaison de boucle depuis stop_reason ; n’utilisez les plafonds que comme filet de sécurité ; traitez max_tokens comme une troncature, pause_turn comme une reprise et refusal comme un arrêt-et-escalade.
• Passez le contexte aux sous-agents explicitement à chaque palier — les contextes isolés n’auto-héritent jamais ; spécifiez la forme du retour pour une agrégation propre.
• Gérez la défaillance partielle avec des erreurs structurées et une décision explicite (quorum, réessai, escalade) — jamais des rejets silencieux.
• Escaladez sur demande explicite (maintenant) ou lacune de capacité (après avoir tenté) ; jamais sur le sentiment ni la confiance auto-déclarée.
• Appliquez les règles critiques et les barrières d’actions irréversibles avec des hooks/permissions déterministes, calés sur le rayon d’impact, non des instructions de prompt.
• Persistez tout ce qui est durable dans le memory tool ou un état externe ; ne réessayez que les écritures idempotentes avec backoff et jitter ; et instrumentez chaque agent avec des traces et des identifiants de corrélation.
• Reconnaissez les variantes d’orchestration (hierarchical, pipeline-with-feedback, blackboard) et le mode de défaillance que chacune introduit ; n’ajoutez des paliers que lorsque l’ampleur ou la qualité s’améliore de façon démontrable.
• Modélisez coût/latence avant de construire : mettre en cache le préfixe stable et aiguiller les sous-tâches simples vers des modèles moins chers bat généralement « modèle plus gros » ou « plus d’agents ».
• Le fan-out paie le surcoût fixe du préfixe par worker ; le caching l’effondre, ce qui en fait le levier de coût correct à l’examen.