Vom Agenten-Schwarm zur kalibrierten Prognose

Ein Schwarm typisierter KI-Agenten imaginiert je eine plausible Zukunft; ein Oracle führt ihre Ausgaben zu einem normalisierten Wahrscheinlichkeitskegel zusammen, den Sie abfragen können. Der Schwarm ist nicht die Prognose — der Merge ist es. Auf Everythink heißen die Agenten Sisters, der Merger ist das Oracle, und die Wahrscheinlichkeiten werden an genau einer Stelle normalisiert. Die Maschine dahinter läuft seit 2016 in Produktion.

Im Juli 2026 argumentierte der BAIR Blog, dass mit gegen null gehenden Kosten für Intelligenz „Schwärme von Agenten, die als Antwort auf jede Endbenutzer-Anfrage hochgefahren werden" zur dominierenden Workload werden — und das schwierigere Problem nicht mehr das Erzeugen der Schwarm-Ausgaben ist, sondern deren Koordination, Persistierung und Vertrauenswürdigkeit (BAIR Blog, "Intelligence is Free, Now What? Data Systems for, of, and by Agents", Juli 2026). Dieser Beitrag handelt von dem, was zwischen Schwarm und Prognose passiert: dem Merge, der fünf unabhängige Imaginationen in einen kalibrierten Kegel verwandelt.

The Honest Architects Kernpunkte

• Ein Schwarm imaginiert; das Oracle merged. Wahrscheinlichkeiten werden an genau einer Stelle normalisiert — everythink-oracle::ensemble — sodass Konsumenten sich auf sum(probability) ≈ 1.0, absteigend sortierte Szenarien und Entropie in nats verlassen können (Everythink, seit 2016 in Produktion).
• Persönlichkeiten sind Daten, kein Code: fünf Sisters (analyst, contrarian, disruptor, historian, institutionalist) werden aus TOML-Dateien geladen, daher erfordert das Bearbeiten einer Persönlichkeit kein Rekompilieren.
• Sisters schreiben nie nach Postgres — sie geben SisterOutput zurück; der Loom persistiert. Die Trennung von Imagination und Persistenz ist die Invariante, die die Prognose auditierbar macht.

Warum braucht ein Schwarm ein Orakel?

Ein Schwarm braucht ein Orakel, weil unabhängige Agenten unabhängige Ausgaben erzeugen, und unabhängige Ausgaben keine Prognose sind — sie sind fünf Meinungen. Im März 2026 definierte KDnuggets einen KI-Agenten als ein großes Sprachmodell für Reasoning, Werkzeuge für Aktion, Gedächtnis für Kontext und eine Kontrollschleife und fügte schlicht hinzu: „Wenn Sie die Schleife und die Werkzeuge entfernen, haben Sie keinen Agenten mehr. Sie haben einen Chatbot" (KDnuggets, "10 Agentic AI Concepts Explained in Under 10 Minutes", März 2026). Fünf Chatbots parallel sind immer noch fünf Chatbots. Die Prognose ist das, was danach kommt.

Das Oracle ist genau das. Es nimmt die SisterOutput-Datensätze, die der Schwarm erzeugt hat, merged sie zu einem Ensemble und normalisiert das Ergebnis. Normalisierung ist kein kosmetischer Schritt. Ohne sie würden fünf Agenten, die ihren eigenen Szenarien Wahrscheinlichkeiten zuweisen, fünf inkompatible Verteilungen erzeugen — verschiedene Träger, verschiedene Skalen, keine gemeinsame Einheit. Das Oracle löst das, indem es eine einzige Verteilung erzeugt, in der die Wahrscheinlichkeiten sich auf etwa eins summieren, die Szenarien absteigend sortiert sind und die Entropie in nats angegeben wird. Ein Konsument kann diesen Kegel abfragen und darauf vertrauen, dass die Zahlen vergleichbar sind.

Dass der Merge von der Imagination getrennt ist, hat denselben Grund wie die Trennung von Gutachter und Autor. Im Mai 2026 beschrieb die Analyse des BAIR Blog zu Adaptive Parallel Reasoning Self-Consistency als unabhängiges Ziehen mehrerer vollständiger Reasoning-Traces und Rückgabe des häufigsten, und Best-of-N als Einsatz eines trainierten Verifikators zur Auswahl des besten — beide einfach, beide mit "redundant computation across branches since trajectories are sampled independently" (BAIR Blog, "Adaptive Parallel Reasoning: The Next Paradigm in Efficient Inference Scaling", Mai 2026). Everythinks Oracle ist näher am Verifikator als am Wähler: Es zählt nicht nur Köpfe, es versöhnt inkompatible Träger zu einer einzigen normalisierten Verteilung.

Wie sind Persönlichkeiten Daten und kein Code?

Persönlichkeiten sind Daten, kein Code, weil eine Persönlichkeit eine zur Laufzeit geladene TOML-Datei ist, kein kompiliertes Verhalten. Jede Sister — analyst, contrarian, disruptor, historian, institutionalist — ist eine Personality, geladen aus backend/crates/everythink-sisters/personalities/*.toml. Eine zu bearbeiten erfordert kein Rekompilieren. Die Prompt-Version im TOML wird auf jeden Lauf gestempelt, sodass eine Prognose reproduzierbar ist: die Persönlichkeit, die sie erzeugt hat, ist identifiziert, versioniert und auditierbar.

[UNIQUE INSIGHT] Die Wahl „Persönlichkeiten als Daten" ist der Mechanismus hinter der Vielfalt des Schwarms und seiner Auditierbarkeit. Die meisten Agenten-Frameworks codieren Persönlichkeit in einem System-Prompt-String, der im Code vergraben ist und ohne Versionsstempel geändert wird. Everythinks TOML-Persönlichkeiten tragen eine Prompt-Version, die auf jeden Lauf gestempelt wird, sodass zwei eine Woche auseinander erzeugte Prognosen anhand der Persönlichkeitsversion verglichen werden können, die sie erzeugt hat. Man kann eine Prognose nicht kalibrieren, wenn man die Version des Geistes, der sie erzeugt hat, nicht identifizieren kann. Das TOML ist die Provenienz.

Die fünf Sisters sind nicht willkürlich. Sie sind typisiert — analyst, contrarian, disruptor, historian, institutionalist — jeweils eine eigene Linse auf denselben Akteur. Der analyst zerlegt; der contrarian widerstreitet dem Konsens; der disruptor modelliert den Bruch; der historian verankert im Präzedenzfall; der institutionalist modelliert die Zwänge, unter denen eine Organisation operiert. Eine Prognose von fünf analysts hätte geringe Varianz und geringen Informationsgehalt. Fünf Typen, die uneinig sind, erzeugen einen breiteren Träger und eine ehrlichere Entropie — und Entropie ist eines der Dinge, die das Oracle berichtet.

Wo findet die Normalisierung statt, und warum nur einmal?

Die Normalisierung findet an genau einer Stelle statt — everythink-oracle::ensemble — und nur einmal, weil an zwei Stellen zu normalisieren eine Verteilung erzeugt, die keine von beiden ist. Das ist eine erklärte Invariante der Plattform: Wahrscheinlichkeiten werden an genau einer Stelle normalisiert, und Konsumenten dürfen sich auf sum(probability) ≈ 1.0, absteigend sortierte Szenarien und Entropie in nats verlassen. Jeder Konsument, der renormalisiert, erzeugt eine andere Verteilung, und diese Verteilung ist nicht die Prognose.

[ORIGINAL DATA] Die Ein-Stellen-Normalisierungs-Invariante ist die akademische Reihe der the 21 papers in Mechanik gegossen. Das Übersichtspapier der Plattform formalisiert Theorem 3: Eine Eigenschaft wird genau dann garantiert, wenn ihr Mechanismus implementiert und gemessen ist. Normalisierung ist eine solche Eigenschaft. Der Mechanismus ist das Modul ensemble; die Messung ist, dass sich die Wahrscheinlichkeiten zu eins summieren, die Szenarien sortiert sind und die Entropie berechnet wird. Würde eine zweite Stelle renormalisieren dürfen, wäre die Eigenschaft nicht mehr durch einen einzigen Mechanismus garantiert — sie wäre, was die zweite Stelle erzeugt, und der Konsument könnte es nicht unterscheiden. Die Invariante ist keine Stilfrage. Sie ist ein Vertrag.

Die praktische Folge ist, dass jeder nachgelagerte Konsument — die API, die Console, der Ledger — die Ausgabe des Oracle als kanonisch behandelt. Die rohen Ausgaben der Sisters sind keine Prognose und werden als solche nicht freigegeben. Der Loom persistiert das gemergte Ensemble, nicht die einzelnen Entwürfe, sodass eine Abfrage den normalisierten Kegel zurückgibt, nicht fünf inkompatible Verteilungen, die jemand per Hand versöhnen müsste.

Was macht einen Wahrscheinlichkeitskegel kalibriert?

Ein Wahrscheinlichkeitskegel ist kalibriert, wenn seine Wahrscheinlichkeiten vergleichbar sind, seine Szenarien geordnet sind und seine Entropie in einer definierten Einheit angegeben wird. Auf Everythink bedeutet das: Wahrscheinlichkeiten summieren sich auf etwa eins, Szenarien sind absteigend sortiert, Entropie in nats. Der Kegel ist keine einzelne Punktschätzung; er ist eine Verteilung über Szenarien, und die Entropie sagt dem Konsumenten, wie breit die Verteilung gestreut ist — wie unsicher der Schwarm nach dem Merge war.

Kalibrierung ist nicht dasselbe wie Genauigkeit, und die Verwechslung der beiden ist der Fehler, den die Benchmark-Literatur immer wieder markiert. Im April 2026 stellte MarkTechPosts Übersicht zu Benchmarks für agentisches Reasoning fest, dass τ-bench „eine Zuverlässigkeitskrise aufdeckt, für die die meisten Ein-Schuss-Benchmarks völlig blind sind" — selbst die besten Function-Calling-Agenten succeeded on fewer than 50% der Aufgaben, und pass^8 fiel im Retail-Bereich unter 25 %, was bedeutet, dass „ein Agent, der eine Aufgabe in einem Versuch bewältigen kann, nicht zuverlässig dieselbe Aufgabe acht Mal hintereinander bewältigen kann" (MarkTechPost, "Top 7 Benchmarks That Actually Matter for Agentic Reasoning in Large Language Models", April 2026). Ein Schwarm, der einmal imaginiert und eine Prognose deklariert, ist diese Art Ein-Versuch-System. Das Oracle macht die Prognose zu einer Eigenschaft der gemergten Verteilung, nicht eines einzelnen Versuchs.

Die Literatur zu Adaptive Parallel Reasoning macht denselben Punkt von der Trainingsseite. Der BAIR Blog berichtete, dass reine Struktur-Belohnungen "too easy to game" sind — Modelle erzeugen viele kurze, nutzlose Threads, um eine Thread-Zähl-Belohnung zu hacken — und dass parallele Effizienz "gated by correctness" sein sollte (BAIR Blog, "Adaptive Parallel Reasoning", Mai 2026). Everythinks Äquivalent: Das Oracle belohnt die Sisters nicht dafür, mehr Szenarien zu imaginieren; es normalisiert, was sie erzeugt haben. Eine Sister, die zehn nahezu duplizierte Szenarien entwarf, bekommt keine zehn Stimmen. Der Merge ist gewichtet, der Träger ist versöhnt, und die Entropie spiegelt echte Uneinigkeit wider, nicht verbales Volumen.

Wie bleibt der Schwarm über seine eigenen Grenzen ehrlich?

Der Schwarm bleibt über seine Grenzen ehrlich, wie der Rest der Plattform auch: indem er den realen Reifegrad jeder Komponente angibt und niemals einen Status hochstuft. Das HAI engine, die Sisters, die Ensemble-Mathematik des Oracle und der Loom, der die Prognose persistiert, sind ✅ Production — sie laufen, und der Mechanismus hinter jedem ist implementiert und gemessen, was der Theorem-3-Test ist. Die Whitelabel Network und Social sind ✅ Production. Matchmaking und Marketplace sind ⚠️ Partial — nützlich, nicht fertig. Das netzwerkbezogene Wallet & Token, die Community-Credit-Schicht und die Föderation zwischen Netzwerken sind 🔵 Roadmap — Designarbeit, ohne Umsatz, nicht live und nicht als Production dargestellt.

Die Ehrlichkeit ist kein Ton. Sie ist ein Test, der auf die Prognose angewandt wird. Ein Wahrscheinlichkeitskegel ist eine Behauptung, und eine Behauptung taugt nur so viel wie der Mechanismus dahinter. Die Normalisierung des Oracle ist der Mechanismus; die sum(probability) ≈ 1.0-Prüfung ist die Messung. Würde das Oracle nicht messen, wäre die Prognose nicht Production, und wir würden es sagen. Das ist die Disziplin, die der BAIR Blog einforderte, als er warnte, heutige Agenten „exploit the missing specifications to reward-hack their way to a high performance metric", und eine Milderung sei, Generierung mit "auxiliary verification agents" zu paaren (BAIR Blog, "Intelligence is Free, Now What?", Juli 2026). Everythinks Verifikation ist kein zweiter Agent; es ist eine einzige, geprüfte Invariante im Merge.

Das zählt, weil eine Prognose nur nützlich ist, wenn ein Käufer das Reasoning prüfen kann, nicht die Adjektive. Ein Kegel, der sagt „70 % wahrscheinlich, erzeugt von fünf typisierten, in TOML versioniert gestempelten Persönlichkeiten, an einer Stelle normalisiert, Entropie 1,2 nats", ist eine prüfbare Behauptung. Der Mechanismus ist sichtbar. Der Reifegrad ist markiert. Der Status wird nicht hochgestuft.

Was ist der Loom, und warum schreiben Sisters nicht nach Postgres?

Der Loom ist der Orchestrator, der die Prognose persistiert, und Sisters schreiben nicht nach Postgres, weil das, was imaginiert, nicht das sein sollte, was sich erinnert. In Everythinks Architektur läuft eine Simulation so: die API authentifiziert und validiert, der Loom löst das Profil auf und fügt die Simulationszeile ein, die Sisters rufen je imagine() auf und geben ein SisterOutput zurück, das Oracle merge()t die Ausgaben zu einem normalisierten Ensemble, und der Ledger persistiert die Szenarien und das foresight. Die Sisters geben zurück; sie schreiben nicht.

[PERSONAL EXPERIENCE] Die Maschine läuft seit 2016 in Produktion, und die Trennung von Imagination und Persistenz ist ihre älteste Invariante. Eine Sister, die nach Postgres schreiben könnte, wäre eine Sister, die in den Record lügen könnte. Eine Sister, die ein SisterOutput an den Loom zurückgibt, kann nur vorschlagen; der Loom verfügt — er entscheidet, was persistiert wird, in welcher Form und mit welcher Provenienz. Dieselbe Trennung ist der Grund, warum Persönlichkeiten Daten sind: die Imagination ist konfigurierbar, die Persistenz ist fix, und beide teilen sich keinen Code-Pfad.

Die „Data Systems Of Agents"-Sektion des BAIR Blog machte das angrenzende Argument: wenn Tausende von Agenten geteilten Zustand editieren, "the effects of the vast majority of these transactions need to be rolled back — with only the one 'correct' transaction's result persisting", und Exactly-Once-Semantik und Operational Transformation sind das relevante Werkzeugkasten (BAIR Blog, "Intelligence is Free, Now What?", Juli 2026). Everythinks Loom ist eine einfachere, frühere Instanz desselben Prinzips: die Entwürfe der Sisters sind tentativ, der Merge des Oracle zählt, und der Ledger schreibt den Merge. Nichts, was die Sisters einzeln erzeugt haben, wird als die Prognose persistiert.

Wie erreicht die Prognose eine Abfrage?

Die Prognose erreicht eine Abfrage wie jeder andere Datensatz auf der Plattform: über die API, unter /api/v1/..., authentifiziert durch das Eye-Key-Regime mit per-Key-Ratenbegrenzung. Das gemergte Ensemble wird als Szenarien und foresight persistiert; eine Abfrage gibt den normalisierten Kegel zurück, nicht die rohen Entwürfe. Der Konsument braucht die Verteilung, und die Verteilung ist, was der Ledger speichert.

Hier zahlt sich die Ein-Stellen-Normalisierungs-Invariante nachgelagert aus. Weil das Oracle die einzige Stelle ist, die normalisiert, liest jeder Konsument — die API, die Console, ein Drittanbieter-SDK — dieselbe Verteilung. Es gibt keinen „beim Lesen renormalisieren"-Schritt, der drift könnte. Ein Käufer, der die Prognose einen Monat später abfragt, erhält dieselben Wahrscheinlichkeiten, die persistiert wurden.

Häufig gestellte Fragen

Werden die einzelnen Entwürfe der Sisters als Teil der Prognose freigegeben?

Nein. Die Sisters geben SisterOutput-Datensätze an den Loom zurück; das Oracle merged sie zu einem normalisierten Ensemble; der Ledger persistiert das gemergte Ensemble als Szenarien und foresight. Eine Abfrage gibt den Kegel zurück, nicht die fünf Entwürfe. Die Ein-Stellen-Normalisierungs-Invariante bedeutet, dass die gemergte Verteilung — nicht die rohen Entwürfe — das kanonische Artefakt ist.

Erfordert das Bearbeiten der Persönlichkeit einer Sister ein Code-Release?

Nein. Jede Sister ist eine Personality, geladen aus einer TOML-Datei in backend/crates/everythink-sisters/personalities/. Ein TOML zu bearbeiten erfordert kein Rekompilieren. Die Prompt-Version wird auf jeden Lauf gestempelt, sodass die Provenienz einer Prognose die Persönlichkeitsversion enthält, die sie erzeugt hat. Das ist der Mechanismus hinter sowohl der Vielfalt des Schwarms als auch seiner Auditierbarkeit.

Was bedeutet „kalibriert" hier, und ist es eine Genauigkeitsgarantie?

Kalibriert bedeutet, dass die Wahrscheinlichkeiten vergleichbar sind — sum(probability) ≈ 1.0, absteigend sortierte Szenarien, Entropie in nats — erzeugt durch einen einzigen Normalisierungsschritt im Oracle. Es ist keine Garantie, dass die Prognose mit der Zukunft übereinstimmt. Wie MarkTechPosts Benchmark-Übersicht anmerkte, sind Agent-Scores „highly scaffold-dependent" und keine Zahl sollte isoliert gelesen werden (MarkTechPost, "Top 7 Benchmarks That Actually Matter for Agentic Reasoning in Large Language Models", April 2026). Kalibrierung macht die Prognose prüfbar; sie macht sie nicht korrekt.

Werden das Wallet oder die Community-Credit-Schicht zur Bewertung von Prognosen verwendet?

Nein. Das netzwerkbezogene Wallet & Token und der Community Credit sind 🔵 Roadmap — ohne Umsatz, nicht implementiert, vor jedem Launch der Howey-Prüfung unterworfen. Nichts in der Wallet- oder Token-Schicht ist live, und nichts hier ist Finanz-, Investitions- oder Rechtsberatung. Die Prognose ist ein Wahrscheinlichkeitskegel, kein bepreistes Instrument.

Kann eine Sister hinzugefügt oder entfernt werden, ohne das Oracle zu ändern?

Das Oracle merged die SisterOutput-Datensätze, die der Loom ihm übergibt. Eine Sister hinzuzufügen bedeutet, ein Persönlichkeits-TOML hinzuzufügen und es in den Fan-Out einzubinden; die Merge-Logik in everythink-oracle::ensemble ändert sich nicht pro Persönlichkeit. Die Normalisierungsstelle bleibt eine. Die Entropie des Kegels wird die neue Mischung der Typen widerspiegeln — eine breitere Menge an Linsen sollte einen breiteren oder anders gewichteten Träger ergeben, und das Oracle berichtet das ehrlich.

---

Ein Schwarm imaginiert. Ein Orakel merged. Die Prognose ist der Merge — an einer Stelle normalisiert, vom Loom persistiert und mit dem realen Reifegrad jeder Komponente dahinter markiert. Wenn Sie sehen möchten, wie fünf typisierte Sisters auf einer Plattform, die seit 2016 in Produktion läuft, zu einem kalibrierten Wahrscheinlichkeitskegel werden, lesen Sie die Papers oder buchen Sie eine Demo.

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/