Letzte Woche schrieb ich über NeMoCo, ein selbstüberwachtes System, das lernt, neuronale Strukturen zu kategorisieren, wie das Gehirn die Welt kategorisiert — aus rohen, unbeschrifteten Erfahrungen, ohne dass man ihm sagt, welche Kategorien das sind. Ich kam immer wieder auf denselben Satz zurück: Labels sind eine Abkürzung, Struktur ist das, was zählt.

Diese Woche habe ich die andere Hälfte dieser Idee umgesetzt, im Bereich, in dem ich tatsächlich arbeite. Ich führe einen persönlichen KI-Assistenten — Aura — der das Gedächtnis verwaltet, Aufgaben weiterleitet und versucht, über Sitzungen hinweg wirklich nützlich zu sein. Er läuft auf einer Flotte von Modellen: Claude für produktives Coden, eine Handvoll Cloud-Modelle für Forschung und Design sowie ein lokales Modell, das nichts verbraucht. Das Problem ist das gleiche, das NeMoCo löst, nur umgekehrt. NeMoCo lernt Struktur aus Rohdaten. Ich hatte die Struktur — einen Kader von Agenten, jeweils mit einer Aufgabe — und ich brauchte das System, um zu entscheiden, welches Modell welche Aufgabe übernehmen soll, live, unter einem Budget, das aufgebraucht wird.

Dieser Entscheidungsmotor ist das, was ich diese Woche gebaut habe. Er besteht aus drei Teilen: einem Klassifikator, der eine Aufgabe liest und entscheidet, welche Art von Arbeit sie ist, einem Router, der ihr das beste Modellketten-Modell zuweist, basierend auf dem aktuellen Kontingent, und einem Dashboard, das das Ganze als lebendiges, pulsierendes Gehirn darstellt. Dies ist der technische Bericht — was jedes Teil tut, warum es so geformt ist, und die Fehlschläge, die das Design erzwungen haben.

Das Problem: Ein Kader ist kein Router

Die naive Einrichtung ist eine statische Tabelle: Dieser Agent führt dieses Modell aus, jener Agent führt jenes Modell aus. Es ist einfach, und es ist falsch, aus drei Gründen.

Erstens, das Budget ist aufgebraucht. Claude arbeitet mit einem wöchentlichen Kontingent und einem rollenden Sitzungs-Kontingent, und sie bewegen sich unabhängig voneinander. An einem Tag lag das wöchentliche Kontingent bei 15 % während das Sitzungs-Kontingent bei 71 % stand — und weil der alte Router nur die wöchentliche Zahl beobachtete, meldete er „Claude verfügbar, Modus NORMAL“ und leitete die Codierungsarbeit direkt in eine Sackgasse. Die CLI lehnte jeden Aufruf für drei Stunden ab mit „Sie haben Ihr Sitzungs-Limit erreicht“, während das Dashboard weiterhin alles als in Ordnung ausgab. Ein Router, der das tatsächlich bindende Limit nicht liest, ist kein Router, sondern ein Ratespiel.

Zweitens, Qualität ist keine einzelne Zahl. Ein Modell, das guten Code schreibt, ist dadurch nicht automatisch gut beim Langkontext-Abruf oder bei der UI-Generierung. Die Bewertung jedes Modells mit einem einzigen „Qualität“-Score ist sinnlos — sie kann nicht sagen, welches Modell den Coder führen sollte gegenüber dem Forscher. Jeder Agent muss auf seiner eigenen Achse bewertet werden.

Drittens, derReviewer darf die blinden Flecken des Autors nicht erben. Ich paire bewusst einen Autor und einen Reviewer — der Coder schreibt, der Diagnostician überprüft — und sie müssen verschiedene Modellfamilien verwenden, sonst macht der Reviewer einfach die gleichen Fehler erneut. Die erste Version des Routers landete beide Köpfe ständig auf dem gleichen Modell, weil sie bei Gleichstand nach Latenz entschied. Das untergrub das gesamte Design.

Also musste die statische Tabelle weg. Was sie ersetzt hat, ist ein Entscheidungsmodul, das den Live-Zustand liest und pro Aufgabe die beste Modellkette berechnet.

Der Klassifikator: Die Aufgabe lesen

Das erste Stück ist ein Klassifikator, der eine Aufgabe liest und entscheidet, welche Art von Arbeit sie ist. Die Eingabe ist ein Satz — „der Zahlungsendpunkt gibt seit dem Deploy in Produktion 500 zurück“ — und die Ausgabe ist ein Urteil: Art, Stufe und Priorität.

Die erste Version war reiner Regex. Sie funktionierte, und sie war brüchig auf genau die Weise, wie Regex immer brüchig ist. „Log parser“ wurde fälschlicherweise an Ops weitergeleitet (es ist eine Code-Komponente, keine Ops-Aufgabe). „Checkout berechnet Kunden doppelt“ enthielt überhaupt kein Fehler-Vokabular, sodass es als unknown klassifiziert wurde und an den Haupt-Agenten durchgereicht wurde — bei einem Produktionsvorfall. „Throwing 500s“ passte nicht zum Statuscode-Muster, weil das nachgestellte ‚s‘ die Wortgrenze brach. Jeder dieser Fälle war eine echte Fehlleitung, die ich jeweils einzeln behoben habe, und jede Korrektur war eine neue Regex-Regel. Das ist das Anzeichen dafür, dass man das falsche Werkzeug bekämpft.

So versucht der Klassifikator jetzt zunächst ein günstiges Modell — `deepseek-v4-flash:cloud` liest die Aufgabe und gibt ein JSON-Urteil zurück. Falls das Modell nicht verfügbar ist, fällt es auf den Regex-Klassifikator zurück. Das Modell ist der Hauptweg; der Regex ist das Sicherheitsnetz. Dies ist dieselbe Lehre wie bei NeMoCo: nicht jedes Fall manuell labeln, die Struktur lernen und sie übertragen lassen.

Der Klassifikator erhält außerdem das aktuelle Kontingent vom Aufrufer, sodass er niemals vom Router abweichen kann. Der Aufrufer liest den Kontingenzustand und übergibt ihn; der Klassifikator liest die Kontingendatei nicht direkt. Die zentrale Regel lautet: Produktionsarbeit wird niemals auf ein schwaches Modell herabgestuft, egal wie knapp das Budget ist. Ein Produktionsvorfall wird als `prod` klassifiziert, selbst wenn Claude erschöpft ist — er wird nicht stillschweigend an einen leichten Agenten weitergeleitet und als erledigt gemeldet. Stattdessen blockiert er, und das Übergabeprotokoll wird ausgelöst. Das Qualitätsrisiko ist schlimmer als das Kontingentrisiko, und das Design vergisst niemals, welches welches ist.

Der Router: Das Entscheidungsmodul

Der Router ist der Ort, wo das eigentliche Denken stattfindet. Er nimmt das Urteil des Klassifikators und den aktuellen Provider-Zustand entgegen und berechnet pro Aufgabenstufe eine Modellkette.

Der Kern ist achsenbasiertes Scoring. Jeder Agent wird auf seiner eigenen Skill-Achse bewertet — Coder bei Codegenerierung, Diagnostician beim Debug‑Reasoning, Researcher bei Faktenabruf, Creative bei UI‑Generierung, Ops beim Tool‑Aufruf, Main bei Orchestrierung. Die effektive Qualität eines Modells ist sein synthetischer Benchmark‑Score mal seine beobachtete Zuverlässigkeit in echten Sessions. Ein Modell, das im Benchmark gut abschneidet, aber in der Produktion Fehler macht, wird degradiert. Das ist die „Lernen aus echter Leistung“-Schicht: Der Benchmark repräsentiert synthetische Fähigkeit, die Zuverlässigkeitsdaten zeigen, was tatsächlich gehalten hat.

Die Bewertungsformel ist Banders Gewichtsmatrix: `score = quality·Wq − cost·Wc − latency·Wl + claudeBonus`. Kosten sind ein relativer 0..1‑Tier, keine echten Dollar — denn Ollama Cloud hat keinen Preis pro Aufruf und Claude ist ein Abonnement, sodass man sie nicht ehrlich gegeneinander min‑max‑skalieren kann. Außerdem gibt es eine harte Qualitätsuntergrenze: Ein Kandidat, der auf seiner eigenen Achse darunter liegt, wird vor dem Ranking entfernt, sodass ein günstiges‑aber‑dummes Modell niemals allein aufgrund des Preises gewinnen kann.

Der Router behandelt auch das Dekorrelationsproblem — indem er die Coder‑ und Diagnostician‑Köpfe auf verschiedene Modellfamilien zwingt, damit der Reviewer nicht die Blindstellen des Writers erbt. Außerdem kümmert er sich um Subagent‑Ökonomie: Ein Subagent führt einen Teil des Auftrags seines Elternteils aus, und eine Delegation kann sich bis zu 20‑fach verzweigen, sodass Subagent‑Ketten den Kosten weit mehr Gewicht geben als irgendeine feste Stufe. Das hält Claude aus Subagent‑Ketten heraus, ohne einen harten Ausschluss — bei einem Kostengewicht von 0,45 kann es einfach nicht gewinnen.

Das Dashboard: Das robotische Gehirn

Das Dashboard ist der Teil, der sich am schwierigsten in Text erfassen lässt. Es stellt das gesamte System als lebendiges Gehirn dar.

Es gibt eine 3D‑Gehirnansicht — eine mit WebGL gerenderte neuronale Struktur, bei der jeder Agent ein Gebiet ist, und Sie können umherkreisen, zoomen und auf ein Gebiet klicken, um in dessen Modellkette, Statistiken und Überschreibungsselektor einzudringen. Außerdem befindet sich im Grid‑View ein „elektronisches Gehirn‑Centerpiece“: Eine SVG‑Schaltkreisplatte, auf der die Agents als Workflow‑Knoten dargestellt sind, die über animierte Signalspuren verbunden sind, wobei das Ganze je nach Live‑Aktivität schneller oder langsamer pulsiert.

Das Gehirn ist nicht nur Dekoration. Es ist sichtbare Telemetrie. Das Dashboard leitet die Aktivität pro Agent aus dem Wachstum der Sitzungsdateien zwischen den Abfragen ab — das stärkste Signal dafür, dass ein Agent tatsächlich arbeitet — und stellt es als Signalimpulse dar, die entlang der Schaltkreisbahnen wandern. Wenn das System inaktiv ist, verlangsamt sich das Gehirn auf ein Kriechen. Wenn es ausgelastet ist, rasen die Spuren. Sie können sehen, wie das Gehirn denkt.

Es gibt außerdem einen Tier‑Selektor — sechs Buttons (Tier 1–4, ein „Local“-Schild und ein „Baseline“-Reset) — mit denen Sie die gesamte Flotte auf eine bestimmte Qualitätsstufe zwingen können. Außerdem gibt es pro‑Agent‑Model‑Overrides, die in einer Datei gespeichert werden, sodass Sie ein bestimmtes Modell an einen bestimmten Agenten festnageln können, wenn die Wahl des Live‑Routers nicht Ihren Vorstellungen entspricht. Das Dashboard ist die Steueroberfläche für das Gehirn.

Die Misserfolge, die es geprägt haben

Jede Designentscheidung hier ist eine Narbe aus einem echten Misserfolg, und sie sind es wert, aufgelistet zu werden, denn sie sind der eigentliche Inhalt der Woche:

• Der Blindpunkt bei der Sitzungsgrenze. Der Router hat nur das wöchentliche Kontingent berücksichtigt und das tatsächlich bindende Sitzungs-Kontingent ignoriert. Die Lösung: beide lesen und das strengere gewinnen lassen.
• Der Benchmark-Umschlag-Fehler. Der rev1-Benchmark schrieb seine Datei in einem `{value:[...]}`-Umschlag statt eines einfachen Arrays, sodass jede Zeile ein `.model`-Feld fehlte und der Router stillschweigend eine leere Map erhielt. Benchmark-Daten erreichten den Router nie, und niemand beschwerte sich. Die Lösung: das Legacy-Format auspacken, damit alte Dateien weiterhin geladen werden.
• Die Achsen-Rubrik-Inversion. Die Achsen-Rubrik bewertete opus mit 0.50 beim Debug-Reasoning — unter einem Modell, das niemals Produktionscode prüfen sollte. Wenn es die Prod-Stufen neu ordnen dürfte, wäre der Rezensent zum Autor geworden. Die Lösung: Prod-Stufen werden nicht von der Rubrik neu eingestuft. Eine Keyword-Rubrik ist kein stark genuges Beweismaterial, um eine getroffene Designentscheidung zu überturnen.
• Der Kontextfenster-Todesspirale. Das Platzieren eines 131k-Kontext-Modells an der Spitze der Orchestrierungsebene überlief das Fenster und löste die Kompaktions-Todesspirale aus. Die Lösung: Jeder Orchestrierungskandidat muss ein Fenster haben, das komfortabel über dem Kontextbudget plus Reserve liegt.
• Die Reliabilitäts-No-Op. Sitzungsprotokolle speichern den reinen Modellnamen, während Kandidaten ein Provider-Präfix tragen, sodass die Reliabilitätsschicht stillschweigend nichts übereinstimmte. Die Lösung: Das Präfix entfernen, bevor abgeglichen wird.

Was ich mitnehme

Der NeMoCo-Beitrag endete mit: „Labels sind eine Abkürzung, Struktur ist das, was zählt, und du kannst Struktur aus roher Erfahrung lernen.“ Diese Woche war die ingenieurtechnische Version davon. Ich habe für jede Aufgabe keine Regel von Hand geschrieben — stattdessen habe ich einen Klassifikator gebaut, der die Aufgabe liest, und einen Router, der den Live-Zustand liest, und ließ die Struktur der Arbeit das Werkzeug entscheiden. Der Regex-Klassifikator war der „Labels“-Ansatz, und er brach genau dort, wo Labels immer brechen: an den Rändern, bei den Fällen, die du nicht vorausgesehen hast. Der modellgestützte Klassifikator ist der „Struktur“-Ansatz: lerne das Muster, übertrage es, falle geschmeidig zurück.

Und das Brain-Dashboard ist der Teil, der es echt wirken lässt. Wenn du die Signalimpulse entlang der Leiterbahnen rasen sehen kannst, während die Agenten tatsächlich arbeiten, und das Gesamtsystem beim Leerlauf zu einem Kriechen verlangsamt siehst, schaust du nicht mehr auf eine Konfigurationsdatei. Du siehst ein System, das einen Puls hat.

Der Router ist im Geist Open-Source — er besteht aus Skripten in meinem Arbeitsbereich, `classify-job.mjs`, `model-router-core.ps1`, `quota-dashboard.mjs` — und läuft auf einer Mischung aus Claude, Cloud-Ollama-Modellen und einem lokalen Modell, das nichts verbraucht. Es ist kein gesperrtes Unternehmenssystem. Es ist ein Entscheidungs-Engine, den du selbst bauen könntest, und die Fehler, die ihn geformt haben, sind der nützliche Teil.

Das ist die Lehre. Ein Roster ist eine Liste. Ein Router ist eine Entscheidung. Und ein Brain ist das, was du bekommst, wenn die Entscheidung live getroffen wird, unter einem Budget, das aufgebraucht ist, von einem System, das aus seinen eigenen Fehlern lernt.