Vos agents IA brûlent leur budget avant même de commencer : 4 patterns avancés pour y remédier

Il y a quelques semaines, j'assistais au TechByte "Building with Advanced Agent Capabilities" organisé par Google Cloud (Ivan Nardini, Alex Notov). En parallèle, Anthropic publiait discrètement quatre cookbooks sur des problèmes que tout le monde rencontre en production mais que peu documentent avec des chiffres réels.

Ce qui suit n'est pas un résumé de documentation. C'est une synthèse de patterns que j'applique (ou que j'évalue activement) dans des contextes de transformation IA en production — des cas réels avec des agents Jira/Confluence, des serveurs MCP multiples, et des contraintes qui ne pardonnent pas.

Le problème que personne n'avoue vraiment

Quand vous construisez votre premier agent avec quelques outils, tout semble fluide. Puis vient le jour où vous connectez plusieurs serveurs MCP à votre système, et vous découvrez quelque chose de déplaisant : votre agent consomme des dizaines de milliers de tokens avant même d'avoir reçu la première question utilisateur.

Voici les chiffres publiés par Anthropic dans le contexte du webinar Google Cloud :

...avant la conversation. À l'échelle, on parle facilement de 100 000+ tokens d'overhead systématique. Le problème est double : coût direct en tokens, et dégradation de la précision de sélection d'outils quand le contexte est saturé.

La bonne nouvelle : Anthropic a publié quatre solutions concrètes. Voici comment elles fonctionnent, avec les vrais benchmarks.

Pattern 1 — Tool Search with Embeddings : découvrir les outils à la demande

Le principe

Au lieu de charger toutes les définitions d'outils dès le départ, on donne à l'agent un seul outil méta : tool_search. Quand Claude a besoin d'une capacité, il la cherche sémantiquement. Les définitions correspondantes sont chargées dans le contexte uniquement à ce moment.

Le cookbook Anthropic (Tool search with embeddings) implémente ça avec sentence-transformers/all-MiniLM-L6-v2 — un modèle léger (384 dimensions) qui tourne localement, sans appel API supplémentaire.

Architecture

python

# 1. Au démarrage : embedder tous les outils disponibles
tool_texts = [tool_to_text(tool) for tool in TOOL_LIBRARY]
tool_embeddings = embedding_model.encode(tool_texts, convert_to_numpy=True)

# 2. Lors d'un appel tool_search par l'agent
def search_tools(query: str, top_k: int = 5):
    query_embedding = embedding_model.encode(query, convert_to_numpy=True)
    # Cosine similarity via dot product (embeddings normalisés)
    similarities = np.dot(tool_embeddings, query_embedding)
    top_indices = np.argsort(similarities)[-top_k:][::-1]
    return [TOOL_LIBRARY[idx] for idx in top_indices]

Le résultat de tool_search retourne des tool_reference objects — pas les définitions complètes — ce qui permet à Claude d'utiliser immédiatement les outils découverts.

Résultats mesurés

• Réduction du contexte initial : 90%+ (on passe de N définitions complètes à 1 seule)
• Passage à l'échelle jusqu'à des milliers d'outils sans modification de l'architecture
• La précision de sélection s'améliore car le modèle travaille avec moins de bruit

Quand l'utiliser : dès que vous avez plus de 10-20 outils, ou que vous connectez plusieurs serveurs MCP.

Pattern 2 — Tool Search Tool avec defer_loading : la solution native Anthropic

Ce que révèle le webinar

Dans la présentation Google Cloud, Anthropic a présenté une solution encore plus directe : le paramètre defer_loading: true dans la définition des outils. C'est la version "officielle" du pattern précédent, intégrée directement dans l'API.

Comment ça fonctionne :

1. Vous marquez vos outils avec defer_loading: true
2. Claude ne voit initialement que le Tool Search Tool
3. Quand Claude a besoin d'une capacité, il cherche — les outils correspondants sont chargés à la demande
4. Résultat : seuls les outils pertinents entrent dans le contexte

Les chiffres publiés

Réduction des tokens : 85% tout en maintenant l'accès complet aux outils.

Seuils recommandés pour activer ce pattern :

• Définitions d'outils consommant > 10 000 tokens
• Problèmes de précision de sélection d'outils
• Systèmes MCP avec plusieurs serveurs
• 10+ outils disponibles

C'est exactement la situation type avec des agents Jira/Confluence en entreprise. Un seul serveur Atlassian MCP peut exposer des dizaines d'endpoints.

Pattern 3 — Automatic Context Compaction : les workflows longue durée

Le problème concret

Imaginez un agent de support qui traite 30 tickets en séquence. Chaque ticket nécessite 7 appels d'outils (classification, recherche KB, priorisation, routage, rédaction, validation, clôture). Sans gestion du contexte, au ticket 10, l'agent traîne l'intégralité de l'historique des 9 tickets précédents dans chaque requête.

Le cookbook Automatic Context Compaction mesure ça précisément sur 5 tickets :

Et la qualité du travail reste identique : tous les tickets sont traités correctement.

L'implémentation

python

runner = client.beta.messages.tool_runner(
    model="claude-sonnet-4-5",
    max_tokens=4096,
    tools=tools,
    messages=messages,
    compaction_control={
        "enabled": True,
        "context_token_threshold": 5000,   # Seuil de déclenchement
        "model": "claude-haiku-4-5",        # Modèle moins cher pour les résumés
        "summary_prompt": """..."""          # Prompt personnalisé optionnel
    },
)

Ce qui se passe lors d'une compaction

1. Le SDK détecte que le seuil est dépassé
2. Il injecte un prompt de résumé en tant que message utilisateur
3. Claude génère un résumé structuré (entre balises <summary></summary>)
4. L'historique complet est remplacé par ce seul résumé
5. Le workflow continue avec un contexte propre

Ce qui est conservé : IDs de tickets traités, catégories, priorités, équipes de routage, statut d'avancement.
Ce qui est supprimé : articles complets de la base de connaissances, texte intégral des réponses rédigées, chaînes d'appels d'outils détaillées.

Calibration des seuils

Cas d'usage idéaux : traitement batch de documents, analyse séquentielle de données, pipelines de revue de code, agents de support multitickets.

À éviter : tâches très courtes (< 50k tokens total), audit trails complets requis, workflows de raffinement itératif où chaque étape dépend des détails exacts de l'étape précédente.

Pattern 4 — Programmatic Tool Calling (PTC) : réduire la latence des workflows complexes

Le problème de fond

Dans un workflow classique, chaque appel d'outil génère un aller-retour complet : le modèle décide, l'outil s'exécute, le résultat est renvoyé au modèle, le modèle décide à nouveau. Pour des pipelines qui nécessitent 10-20 appels séquentiels avec des résultats volumineux, ça devient rapidement prohibitif.

Le cookbook Programmatic Tool Calling démontre une alternative : laisser Claude écrire du code Python qui appelle les outils directement dans l'environnement d'exécution, sans round-trip pour chaque invocation.

Benchmark réel : analyse des frais de déplacement

Cas de test : identifier les membres de l'équipe engineering ayant dépassé leur budget de déplacement trimestriel, avec vérification des budgets personnalisés.

Sans PTC, le modèle reçoit intégralement les résultats bruts de get_expenses() — potentiellement des centaines de lignes par employé, avec métadonnées complètes (URLs de reçus, chaînes d'approbation, codes projets). Avec PTC, Claude écrit du code qui filtre, agrège et ne remonte que ce dont il a besoin avant que ces données n'entrent dans la fenêtre de contexte.

python

# Exemple conceptuel de ce que génère PTC
import json

# Claude écrit ce code qui s'exécute localement
expenses = json.loads(get_expenses("ENG001", "Q3"))
travel_total = sum(
    e["amount"] for e in expenses 
    if e["category"] == "travel" and e["status"] == "approved"
)
# Seule la valeur agrégée remonte au modèle — pas les 100+ lignes brutes

Quand utiliser PTC :

• Outils tiers que vous ne pouvez pas modifier retournant de larges résultats
• Dépendances séquentielles entre appels d'outils
• Filtrage/agrégation nécessaire avant analyse par le modèle
• Pipelines à haute fréquence où la latence compte

Pattern 5 — Agent Memory : la persistance inter-sessions

Ce que la plupart des agents oublient

Un agent sans mémoire persistante est un agent qui repart de zéro à chaque conversation. Pour des cas métier — suivi de projet, onboarding utilisateur, analyse longitudinale — c'est rédhibitoire.

Le cookbook Memory & Context Management introduit un système de mémoire via fichier, illustré par l'exemple "Claude joue à Pokémon" : l'agent maintient des notes précises sur des milliers d'étapes de jeu, en développant ses stratégies au fil du temps sans que cela ait été explicitement programmé.

Capacités démontrées :

• Maintien de l'état de projet entre sessions
• Référence au travail précédent sans contexte complet
• Suivi d'objectifs sur des milliers d'étapes
• Construction de notes stratégiques progressives

Architecture simplifiée

python

# Outil memory disponible pour l'agent
@beta_tool
def read_memory(key: str) -> dict:
    """Lire une entrée de mémoire persistante."""
    memory_file = Path(f"memory/{key}.json")
    return json.loads(memory_file.read_text()) if memory_file.exists() else {}

@beta_tool  
def write_memory(key: str, data: dict) -> bool:
    """Persister une information entre sessions."""
    Path("memory").mkdir(exist_ok=True)
    Path(f"memory/{key}.json").write_text(json.dumps(data, indent=2))
    return True

L'agent décide lui-même quoi mémoriser, quand consulter la mémoire, et comment structurer l'information. C'est cette autonomie qui distingue ce pattern d'une simple base de données.

Vue d'ensemble : quand appliquer quel pattern

Dans un projet d'intégration Jira/Confluence via MCP, une combinaison Tool Search + Compaction s'impose naturellement. Un agent exposant 40+ opérations Atlassian ne peut pas se permettre de charger toutes les définitions à chaque conversation.

Ce que ça change pour les architectes et les CTO

Ces quatre patterns ne sont pas des optimisations cosmétiques. Ils représentent un changement de philosophie dans la conception des agents :

Avant : charger tout le contexte au démarrage, espérer que le modèle s'y retrouve.

Après : contexte dynamique, découverte à la demande, compression intelligente. L'agent ne consomme que ce dont il a besoin, quand il en a besoin.

Pour les CTO et les CAIO, les implications concrètes :

Réduction des coûts : 58 à 90% selon le pattern. Sur des agents en production à haute fréquence, ça change l'économie du projet.

Fiabilité accrue : un modèle qui travaille avec un contexte propre fait moins d'erreurs de sélection d'outils. Les benchmarks Anthropic montrent +25% de précision pour Opus 4 avec Tool Search Tool.

Scalabilité réelle : le pattern Tool Search permet de passer de 10 outils à 10 000 sans refactoring architectural. C'est la différence entre un prototype et un système d'entreprise.

Workflows longue durée : la compaction automatique est ce qui rend possible les agents de traitement batch — des workflows qui durent des heures, pas des minutes.

Pour aller plus loin

Les quatre cookbooks Anthropic avec le code complet :

• Automatic Context Compaction — Pedram Navid, Nov. 2025
• Tool Search with Embeddings — Henry Keetay, Nov. 2025
• Programmatic Tool Calling (PTC) — Pedram Navid, Nov. 2025
• Memory & Context Management — Alex Notov, Mai 2025

Le webinar complet : TechByte: Building with Advanced Agent Capabilities — Ivan Nardini & Alex Notov, Google Cloud / Anthropic, Février 2026.

Ces patterns s'appliquent directement à des architectures ADK et à toute intégration MCP en production. Si vous travaillez sur ce type d'architecture en contexte enterprise, je suis disponible pour échanger sur les implications concrètes.