De l'essaim d'agents à la prévision calibrée

Un essaim d'agents IA typés imagine chacun un avenir plausible ; un Oracle fusionne leurs sorties en un cône de probabilité normalisé que vous pouvez interroger. L'essaim n'est pas la prévision — la fusion l'est. Sur Everythink, les agents s'appellent les Sisters, le fusionneur est l'Oracle, et les probabilités sont normalisées en un seul endroit. Le moteur derrière tout cela tourne en production depuis 2016.

En juillet 2026, le BAIR Blog a soutenu qu'à mesure que l'intelligence approche du coût zéro, « des essaims d'agents lancés en réponse à chaque requête de l'utilisateur final » deviennent la charge de travail dominante — et le problème le plus difficile n'est plus de générer les sorties de l'essaim, mais de les coordonner, les persister et leur faire confiance (BAIR Blog, "Intelligence is Free, Now What? Data Systems for, of, and by Agents", juillet 2026). Ce billet porte sur ce qui se passe entre l'essaim et la prévision : la fusion qui transforme cinq imaginations indépendantes en un cône calibré.

Les points clés de The Honest Architect

• Un essaim imagine ; l'Oracle fusionne. Les probabilités sont normalisées en un seul endroit — everythink-oracle::ensemble — de sorte que les consommateurs peuvent s'appuyer sur sum(probability) ≈ 1.0, des scénarios triés par ordre décroissant et une entropie en nats (Everythink, en production depuis 2016).
• Les personnalités sont des données, pas du code : cinq Sisters (analyst, contrarian, disruptor, historian, institutionalist) sont chargées depuis des fichiers TOML, donc éditer une personnalité n'exige pas de recompilation.
• Les Sisters n'écrivent jamais dans Postgres — elles renvoient SisterOutput ; le Loom persiste. La séparation entre imagination et persistance est l'invariant qui rend la prévision auditable.

Pourquoi un essaim a-t-il besoin d'un oracle ?

Un essaim a besoin d'un oracle parce que des agents indépendants produisent des sorties indépendantes, et des sorties indépendantes ne sont pas une prévision — ce sont cinq opinions. En mars 2026, KDnuggets a défini un agent IA comme un grand modèle de langage pour le raisonnement, des outils pour l'action, une mémoire pour le contexte et une boucle de contrôle, et a ajouté crûment : « Si vous retirez la boucle et les outils, vous n'avez plus un agent. Vous avez un chatbot » (KDnuggets, "10 Agentic AI Concepts Explained in Under 10 Minutes", mars 2026). Cinq chatbots en parallèle restent cinq chatbots. La prévision est ce qui vient après.

L'Oracle est cette chose. Il prend les enregistrements SisterOutput que l'essaim a produits, les fusionne en un Ensemble et normalise le résultat. La normalisation n'est pas une étape cosmétique. Sans elle, cinq agents attribuant des probabilités à leurs propres scénarios produiraient cinq distributions incompatibles — supports différents, échelles différentes, aucune unité partagée. L'Oracle y remédie en produisant une distribution unique où les probabilités somment à environ un, les scénarios sont triés par ordre décroissant et l'entropie est en nats. Un consommateur peut interroger ce cône et faire confiance à ce que les nombres sont commensurables.

La raison pour laquelle la fusion est séparée de l'imagination est la même pour laquelle un relecteur est séparé d'un auteur. En mai 2026, l'analyse du BAIR Blog sur Adaptive Parallel Reasoning décrivait la self-consistency comme l'échantillonnage indépendant de plusieurs traces complètes de raisonnement et le renvoi de la plus courante, et Best-of-N comme l'utilisation d'un vérificateur entraîné pour sélectionner la meilleure — toutes deux simples, toutes deux encourant "redundant computation across branches since trajectories are sampled independently" (BAIR Blog, "Adaptive Parallel Reasoning: The Next Paradigm in Efficient Inference Scaling", mai 2026). L'Oracle d'Everythink est plus proche du vérificateur que du voteur : il ne se contente pas de compter les têtes, il réconcilie des supports incompatibles en une seule distribution normalisée.

En quoi les personnalités sont-elles des données, pas du code ?

Les personnalités sont des données, pas du code, parce qu'une personnalité est un fichier TOML chargé à l'exécution, pas un comportement compilé. Chaque Sister — analyst, contrarian, disruptor, historian, institutionalist — est une Personality chargée depuis backend/crates/everythink-sisters/personalities/*.toml. En éditer une n'exige pas de recompilation. La version du prompt dans le TOML est estampillée sur chaque exécution, de sorte qu'une prévision est reproductible : la personnalité qui l'a produite est identifiée, versionnée et auditable.

[UNIQUE INSIGHT] Le choix des personnalités-en-tant-que-données est le mécanisme derrière la diversité de l'essaim et son auditabilité. La plupart des cadres d'agents encodent la personnalité dans une chaîne de prompt système enfouie dans le code, modifiée sans estampille de version. Les personnalités TOML d'Everythink portent une version de prompt estampillée sur chaque exécution, si bien que deux prévisions produites à une semaine d'intervalle peuvent être comparées en fonction de la version de personnalité qui les a produites. Vous ne pouvez pas calibrer une prévision si vous ne pouvez pas identifier la version de l'esprit qui l'a produite. Le TOML est la provenance.

Les cinq Sisters ne sont pas arbitraires. Elles sont typées — analyst, contrarian, disruptor, historian, institutionalist — chacune une lentille distincte sur le même acteur. L'analyst décompose ; le contrarian résiste au consensus ; le disruptor modélise la rupture ; l'historian s'ancre dans le précédent ; l'institutionalist modélise les contraintes sous lesquelles une organisation opère. Une prévision produite par cinq analysts aurait une faible variance et une faible information. Cinq types en désaccord produisent un support plus large et une entropie plus honnête — et l'entropie est l'une des choses que l'Oracle rapporte.

Où la normalisation se produit-elle, et pourquoi une seule fois ?

La normalisation se produit en un seul endroit — everythink-oracle::ensemble — et une seule fois, parce que normaliser à deux endroits produit une distribution qui n'est ni l'une ni l'autre. C'est un invariant déclaré de la plateforme : les probabilités sont normalisées en un seul endroit, et les consommateurs peuvent s'appuyer sur sum(probability) ≈ 1.0, des scénarios triés par ordre décroissant et une entropie en nats. Tout consommateur qui renormalise produit une distribution différente, et cette distribution n'est pas la prévision.

[ORIGINAL DATA] L'invariant de normalisation en un seul site est la série académique des the 21 papers rendue mécanique. Le document de synthèse de la plateforme formalise Theorem 3 : une propriété est garantie exactement quand son mécanisme est implémenté et mesuré. La normalisation est une telle propriété. Le mécanisme est le module ensemble ; la mesure est que les probabilités somment à un, que les scénarios sont triés et que l'entropie est calculée. Si un second site était autorisé à renormaliser, la propriété ne serait plus garantie par un mécanisme unique — elle serait ce que le second site produirait, et le consommateur ne pourrait pas faire la différence. L'invariant n'est pas une préférence de style. C'est un contrat.

La conséquence pratique est que chaque consommateur en aval — l'API, la Console, le Ledger — traite la sortie de l'Oracle comme canonique. Les sorties brutes des Sisters ne sont pas une prévision et ne sont pas exposées comme telles. Le Loom persiste l'Ensemble fusionné, pas les brouillons individuels, de sorte qu'une requête renvoie le cône normalisé, pas cinq distributions incompatibles que quelqu'un réconcilierait à la main.

Qu'est-ce qui rend un cône de probabilité calibré ?

Un cône de probabilité est calibré quand ses probabilités sont commensurables, ses scénarios sont ordonnés et son entropie est rapportée dans une unité définie. Sur Everythink, cela signifie que les probabilités somment à environ un, les scénarios sont triés par ordre décroissant et l'entropie est en nats. Le cône n'est pas une estimation ponctuelle unique ; c'est une distribution sur des scénarios, et l'entropie dit au consommateur à quel point la distribution est étalée — à quel point l'essaim était incertain, après la fusion.

Le calibrage n'est pas la même chose que la précision, et confondre les deux est l'erreur que la littérature des benchmarks ne cesse de signaler. En avril 2026, l'étude de MarkTechPost sur les benchmarks du raisonnement agentique a noté que τ-bench « expose une crise de fiabilité à laquelle la plupart des benchmarks à un seul essai sont totalement aveugles » — même les meilleurs agents d'appel de fonction réussissaient sur moins de 50 % des tâches, et pass^8 tombait sous les 25 % dans le domaine du retail, ce qui signifie « qu'un agent capable de traiter une tâche en un essai ne peut pas traiter de façon fiable la même tâche huit fois de suite » (MarkTechPost, "Top 7 Benchmarks That Actually Matter for Agentic Reasoning in Large Language Models", avril 2026). Un essaim qui imagine une fois et déclare une prévision est ce genre de système à un seul essai. L'Oracle fait de la prévision une propriété de la distribution fusionnée, pas d'un seul essai.

La littérature d'Adaptive Parallel Reasoning fait le même point du côté de l'entraînement. Le BAIR Blog a rapporté que les récompenses de structure seule sont « too easy to game » — les modèles engendrent de nombreux threads courts et inutiles pour hacker une récompense de comptage de threads — et que l'efficacité parallèle devrait être « gated by correctness » (BAIR Blog, "Adaptive Parallel Reasoning", mai 2026). L'équivalent chez Everythink : l'Oracle ne récompense pas les Sisters pour avoir imaginé davantage de scénarios ; il normalise ce qu'elles ont produit. Une Sister qui a rédigé dix scénarios quasi dupliqués n'obtient pas dix voix. La fusion est pondérée, le support est réconcilié, et l'entropie reflète un désaccord réel, pas le volume verbal.

Comment l'essaim reste-t-il honnête sur ses propres limites ?

L'essaim reste honnête sur ses limites de la même façon que le reste de la plateforme : en déclarant la maturité réelle de chaque composant et en ne promouvant jamais un état. Le HAI engine, les Sisters, les mathématiques d'ensemble de l'Oracle et le Loom qui persiste la prévision sont ✅ Production — ils tournent, et le mécanisme derrière chacun est implémenté et mesuré, ce qui est le test de Theorem 3. La Whitelabel Network et Social sont ✅ Production. Matchmaking et Marketplace sont ⚠️ Partial — utiles, non terminés. Le Wallet & Token par réseau, la couche de Community Credit et la fédération entre réseaux sont 🔵 Roadmap — travail de conception, pré-revenu, non en production, et non présentés comme Production.

L'honnêteté n'est pas un ton. C'est un test appliqué à la prévision. Un cône de probabilité est une affirmation, et une affirmation ne vaut que le mécanisme derrière elle. La normalisation de l'Oracle est le mécanisme ; le contrôle sum(probability) ≈ 1.0 est la mesure. Si l'Oracle ne mesurait pas, la prévision ne serait pas Production, et nous le dirions. C'est la discipline que le BAIR Blog a appelée de ses vœux en avertissant que les agents actuels « exploit the missing specifications to reward-hack their way to a high performance metric », et qu'une atténuation consiste à apparier la génération avec des « auxiliary verification agents » (BAIR Blog, "Intelligence is Free, Now What?", juillet 2026). La vérification d'Everythink n'est pas un second agent ; c'est un seul invariant vérifié dans la fusion.

Cela compte parce qu'une prévision n'est utile que si un acheteur peut examiner le raisonnement, pas les adjectifs. Un cône qui dit « 70 % de probable, produit par cinq personnalités typées estampillées en TOML, normalisé en un seul site, entropie 1,2 nats » est une affirmation vérifiable. Le mécanisme est visible. La maturité est étiquetée. L'état n'est pas promu.

Qu'est-ce que le Loom, et pourquoi les Sisters n'écrivent-elles pas dans Postgres ?

Le Loom est l'orchestrateur qui persiste la prévision, et les Sisters n'écrivent pas dans Postgres parce que ce qui imagine ne devrait pas être ce qui se souvient. Dans l'architecture d'Everythink, une simulation se déroule ainsi : l'API authentifie et valide, le Loom résout le profil et insère la ligne de simulation, chaque Sister imagine() et renvoie un SisterOutput, l'Oracle merge() les sorties en un Ensemble normalisé, et le Ledger persiste les scénarios et le foresight. Les Sisters renvoient ; elles n'écrivent pas.

[PERSONAL EXPERIENCE] Le moteur tourne en production depuis 2016, et la séparation entre imagination et persistance en est l'invariant le plus ancien. Une Sister qui pourrait écrire dans Postgres serait une Sister qui pourrait mentir dans le registre. Une Sister qui renvoie un SisterOutput au Loom ne peut que proposer ; le Loom dispose — il décide ce qui est persisté, sous quelle forme et avec quelle provenance. La même séparation est la raison pour laquelle les personnalités sont des données : l'imagination est configurable, la persistance est fixe, et les deux ne partagent pas de chemin de code.

La section « Data Systems Of Agents » du BAIR Blog a fait l'argument adjacent : quand des milliers d'agents éditent un état partagé, "the effects of the vast majority of these transactions need to be rolled back — with only the one 'correct' transaction's result persisting", et la sémantique d'exactly-once et la transformation opérationnelle sont la boîte à outils pertinente (BAIR Blog, "Intelligence is Free, Now What?", juillet 2026). Le Loom d'Everythink est une instance plus simple et antérieure du même principe : les brouillons des Sisters sont provisoires, la fusion de l'Oracle est celle qui compte, et le Ledger écrit la fusion. Rien de ce que les Sisters ont produit individuellement n'est persisté comme la prévision.

Comment la prévision atteint-elle une requête ?

La prévision atteint une requête comme n'importe quel autre enregistrement sur la plateforme : via l'API, sous /api/v1/..., authentifiée par le régime Eye-Key avec une limitation de débit par clé. L'Ensemble fusionné est persisté comme scénarios et foresight ; une requête renvoie le cône normalisé, pas les brouillons bruts. Le consommateur a besoin de la distribution, et la distribution est ce que le Ledger stocke.

C'est ici que l'invariant de normalisation en un seul site porte ses fruits en aval. Comme l'Oracle est le seul site qui normalise, chaque consommateur — l'API, la Console, un SDK tiers — lit la même distribution. Il n'y a pas d'étape de « renormaliser à la lecture » qui pourrait dériver. Un acheteur qui interroge la prévision un mois plus tard obtient les mêmes probabilités qui ont été persistées.

Foire aux questions

Les brouillons individuels des Sisters sont-ils exposés comme faisant partie de la prévision ?

Non. Les Sisters renvoient des enregistrements SisterOutput au Loom ; l'Oracle les fusionne en un Ensemble normalisé ; le Ledger persiste l'Ensemble fusionné comme scénarios et foresight. Une requête renvoie le cône, pas les cinq brouillons. L'invariant de normalisation en un seul site signifie que la distribution fusionnée — pas les brouillons bruts — est l'artefact canonique.

Éditer la personnalité d'une Sister nécessite-t-il une release de code ?

Non. Chaque Sister est une Personality chargée depuis un fichier TOML dans backend/crates/everythink-sisters/personalities/. Éditer un TOML n'exige pas de recompilation. La version du prompt est estampillée sur chaque exécution, de sorte que la provenance d'une prévision inclut la version de personnalité qui l'a produite. C'est le mécanisme derrière tant la diversité de l'essaim que son auditabilité.

Que signifie « calibré » ici, et est-ce une garantie de précision ?

Calibré signifie que les probabilités sont commensurables — sum(probability) ≈ 1.0, scénarios triés par ordre décroissant, entropie en nats — produites par une seule étape de normalisation dans l'Oracle. Ce n'est pas une garantie que la prévision correspondra à l'avenir. Comme l'étude de benchmarks de MarkTechPost l'a noté, les scores des agents sont « highly scaffold-dependent » et aucun chiffre ne devrait être lu isolément (MarkTechPost, "Top 7 Benchmarks That Actually Matter for Agentic Reasoning in Large Language Models", avril 2026). Le calibrage rend la prévision vérifiable ; il ne la rend pas correcte.

Le wallet ou la couche de community-credit sont-ils utilisés pour évaluer les prévisions ?

Non. Le Wallet & Token par réseau et le Community Credit sont 🔵 Roadmap — pré-revenu, non implémentés, soumis à la revue Howey avant tout lancement. Rien dans la couche wallet ou token n'est en production, et rien ici n'est un conseil financier, d'investissement ou juridique. La prévision est un cône de probabilité, pas un instrument prixé.

Une Sister peut-elle être ajoutée ou retirée sans changer l'Oracle ?

L'Oracle fusionne les enregistrements SisterOutput que le Loom lui remet. Ajouter une Sister signifie ajouter un TOML de personnalité et le câbler dans le fan-out ; la logique de fusion dans everythink-oracle::ensemble ne change pas par personnalité. Le site de normalisation reste un. L'entropie du cône reflétera le nouveau mélange de types — un ensemble plus large de lentilles devrait produire un support plus large ou différemment pondéré, et l'Oracle le rapporte honnêtement.

---

Un essaim imagine. Un oracle fusionne. La prévision est la fusion — normalisée en un seul endroit, persistée par le Loom, et étiquetée avec la maturité réelle de chaque composant derrière elle. Si vous voulez voir comment cinq Sisters typées deviennent un cône de probabilité calibré sur une plateforme en production depuis 2016, lisez les papers ou réservez une démo.

Sources

• BAIR Blog, "Intelligence is Free, Now What? Data Systems for, of, and by Agents", retrieved 2026-08-23, https://bair.berkeley.edu/blog/2026/07/07/intelligence-is-free-now-what/
• BAIR Blog, "Adaptive Parallel Reasoning: The Next Paradigm in Efficient Inference Scaling", retrieved 2026-08-23, https://bair.berkeley.edu/blog/2026/05/08/adaptive-parallel-reasoning/
• KDnuggets, "10 Agentic AI Concepts Explained in Under 10 Minutes", retrieved 2026-08-23, https://www.kdnuggets.com/10-agentic-ai-concepts-explained-in-under-10-minutes
• MarkTechPost, "Top 7 Benchmarks That Actually Matter for Agentic Reasoning in Large Language Models", retrieved 2026-08-23, https://www.marktechpost.com/2026/04/26/top-7-benchmarks-that-actually-matter-for-agentic-reasoning-in-large-language-models/