Der Intelligence-Hub

Intelligence (/intelligence) beantwortet eine andere Frage als der Rest des Produkts. Tasks, Runs und Backlog handeln von der Arbeit. Intelligence handelt davon, wie gut die Agenten diese Arbeit erledigen und wie das mit der Zeit besser wird. Genau deshalb steht der Hub in der Seitenleiste in der Gruppe Auswerten neben den Berichten: Berichte sagen dir, was die Arbeit hervorgebracht hat, Intelligence sagt dir, wie gut die Maschinerie ist, die es hervorgebracht hat.

Der Hub trägt vier Tabs – Wissen, Agent KPIs, Auto-Agent / Modelle und Beratungen. /intelligence landet auf Wissen; die übrigen drei liegen ein Segment tiefer.

Warum diese vier zusammengehören

Jeder Tab ist eine Station derselben Schleife. Wissen ist das, was die Agenten beim Start kennen. Auto-Agent / Modelle hält fest, wer für ein Stück Arbeit ausgewählt wurde und unter welcher Richtlinie. Agent KPIs misst, wie gut sich diese Wahl geschlagen hat, und stellt eine Ausführungsstrategie an derselben Arbeit gegen eine andere. Beratungen ist das, was passiert, wenn ein einzelner Agent für eine Entscheidung nicht genügt und stattdessen mehrere abwägen. Und eine Empfehlung aus den Agent KPIs lässt sich direkt zurück ins Wissen pinnen – dort schließt sich die Schleife. Keiner dieser vier Tabs ist ein Ort, an dem Arbeit stattfindet; alle vier handeln von der Güte dieser Arbeit. Deshalb sind sie eine Oberfläche und nicht vier Seitenleisten-Einträge.

Wissen

Eine Memory ist eine dauerhafte Notiz, die Agenten als Kontext erhalten: eine Konvention, eine Stolperfalle, eine erinnerungswürdige Entscheidung. Der Tab heißt Wissen, das Objekt darin heißt Memory. Jede Memory hat einen Scope – persönlich (nur deine), Projekt (an ein Projekt gebunden) oder Workspace (im Workspace geteilt) –, und der Scope entscheidet sowohl darüber, wer sie sieht, als auch darüber, ob sie mit deinem synchronisierten Repository mitreist.

Der Wissen-Tab bietet mehrere Sichten auf diesen Bestand; hier zählt vor allem die Sicht Governance. Dort legt ein Workspace-Eigentümer oder -Admin je Scope fest, ob eine neue Memory dieses Scopes sofort live geht oder erst auf eine menschliche Freigabe wartet, und wie lange Memories dieses Scopes aufbewahrt werden. „Prüfung erforderlich” ist der sichere Standard, und er gilt für jede neue Memory dieses Scopes – für eine, die du selbst schreibst, genauso wie für eine, die ein Agent am Ende eines Tasks vorschlägt.

Schreiben, Bearbeiten, Vorschläge prüfen und die Versionshistorie einer Memory lesen behandelt Memories verwalten vollständig.

Agent KPIs

Die Route heißt experiments, der Tab heißt Agent KPIs. Beides ist ehrlich: das zugrunde liegende Objekt ist tatsächlich ein Experiment, und der Tab wurde danach benannt, was er zeigt, nicht danach, worauf er gebaut ist. Das Wort überlebt in der URL und in der API; die Oberfläche ist ein KPI-Dashboard.

Ein Experiment ist ein Benchmark, den du definierst: ein kleiner Datensatz von Aufgabenfällen und mindestens zwei Varianten. Eine Variante ist eine vollständige Ausführungsstrategie – welcher Agent und welches Harness, welcher Anbieter, welches Modell, welche Tool- und Budget-Richtlinie. Beim Start entfaltet das Experiment Fälle × Varianten zu echten Tasks in einem echten Projekt; der Vergleich besteht also aus tatsächlichen Agenten-Runs und nicht aus einer Simulation. Sobald ein Run endet, hängt sich seine Telemetrie von selbst an: Kosten, Tokens, Laufzeit, Wiederholungen, Tool-Fehler, Timeouts und ob ein Pull-Request dabei herauskam.

Fälle × Varianten ergibt meist mehr Tasks, als ein Workspace gleichzeitig ausführt – und das ist in Ordnung: Der Start startet so viele, wie Plätze frei sind, und stellt den Rest in eine Warteschlange. Ein wartender Run ist weder fehlgeschlagen noch verloren – er steht im Start-Panel unter Warten auf einen Platz und startet von selbst, sobald frühere Runs enden. Das zählt für die Kennzahlen genauso wie für die Nerven: Ein Run, der nie gestartet ist, darf nie als verlorene Variante gewertet werden.

Sie müssen nicht jedes Mal das ganze Dataset starten. Haken Sie einzelne Dataset-Cases an, um genau diese zu starten – nützlich, um eine einzelne Lücke in der Matrix zu füllen, statt alles davor zu wiederholen. Ein Start verdoppelt außerdem keinen Case, der auf dieser Variante bereits läuft oder schon erfolgreich war; er meldet ihn als bereits abgedeckt, statt still dieselbe Messung ein zweites Mal zu machen. Wenn die Wiederholung genau das Ziel ist – etwa um ein flackerndes Ergebnis zu reproduzieren – haken Sie Vorhandene Läufe wiederholen an.

Varianten lassen sich einem bereits laufenden Experiment hinzufügen. Eine neue Variante startet bei einer Stichprobengröße von null, und das ist fair statt unglücklich: Jede Kennzahl dieses Boards wird je Variante gemessen; die neue Variante verdient sich ihre Zahlen also genauso wie die anderen, und keine bestehende Variante verschiebt sich dadurch.

Innerhalb eines Experiments müssen Variantennamen eindeutig sein — ohne Rücksicht auf Groß-/Kleinschreibung und umgebende Leerzeichen. Das ist keine Buchhaltung: Der Name ist die Zuordnung eines Ergebnisses — auf dem Leaderboard, in den Bewertungen und in jeder Durchsicht des Laufs. Zwei Varianten namens „Control” machten jede Kennzahl zwischen ihnen mehrdeutig. Eine Kollision wird abgelehnt, und die Ablehnung nennt die betroffene Variante. Verschiedene Experimente dürfen dieselben Namen wiederverwenden.

Genau darin liegt die Antwort auf die Frage, für die es diesen Tab gibt: Woher weißt du, dass eine Änderung an der Arbeitsweise eines Agenten die Dinge besser gemacht hat und nicht bloß anders? Weil jede Variante dieselben Fälle bearbeitet hat, ist der Vergleich gleichwertig – und die Kennzahl, die es entscheidet, ist meist nicht die Erfolgsquote allein, sondern die Kosten je akzeptiertem Ergebnis: Eine Variante, die etwas seltener trifft, dafür ein Drittel kostet, kann der bessere Standard sein.

Das Dashboard liest denselben Bestand durch sechs Sichten: ein Leaderboard je Variante, dieselben Zahlen umgruppiert nach Harness und nach Modell, eine Matrix der Task-Klassen mit dem Sieger je Klasse von Arbeit, eine Run-Detailsicht und eine Benchmark-Matrix. Je Variante meldet es die Stichprobengröße, den Anteil akzeptierter Runs, Kosten, Minuten und Tokens je akzeptiertem Ergebnis, die Anteile bestandener Tests und angenommener Reviews, den Timeout-Anteil und den Verlust – das Geld für Runs, aus denen nichts wurde. Daraus leitet es Empfehlungen ab, jede mit Stichprobengröße und Konfidenz und jede ins Workspace-Wissen pinnbar, sodass Agenten das Ergebnis beim nächsten Run als Kontext lesen.

Auto-Agent / Modelle

Wenn du einen Task startest, ohne ein Agent-Profil festzupinnen, wählt SupaCloud eines für dich. Es bewertet jedes aktive Profil nach Fähigkeitspassung, dem Ausgang früherer Runs dieses Profils, einem gelernten Signal aus erfassten Ergebnissen, Budgetdruck, der Frage, ob es der Workspace-Standard ist, und Kosteneffizienz. Das Modell kommt anschließend aus dem Profil, das gewonnen hat: das festgepinnte, falls es eines pinnt, sonst das, auf das sich die Lernschicht für dieses Profil eingependelt hat. Jede Entscheidung trägt eine Richtlinie – auto, wenn SupaCloud gewählt hat, manual, wenn du selbst ein Profil gepinnt hast oder die automatische Auswahl für den Workspace abgeschaltet ist.

Dieser Tab ist der Verlauf dieser Entscheidungen: eine Zeile je Auswahl mit Zeitpunkt, gewähltem Agent-Typ und Modell, der Richtlinie und einer einzeiligen Zusammenfassung dessen, wofür ausgewählt wurde. Der Verlauf lässt sich durchsuchen, sortieren und nach Provider, Modell und Richtlinie filtern.

Er ist bewusst nur lesbar, und das ist eine gezogene Grenze, kein fehlendes Feature: Die automatische Auswahl hält fest, was sie entschieden hat und was du überstimmt hast, und sie lernt aus diesem Protokoll nicht unmittelbar nach. Nichts auf diesem Tab verändert, wie die nächste Auswahl zustande kommt.

Drei Dinge, die man hier zu Recht erwarten könnte, liegen anderswo:

Der autonome Backlog-Router ist ein anderer Selektor. Wenn die Delivery-Engine ein Backlog-Item versendet, routet sie nach Schweregrad, Umfang und Aufwand über eine Kandidatenmenge von Profilen und schreibt das in ihr eigenes Routing-Entscheidungsprotokoll – mit den Kandidaten, dem gewählten Profil und der Begründung. Dieses Protokoll liegt unter Berichte → Betrieb, nicht hier; Backlog-Routing-Entscheidungen erscheinen also nicht auf diesem Tab. Wie weit die Engine allein gehen darf, behandelt Autonomie und die Delivery-Engine.
Der Live-Modellkatalog wird hier nicht gezeigt. SupaCloud synchronisiert einen Katalog von Modellen mit Kontextfenstern, Preisen und Fähigkeiten, und dieser Katalog speist die Modell-Auswahlfelder und den Modelle-Tab in den Einstellungen. Die Modellspalte dieses Tabs ist der Rohwert, der zum Zeitpunkt der Entscheidung erfasst wurde – ein Modell, das du längst nicht mehr einsetzt, steht deshalb weiterhin in seiner Historie.
Kontingente und Modell-Fallback stehen hier ebenfalls nicht. Die Anzeigen zur Anbieter-Auslastung liegen unter Berichte → Betrieb, und die Kette, die einen Task auf ein gleichwertiges Modell verschiebt, wenn das gepinnte an seine Kontingentgrenze stößt, ist eine Workspace-Einstellung – beschrieben in Wenn ein Modell sein Kontingent erreicht.

Beratungen

Eine Beratung (englisch Council) sind mehrere Agent-Profile, die dieselbe Frage erörtern, wobei eines als Richter auftritt und die Antworten zu einer einzigen Empfehlung mit Konfidenz zusammenführt. Eine Beratung ändert von sich aus nie etwas. Sie erzeugt eine Empfehlung und hört auf; darauf zu handeln ist ein ausdrücklicher, getrennter Schritt – aus einer abgeschlossenen Beratung heraus kannst du sie abzweigen, in einen Task umwandeln oder ihre Synthese ins Wissen pinnen.

Eine Beratung entsteht heute also durch eine Pipeline-Stufe, die als Beratung konfiguriert ist: Statt dass ein einzelner Agent diese Stufe abarbeitet, erörtern mehrere Kandidatenprofile denselben Stufen-Prompt, und ein Richter führt das Ergebnis zusammen. Verfügbar ist das auf den abwägenden Stufen – eine Änderung planen und sie prüfen – und bewusst nicht auf der Stufe, die Code schreibt: Eine Beratung wägt einen Plan oder ein Review ab, sie implementiert nicht. Sie ist vollständig opt-in; keine Pipeline kommt mit eingeschalteter Beratung.

Der Beratungen-Tab ist der Ort, an dem du die Ergebnisse liest. Er listet die Beratungen des Workspace mit einem Statusfilter, und beim Öffnen siehst du die erörterte Frage, die Beteiligten, die Synthese des Richters, deren Konfidenz und die drei Folgeaktionen. Du startest von diesem Tab aus keine Beratung – du schaltest die Option für eine Stufe ein, und die Beratungen erscheinen hier, während diese Pipeline läuft.

Der Governor – die Schleife, die sich schließt

Unter Auto-Agent / Modelle liegt eine Lernschleife, und über dieser Schleife steht ein Governor, dessen ganze Aufgabe darin besteht, dafür zu sorgen, dass das Lernen die Dinge nie stillschweigend verschlechtert.

Die Grundform lohnt sich, auch wenn du nie etwas daran konfigurierst. Die Auswahl startet bei einer statischen Heuristik – darauf läuft ein brandneuer Workspace, und bei Sicherheit und Budget bleibt sie maßgeblich. Erfasste Ergebnisse speisen dann ein Belohnungssignal, und eine gelernte Schicht darf die Rangfolge der Heuristik anstupsen, sobald genug Daten vorliegen, um ihr zu trauen. Der Governor beobachtet genau das: Er vergleicht die jüngsten Ergebnisse eines Profils mit dessen eigener früherer Grundlinie, und wenn die jüngere Verteilung sich wirklich verschlechtert hat statt nur zu schwanken, friert er die gelernte Auswahl für dieses Profil ein – die Auswahl fällt auf die reine Heuristik zurück –, schreibt ein Audit-Ereignis und eröffnet einen Vorschlag für einen Menschen.

Nichts, worauf der Governor kommt, wird von selbst angewendet. Seine Vorschläge – und die Skills, die er aus erfolgreichen Runs ableitet – landen in der einen Entscheidungs-Warteschlange unter Posteingang → Entscheidungen, neben Workflow-Gates, Tool-Freigaben und Memory-Prüfungen. Wird ein Profilversions-Vorschlag angenommen, schreibt das über den gewöhnlichen validierten Weg eine neue Version des Agent-Profils und hebt den Freeze auf; wird er abgelehnt, schließt der Vorschlag und der Freeze bleibt bestehen – eine Ablehnung ist also eine sichere Antwort und kein stilles Weiterlaufen. Den vollständigen Mechanismus – die Lernschichten, das Golden-Set-Audit, den kalibrierten Richter und den Drift-Test – beschreibt Der selbstlernende Governor.

Wer was sehen und ändern darf

Der Hub ist nicht admin-gebunden: Jedes Mitglied des Workspace sieht alle vier Tabs, und Lesen ist durchgehend auf Mitgliedsebene – die Memory-Liste, das KPI-Dashboard, der Auswahlverlauf und die Beratungsliste stehen Mitgliedern offen, und jede Abfrage ist auf deinen Workspace eingegrenzt, sodass kein Tab die Daten eines anderen Workspace zeigen kann.

Unterschiede gibt es beim Schreiben. Einen Benchmark anlegen, seine Tasks starten und eine Empfehlung ins Wissen pinnen verlangen Workspace-Eigentümer oder -Admin, und ebenso das Setzen der Memory-Governance je Scope. Wissen ist die bewusste Ausnahme: Jedes Mitglied darf eine Memory schreiben, und ob sie sofort veröffentlicht wird oder in die Prüfung wandert, entscheidet die Governance-Richtlinie – nicht eine Rolle. Beratungen sind von dieser Oberfläche aus für alle nur lesbar; ihre Folgeaktionen stehen Mitgliedern offen, weil keine davon ein Repository verändert. In der Entscheidungs-Warteschlange unterscheiden sich die beiden governor-nahen Arten: Über einen abgeleiteten Skill-Vorschlag darf ein Eigentümer oder ein Admin befinden, ein Profilversions-Vorschlag ist dem Workspace-Eigentümer vorbehalten.

Über all dem steht ein weiteres Tor: Jede dieser Oberflächen ist eine eigene Berechtigung. Auf einem Tarif, der sie nicht enthält, meldet der Tab, dass die Funktion für den Workspace nicht freigeschaltet ist, statt ein leeres Board zu zeigen. Wie Tarife und Deployment-Edition zusammenspielen, behandelt Berechtigungen und MCP-Tool-Stufen.