Le framework R&D & Un agent concentré est un agent performant

Le framework R&D : Reduce & Delegate

L’idée en une phrase

Tout le context engineering se ramène à un choix binaire, répété à chaque décision : Reduce — limiter ce qui entre dans la fenêtre de l’agent principal — ou Delegate — déporter le traitement lourd et bruyant vers un contexte isolé. Le but n’est pas d’économiser des tokens pour économiser, mais de dépenser les bons tokens afin d’obtenir une exécution réussie du premier coup (1-shot execution).

Analogie : un chef de chantier. Il ne porte pas lui-même chaque outil, chaque plan et chaque sac de ciment : il garde les mains libres pour décider (Reduce) et confie les tâches lourdes et autonomes à des ouvriers spécialisés qui reviennent lui dire « c’est fait » en une phrase (Delegate). S’il tente de tout tenir en main, il devient le goulot d’étranglement et se trompe. La fenêtre de contexte de l’agent, ce sont ses deux mains : leur valeur tient à ce qu’on choisit d’y mettre.

Points clés

• R&D = Reduce & Delegate, deux leviers complémentaires. Reduce agit en amont, sur ce qui entre dans la fenêtre de l’agent principal ; Delegate déporte un travail lourd vers un sous-agent qui dispose de son propre contexte et ne renvoie qu’un résumé.
• L’objectif est le 1-shot : réussir la tâche sans allers-retours correctifs. On accepte volontiers de dépenser des tokens s’ils augmentent la probabilité de réussite ; on refuse ceux qui ne font que remplir la fenêtre.
• Chaque technique du livre se situe sur cet axe R&D. Nommer explicitement le levier (« ici je réduis » ou « ici je délègue ») force une décision claire plutôt qu’un empilement de contexte par réflexe.
• Le levier Delegate est natif dans Claude Code : un sous-agent défini dans .claude/agents/ s’exécute dans sa propre fenêtre et ne rend à l’agent principal qu’une synthèse — le bruit reste chez lui.

Exemple concret

Une fenêtre standard tient de l’ordre de 200 000 tokens. Au démarrage d’une session, la commande intégrée /context révèle souvent une occupation déjà lourde : prompt système et outils intégrés ~15 000 tokens, trois serveurs MCP bien fournis ~30 000, un CLAUDE.md devenu fourre-tout ~8 000 — soit ~53 000 tokens, environ 26 % de la fenêtre, avant la première question. Appliquer Reduce en retirant deux serveurs MCP inutiles pour la tâche libère ~20 000 tokens et ramène l’occupation vers 16 %. Puis la tâche exige de lire cinq pages de documentation, ~40 000 tokens de HTML bruyant : plutôt que de les charger dans la fenêtre principale, Delegate confie l’ingestion à un sous-agent qui renvoie un résumé de ~1 500 tokens. L’agent principal absorbe 1 500 tokens au lieu de 40 000, et reste concentré.

Reduce vs Delegate — deux leviers, un même but

Commande — mesurer avant d’agir

# Dans le REPL Claude Code, à tout moment, la commande intégrée :
/context
# → répartition vivante de la fenêtre par catégorie :
#   prompt système, outils, serveurs MCP, sous-agents,
#   fichiers mémoire (CLAUDE.md), skills, messages de la conversation.
# On ne réduit bien que ce qu'on a d'abord mesuré.

Piège courant : « Reduce, c’est économiser des tokens pour réduire la facture » est inexact. L’enjeu premier est la qualité de l’attention, pas le coût. On peut dépenser beaucoup de tokens intelligemment (un contexte dense et pertinent, exécution en un coup) ou peu de tokens bêtement (une fenêtre encombrée de bruit). La facture allégée n’est qu’un effet secondaire agréable.

Un agent concentré est un agent performant

L’idée en une phrase

Les LLM subissent des lois d’échelle inverses sur l’attention : à mesure que la fenêtre de contexte se remplit, la performance chute — oublis d’instructions, contradictions, hallucinations, perte du fil. Réduire et déléguer ne sont donc pas de la simple hygiène : ce sont les deux gestes qui préservent l’attention de l’agent, donc sa capacité à réussir.

Analogie : un projecteur de scène. Faisceau serré, chaque acteur est nettement éclairé ; élargi pour inonder toute la salle, la même lumière se dilue et les visages deviennent flous. La fenêtre de contexte, c’est la largeur du faisceau ; l’attention, c’est l’intensité lumineuse — une quantité fixe, d’autant plus diluée que la scène s’élargit. Un agent « qui voit tout » voit tout mal.

Points clés

• Plus de contexte n’est pas mieux. Au-delà d’un certain remplissage, chaque token supplémentaire dégrade la sortie : l’attention est un budget fini, réparti d’autant plus mince que la fenêtre est pleine.
• Symptômes d’un agent saturé : il oublie une consigne posée plus tôt, se contredit, hallucine des détails, ignore un fichier qu’il vient pourtant de lire.
• Claude Code expose ce budget : les modèles récents suivent leur propre consommation (token budget), /context en donne la répartition, et la ligne de statut peut afficher le pourcentage occupé.
• Un agent concentré = moins de tokens, mais à plus fort signal → réussite du premier coup. C’est le pourquoi de Reduce & Delegate : les deux leviers existent pour garder l’attention dense.

Exemple concret

Même modèle, même prompt, même tâche de refactorisation, deux façons de charger la fenêtre de 200 000 tokens :

• Run « tout charger » : CLAUDE.md 12 000 + quatre serveurs MCP 45 000 + huit fichiers pré-lus 60 000 = ~117 000 tokens (~58 %) avant même de commencer. L’agent dérive, oublie une contrainte énoncée au tiers de la fenêtre, et réclame trois tours de correction.
• Run « concentré » : deux fichiers ciblés 9 000 + un seul MCP utile 10 000 = ~19 000 tokens (~10 %). L’agent exécute la tâche en un coup.

La différence de résultat ne tient ni au modèle ni au prompt, mais à la densité d’attention : le second agent voit peu, mais voit juste.

Remplissage de la fenêtre et qualité de l’attention

Commande — désaturer une session en cours

# Quand la fenêtre sature au fil d'une longue session :
/context   # 1. mesurer : quelle catégorie pèse le plus ?
/compact   # 2. résumer l'historique pour réduire l'occupation
# /compact est un secours, pas une baguette magique : mieux vaut
# entrer concentré (Reduce en amont) que compacter trop tard.

Piège courant : « /compact vide le contexte et remet l’agent à neuf » est faux. La compaction résume l’historique en une forme plus courte — une compression avec perte : des détails disparaissent. C’est utile pour prolonger une session, mais un agent déjà saturé qu’on compacte reste un agent qui a perdu de l’information. Garder la fenêtre basse dès le départ préserve mieux l’attention que compacter en catastrophe.

Fil rouge — Reduce ou Delegate ?

Ce chapitre est l’axe R&D lui-même : il en pose les deux pôles avant que les chapitres suivants ne les déclinent. Reduce limite ce qui entre dans la fenêtre de l’agent principal (hygiène MCP, CLAUDE.md minimal, context priming — le tier Débutant) ; Delegate déporte le traitement lourd vers des contextes isolés (sous-agents, orchestration, agents en arrière-plan — les tiers supérieurs). L’impact se chiffre : maintenir la fenêtre principale sous ~30-40 % d’occupation garde une attention dense, quand un passage à ~70 % fait basculer vers l’oubli et l’hallucination. Réduire et déléguer, ce n’est pas économiser pour économiser — c’est protéger l’attention de l’agent, la seule ressource qui décide de la réussite au premier coup.

Kata — construire la commande /context-report

Objectif : construire une commande slash /context-report réutilisable qui fait produire à l’agent une fiche de diagnostic de son propre contexte — ce qui l’occupe, plus une action Reduce et une action Delegate à envisager. C’est l’incarnation du chapitre : mesurer, puis décider sur l’axe R&D.

L’artefact : .claude/commands/context-report.md — un prompt réutilisable, structuré en Purpose / Read / Run / Report, que l’on invoque par /context-report dans Claude Code. (Les fichiers de .claude/commands/ restent des commandes slash valides ; ils sont désormais unifiés avec les skills.)

Squelette :

# /context-report — diagnostic R&D du contexte courant

## Purpose
<!-- TODO 1 : une phrase — pourquoi cette commande existe (mesurer avant de réduire) -->

## Read
<!-- TODO 2 : indiquer de lire la sortie de /context (aucun gros fichier à charger) -->

## Run
<!-- TODO 3 : la commande intégrée à lancer pour mesurer l'occupation -->

## Report
<!-- TODO 4 : demander une action Reduce ET une action Delegate concrètes -->

Auto-correction :

# test_kata_day_1_2.py — harnais stdlib pur, aucune dépendance
from pathlib import Path

texte = Path(".claude/commands/context-report.md").read_text(encoding="utf-8")

# 1) Un /context-report bien formé porte les 4 sections Purpose / Read / Run / Report
for section in ["## Purpose", "## Read", "## Run", "## Report"]:
    assert section in texte, f"Section manquante : {section}"

# 2) Le coeur du chapitre : la commande doit nommer les deux leviers R&D
for levier in ["Reduce", "Delegate"]:
    assert levier in texte, f"Levier R&D absent : {levier}"

# 3) Elle doit s'appuyer sur la mesure native
assert "/context" in texte, "La commande doit s'appuyer sur /context pour mesurer"

# 4) Reduce sur l'artefact lui-meme : il reste leger (~1 token pour 4 caracteres)
tokens_estimes = len(texte) // 4
assert tokens_estimes <= 400, f"Trop lourd : ~{tokens_estimes} tokens (viser <= 400)"

# 5) Plus aucun TODO : la commande est reellement terminee
assert "TODO" not in texte, "Des TODO subsistent : commande incomplete"

print("Kata validé !")

# /context-report — diagnostic R&D du contexte courant

## Purpose
Faire le point sur ce qui occupe la fenêtre avant d'agir : on ne réduit bien
que ce qu'on a d'abord mesuré.

## Read
Lire uniquement la sortie de la commande /context — ne charger aucun gros
fichier, l'idée est justement de rester léger.

## Run
- /context

## Report
Résumer en 4 lignes :
1. Les deux catégories les plus lourdes de la fenêtre (en % ou en tokens).
2. Une action Reduce concrète (ex. retirer un serveur MCP inutile).
3. Une action Delegate concrète (ex. confier une lecture volumineuse à un sous-agent).
4. Le pourcentage d'occupation visé après ces deux actions.