L'orchestrateur IA choisit l'infrastructure, pas juste le modèle¶

Resume¶

Un fondateur décrit son architecture d'agents orchestrateurs personnels ("Soulmates") capables de router le compute entre cloud providers (via OpenRouter), clés dédiées, et modèles locaux à la demande. L'architecture complète (diagramme fourni) : Soulmates → Routing intelligent → Cloud APIs | OpenRouter | Local compute → Orchestria (génère d'autres agents). La nouvelle brique : les Soulmates peuvent spin up des modèles locaux sur n'importe quelle machine connectée (auto-expansible). La thèse : le vrai différentiel n'est plus "quel modèle" mais "où, combien, pour combien".

Analyse critique¶

Ce qui est juste :

Le framing est solide. Le modèle-selection est en train de devenir une commodité — tous les providers convergent sur les mêmes benchmarks, les prix s'effondrent. L'avantage compétitif se déplace vers l'infrastructure décisionnelle : latence, coût/token, confidentialité, disponibilité. C'est exactement ce que LiteLLM, OpenRouter, et les frameworks d'orchestration font déjà au niveau plateforme.

L'idée du "MacBook dormant = compute pool" est concrète et immédiatement actionnable avec Ollama. Pas de magie : c'est une API Ollama exposée sur le réseau local + un routeur qui sait quand l'utiliser.

Ce qui est exagéré :

"La vraie révolution" — c'est plus une évolution logique qu'une révolution. Le compute routing existe en prod chez AWS (Bedrock), Google (Vertex AI routing), et dans les frameworks OSS depuis 2023. Ce qui est nouveau ici c'est l'application au niveau personnel/équipe (<10 machines) avec un agent orchestrateur qui prend la décision de manière autonome.

Le naming "Soulmates" est du personal branding fondateur — ça n'ajoute rien à l'analyse technique.

Ce que le diagramme révèle que le texte cache — Orchestria :

C'est le détail le plus intéressant et le plus absent du post. Le diagramme montre un composant Orchestria ("génère d'autres agents") connecté en boucle depuis le Local compute. Ce n'est plus seulement "l'AI choisit où tourner" — c'est "l'AI peut spawner de nouveaux agents sur le compute qu'elle vient de mobiliser". C'est le pattern agentic mesh auto-réplicant : l'orchestrateur crée du compute, y installe des agents, ces agents créent d'autres agents.

C'est architecturalement plus ambitieux que le texte ne le laisse entendre. Et c'est aussi là que ça peut déraper — la gouvernance de "qui a le droit de spawner quoi" n'est pas mentionnée du tout.

Ce qui manque :

Zéro détail sur la politique de routing (quels signaux déclenchent local vs cloud) et zéro mention des guardrails sur Orchestria. Un orchestrateur qui génère des agents sans politique de spawn explicite, c'est la recette du runaway cost ou des actions non supervisées.

Verdict : veille. Le post est plus modeste que l'architecture. Orchestria change le niveau d'ambition — à surveiller.

Pertinence ProbatioVault¶

ProbatioVault fait déjà exactement ça, en moins formalisé :

Ce qui manque et que le post pointe indirectement : formaliser la politique de routing comme un artefact de gouvernance. Aujourd'hui le choix est implicite dans les skills. Le rendre explicite (coût/token seuil, RGPD flag, latence max) serait une amélioration.

Parallèle direct avec la gouvernance ProbatioVault : le pattern Orchestria (agent qui génère d'autres agents) existe déjà dans le workflow — étape 6b lance jusqu'à 17 agents en séquence, chacun spawné par l'orchestrateur Claude. La différence : ProbatioVault a des guardrails constitutionnels explicites (CONSTITUTIONAL.md, Article VI). Le projet "Soulmates" n'a apparemment rien de comparable — aucun mécanisme de supervision des agents spawné par Orchestria n'est visible.

Action immédiate possible : le MacBook peut être ajouté au pool Ollama (OLLAMA_HOST=0.0.0.0) comme overflow compute pour l'IA-Server sur les gros modèles (Llama 3.3 70B).