L'Orchestrateur : Pourquoi l'intention devrait survivre au processus

Les piles d'agents actuelles sont inversées. La surface (terminal, éditeur) possède le modèle, les outils et l'historique, tandis que l'identité est éphémère — ouvrez un nouveau terminal et l'agent disparaît. L'auteur propose une couche d'orchestrateur qui dissocie l'intention de tout processus unique. Propriétés clés :

• Identité au-dessus des sessions : Un agent logique persiste à travers les processus. Les sessions vont et viennent ; l'agent reste.
• Routage entre surfaces : L'agent distribue le travail à différentes machines (par exemple, boîte repo, boîte GPU, téléphone) sans les traiter comme non liées.
• Primitive de transfert réelle : Un objet typé transportant ce qui a été fait, ce qui est inachevé, les décisions bloquées — pas un historique de chat dégradé.
• Agents pairs, pas sous-agents : Deux agents dans des contextes différents coordonnent via un plan de contrôle qu'aucun ne possède.
• Appels inter-pilotes : « Modèle bon marché résume, modèle coûteux agit » est une primitive, pas de l'ingénierie de prompt. L'orchestrateur choisit le runtime par étape en fonction du coût, de la latence, des capacités.
• Surfaces d'approbation qui survivent : Si l'agent fait une pause pour approbation et que vous êtes à trois fuseaux horaires de distance, l'approbation vous parvient sans garder l'agent en vie.

Exemple concret : Trier un test instable

Aujourd'hui, vous ouvrez trois terminaux et collez des traces de pile entre Claude, Gemini et Grok. Le flux souhaité par l'auteur sous une seule intention d'orchestrateur : « Trier cette instabilité, proposer un correctif, le faire réviser. »

• Ollama (local) : Ingérer le journal de test, supprimer le bruit, produire un résumé structuré de l'échec. Gratuit, ne quitte jamais la machine.
• Gemini CLI : Prendre le résumé plus le dépôt, identifier le changement suspect, rédiger un patch. Grand contexte, fort pour lire le code, accès en lecture seule au dépôt.
• Grok Build : Prendre le patch et l'échec original, rendre un verdict (livrer/réviser/remonter). Une autre famille de modèles comme second avis. Pas d'accès en écriture.

Trois runtimes, trois périmètres d'autorisation, trois niveaux de coût, une seule intention. L'orchestrateur transporte l'objet de transfert entre les étapes et présente une seule approbation au lieu de trois conversations déconnectées. Si Grok dit « remonter », l'intention fait une pause et attend une décision humaine — sans garder Ollama ou Gemini en vie.

Depuis la semaine dernière, au moins trois agents de codage natifs au terminal s'exécutent localement : le runtime Ollama, Gemini CLI de Google et Grok Build de xAI avec mode plan et sous-agents parallèles. Le modèle est la partie bon marché et remplaçable. L'orchestrateur devrait être la partie ennuyeuse et durable.