Le mythe de l'agent omniscient

Dans l'industrie des agents IA, une croyance persiste : plus on connecte d'outils à un agent, plus il devient intelligent. Google vous donne accès à 50 APIs ? Connectez-les toutes. Meta propose 30 endpoints différents ? Ajoutez-les au contexte. Notion, Figma, Xero, Analytics... Plus le contexte est riche, meilleure sera la réponse, n'est-ce pas ?

Faux.

En faites c’est même complètement l'inverse : plus vous chargez d'outils dans le contexte d'un LLM, plus il devient inefficace, lent et coûteux. Ce phénomène s'appelle le Context Saturation, et c'est le principal frein à la scalabilité des agents IA multi-outils.

Avec Bumps Brain, nous construisons un écosystème d'agents IA pour les dirigeants d'agences marketing. Notre promesse : connecter tous vos outils (Google Ads, Meta Ads, Analytics, Supabase, Notion, Xero, Figma...) via le protocole MCP (Model Context Protocol) et permettre à vos équipes d'interroger ces données en langage naturel.

Sauf qu'en pratique, quand on connecte 15 services MCP à un seul agent Claude ou GPT-4, voici ce qui se passe :

Intenable.

C'est ce problème que nous avons résolu avec l'architecture HBT (Hierarchical Brain Task), inspirée des travaux récents sur les systèmes multi-agents hiérarchiques. Résultat : 98% de réduction des tokens et 99,9% de réduction des coûts.

Voici comment.

L'architecture HBT : 3 couches, 3 responsabilités

L'architecture HBT repose sur un principe simple : la séparation des responsabilités. Au lieu d'un seul agent qui fait tout (et mal), nous décomposons chaque requête en trois couches :

Couche 1 : Planning (Stratégie)

Rôle : Comprendre la requête utilisateur et la décomposer en sous-tâches atomiques.

LLM utilisé : Claude Sonnet 4 ou GPT-4o (modèles les plus puissants)

Exemple :

Contexte chargé : ~5 000 tokens (instructions + historique, sans aucun outil MCP)

Couche 2 : Orchestration (Coordination)

Rôle : Router chaque sous-tâche vers le bon agent spécialisé, gérer les dépendances et optimiser l'ordre d'exécution.

LLM utilisé : GPT-4o, Claude Sonnet 4, ou Gemini 1.5 Pro selon la complexité

Exemple :

Contexte chargé : ~3 000 tokens (plan + état d'exécution)

Couche 3 : Execution (Action)

Rôle : Agents spécialisés qui exécutent les tâches. Chaque agent a accès à un seul service MCP (isolation du contexte) et parfois même 1 seul Tools du MCP.

LLMs utilisés : Arbitrage automatique via notre proxy multi-LLM (Llama 3.1, Mistral, GPT-4o-mini, Claude Haiku...)

Exemple :

Contexte chargé par agent : ~8 000 tokens maximum

Innovation #1 : L'isolation du contexte

Le problème du "single agent" classique :

# ❌ Approche naïve : Tout charger
agent = Agent(
    tools=[
        GoogleAdsTool(),
        MetaAdsTool(),
        NotionTool(),
        SupabaseTool(),
        FigmaTool(),
        XeroTool(),
        GoogleAnalyticsTool(),
        # ... 15 outils avec leurs schémas complets
    ]
)
# Contexte : 50 000 tokens avant même de commencer

Notre approche avec HBT :

# ✅ Isolation : Chaque agent n'a qu'un seul outil
google_ads_agent = SpecializedAgent(
    tools=[GoogleAdsTool()]  # Contexte : 8 000 tokens
)

meta_ads_agent = SpecializedAgent(
    tools=[MetaAdsTool()]  # Contexte : 8 000 tokens
)

# L'orchestrateur appelle séquentiellement
results = orchestrator.coordinate([
    google_ads_agent.execute(task1),
    meta_ads_agent.execute(task2)
])

Résultat : Chaque agent opère avec 84% moins de contexte, ce qui améliore :

• La précision : Moins de confusion entre les APIs

• La vitesse : Moins de tokens = moins de latence

• Le coût : Seuls les agents nécessaires sont appelés

Innovation #2 : Le proxy multi-LLM intelligent

Toutes les tâches ne nécessitent pas un Claude Sonnet 4 à 15$ / million de tokens. C'est pourquoi nous avons développé un proxy multi-LLM basé sur LiteLLM avec des couches d'arbitrage custom.

Critères de routage automatique

Exemple de décision

# Orchestrateur reçoit une tâche
task = "Extract Google Ads metrics for last 30 days"

# Le proxy analyse la complexité
if task.requires_reasoning():
    model = "claude-sonnet-4"
elif task.is_structured_extraction():
    model = "llama-3.1-70b-local"  # Gratuit, rapide
elif task.needs_math():
    model = "mistral-large-2"
else:
    model = "gpt-4o-mini"  # Par défaut économique

response = await proxy.complete(model, task)

Nous avons accès à des centaines de modèles (via LiteLLM) : OpenAI, Anthropic, Google Gemini, Mistral, Llama, Qwen, DeepSeek, et même des modèles locaux hébergés sur nos serveurs Railway.

Cette stratégie d'arbitrage représente à elle seule 60% de nos économies de coûts.

Innovation #3 : Code Execution Layer

Le dernier problème à résoudre : les réponses MCP volumineuses.

Quand vous interrogez l'API Google Ads pour récupérer 100 campagnes avec leurs métriques, le serveur MCP vous renvoie un JSON de ~180 000 tokens ce qui signifie : Saturation du contexte + Perte d’intelligence + Risque d’hallucination très élevé (et risque d’erreur également) :

{
  "campaigns": [
    {
      "id": "12345",
      "name": "Campaign A",
      "metrics": {
        "impressions": 150000,
        "clicks": 3200,
        "cost": 4500.50,
        "conversions": 45,
        "ctr": 2.13,
        "cpc": 1.41,
        "roas": 3.2,
        // ... 50 autres métriques
      },
      "segments": { /* ... */ },
      "targeting": { /* ... */ }
    },
    // ... x100 campagnes
  ]
}

Si vous renvoyez ce JSON brut au LLM pour qu'il l'analyse, vous explosez votre budget.

Notre solution : Génération de code Python

Au lieu de renvoyer les données au LLM, nous demandons à l'agent d'exécution de générer du code Python qui va analyser le JSON localement dans une sandbox isolée.

Avant (approche naïve) :

Après (code execution) :

# 1. L'agent génère ce code (1 000 tokens)
import pandas as pd

def analyze_campaigns(json_data):
    df = pd.DataFrame(json_data['campaigns'])

    # Calculs locaux
    top_5 = df.nlargest(5, 'roas')[['name', 'roas', 'cost', 'conversions']]
    avg_ctr = df['ctr'].mean()
    total_spend = df['cost'].sum()

    return {
        "top_campaigns": top_5.to_dict(),
        "metrics": {
            "average_ctr": round(avg_ctr, 2),
            "total_spend": round(total_spend, 2)
        }
    }

# 2. Exécution dans sandbox
result = execute_code(analyze_campaigns, mcp_response)

# 3. Résultat compact (500 tokens) renvoyé au LLM

Coût : ~0,01$ (génération du code) + 0,00$ (exécution) = 99% d'économie

Sécurité de l'exécution

Le code est exécuté dans une sandbox isolée avec :

• Timeout de 30 secondes

• Limitation mémoire (512 MB)

• Accès réseau désactivé

• Packages autorisés : pandas, numpy, matplotlib, seaborn

• Validation statique du code avant exécution (AST parsing)

Nous utilisons une architecture containerisée sur Railway avec des workers éphémères qui se détruisent après chaque exécution.

Métriques : Les chiffres qui comptent

Voici nos résultats sur 1 000 requêtes réelles d'utilisateurs beta (agences marketing) sur une période de 30 jours :

Réduction des tokens

Décomposition des économies

Scalabilité

• 15 services MCP connectés sans dégradation de performance

• Temps de réponse constant même avec 30+ outils (vs +200% avec single agent)

• Coût linéaire : Chaque nouveau service MCP ajoute ~0,001$ par requête (vs +0,15$ avec single agent)

Stack technique 100% open source

Nous croyons fermement à l'open source. Voici notre stack complète :

Frontend (Swift/SwiftUI)

• Swift 5.9 : Langage natif macOS/iOS

• SwiftData : Persistance locale (Core Data moderne)

• Combine : Programmation réactive

Backend (Node.js + Python)

• Express.js : API Gateway HTTP

• FastAPI : Serveurs MCP Python

• Node.js : Serveurs MCP JavaScript

• Railway : Plateforme de déploiement

Orchestration

• LiteLLM : Proxy multi-LLM (fork avec custom routing)

• MCP Protocol : Standard Anthropic pour connecter les outils

• Docker : Containerisation des workers

Storage & Auth

• Supabase : Base de données PostgreSQL + Auth

• Redis : Cache distribué pour les réponses MCP

• Keychain : Stockage sécurisé des clés API (macOS)

Monitoring

• OpenTelemetry : Observabilité distribuée

• Prometheus : Métriques

• Grafana : Dashboards

Exceptions propriétaires : Les LLMs eux-mêmes (Claude, GPT-4, Gemini) ne sont pas open source, mais tous les modèles locaux que nous utilisons le sont (Llama 3.1, Mistral, Qwen).

Limitations et pistes d'amélioration

L'architecture HBT n'est pas parfaite. Voici nos challenges actuels :

1. Latence de coordination

Chaque couche ajoute ~500ms de latence. Pour des requêtes ultra-simples ("Quel est mon budget Google Ads ?"), le single agent reste plus rapide.

Solution explorée : Détection heuristique des requêtes simples pour bypass direct.

2. Code execution pas toujours optimal

Les 65% de réduction avec code execution sont une moyenne. Pour certains cas (petites réponses MCP < 2 000 tokens), générer du code coûte plus cher que de traiter directement.

Solution explorée : Seuil dynamique (si réponse < 2 000 tokens → traitement direct, sinon → code execution).

3. Debugging complexe

Avec 3 couches et plusieurs agents, tracer un bug devient difficile. Nous investissons massivement dans l'observabilité.

Solution en cours : Dashboard temps réel avec visualisation du flow HBT (OpenTelemetry + Grafana).

Le futur : Vers l'autonomie complète. Notre vision à 12 mois.

Q1 2025 : Mémoire contextuelle long-terme

• RAG (Retrieval-Augmented Generation) sur l'historique des projets

• Les agents apprennent des erreurs passées

• Réutilisation automatique des scripts Python validés

Q2 2025 : Agents self-improving

• Les agents génèrent leurs propres prompts optimisés

• A/B testing automatique des stratégies de planification

• Fine-tuning des modèles locaux sur nos cas d'usage

Q3 2025 : Multi-tenancy et collaboration

• Plusieurs utilisateurs peuvent interroger le même projet

• Agents collaboratifs (plusieurs humains + plusieurs agents)

• Audit trail complet des décisions d'agents

Q4 2025 : Open source complet

• Publication du core HBT sous licence Apache 2.0

• Marketplace de "skills" (agents spécialisés contributés par la communauté)

• SDK pour créer ses propres couches d'orchestration

Conclusion : L'intelligence n'est pas dans le modèle, mais dans l'architecture

La course aux LLMs toujours plus gros (GPT-5, Claude Opus 5...) nous fait oublier l'essentiel : l'architecture compte plus que le modèle.

Avec HBT, nous avons prouvé qu'un Llama 3.1 70B bien orchestré peut surpasser un Claude Sonnet 4 mal utilisé, tout en coûtant 100x moins cher.

Les vrais gains ne viendront pas de modèles plus puissants, mais de systèmes plus intelligents qui savent :

1. Quand utiliser quel modèle

2. Comment isoler les contextes

3. Pourquoi générer du code plutôt que traiter des données

Bumps Brain n'est pas un "wrapper autour de ChatGPT". C'est un système de coordination multi-agents pensé pour la scalabilité, l'efficacité et le coût.

Et tout ça avec une stack 100% auditable et open source.