Gestern Nacht habe ich AutoML in eine Flotte aus zehn Agents eingebaut, in einer einzigen Session. Die zusätzlichen monatlichen Kosten waren null Euro. Nicht weil ich einen Rabatt gefunden hätte, sondern weil die Mathematik im Kern von Agent Routing keinen LLM Call braucht.
Die Flotte läuft alle zwei Wochen sonntags und schreibt zehn bis fünfzehn Seiten Bericht für einen echten Kunden, der den Service bezahlt. Bis gestern liefen alle neun Worker bei jedem Lauf, auch wenn nur vier oder fünf von ihnen wirklich etwas zu sagen hatten zu diesem spezifischen Kunden. Die neue Schicht beobachtet, wie gut jeder Worker tatsächlich performt, lernt welche Worker für welches Customer Profil ihre Zeit wert sind, und ist in ein paar Wochen bereit, nur noch die besten vier bis sechs zu feuern. Die Rechnung bleibt gleich. Der Durchsatz steigt.
Ich schreibe das auf, weil das Muster brutal einfach ist, übertragbar auf fast jedes Setup mit mehreren Agents, und außerhalb akademischer Kreise quasi niemand darüber spricht wie billig es wirklich ist.
Das Setup, das noch keiner hinterfragt hat
Wir betreiben einen Service namens StudioMeyer Agents. Zehn spezialisierte Agents arbeiten auf einem Kunden gleichzeitig, und ein Master Agent näht ihre Findings zu einem zusammenhängenden Bericht. Vier Agents prüfen Website Signale wie Sichtbarkeit, Traffic, Konkurrenz und technische SEO. Drei prüfen KI Sichtbarkeit, also LLM Citations, Brand Mentions und zitierte Quellen. Zwei prüfen Branchentrends. Der letzte, der Master Synthesizer, liest alle neun Reports und schreibt die Version, die der Kunde am Ende sieht.
Für unseren Pilot Kunden, eine Maklerin im Anti Luxus Segment auf Mallorca, feuert der Master alle zwei Wochen sonntags. Für StudioMeyer selbst auch alle zwei Wochen, auf einem anderen Slot. Jeder Lauf verbraucht eine ordentliche Portion Tokens aus dem Anthropic Max Plan. Jeder Lauf produziert auch 40 bis 80 KB strukturierte Worker Reports plus das Markdown, das beim Kunden landet.
Hier ist der Teil, den noch niemand gefragt hat. Welche dieser neun Worker tragen eigentlich wirklich bei? Manche Wochen hat der Technical SEO Agent nichts zu sagen, weil sich auf der technischen Schicht nichts geändert hat. Manche Wochen findet der KI Visibility Agent zwölf neue Citations und der Master baut den halben Bericht drum herum. Verschiedene Kundentypen ziehen unterschiedlich an verschiedenen Agents. Ein Tourismus Kunde profitiert vermutlich mehr von den Sichtbarkeitsagents und den Agents fürs lokale Suchergebnis. Ein B2B SaaS Kunde zieht härter an den Konkurrenz und Citation Agents.
Die Flotte läuft seit Phase D Mitte Mai 2026 produktiv. Sie funktioniert. Aber wir ließen Signal auf dem Boden liegen, indem wir alle neun Agents als gleich relevant für jeden Kunden behandelten.
Warum AutoML normalerweise eine Vendor Rechnung bedeutet
Wenn man den meisten Engineers sagt "wir sollten AutoML in unsere Agent Flotte einbauen", hören sie "lass uns DataRobot, SageMaker Autopilot oder Vertex AI dafür bezahlen". Das ist eine echte Lösung für ein anderes Problem. Keine dieser Plattformen ist billig, und keine wurde gebaut für die Frage, welche Untermenge meiner LLM Agents ich für Kunde X an diesem Dienstag laufen lassen soll.
Der andere Instinkt ist, den LLM entscheiden zu lassen. Bau einen Meta Agent, dessen Job es ist, das Profil jedes Kunden zu lesen, zu entscheiden welche Sub Agents zu feuern, und sie zu dispatchen. Das funktioniert. Heißt aber auch, dass jede einzelne Routing Entscheidung jetzt ein LLM Call ist, mit Latenz, Tokenbudget und Halluzinationsoberfläche.
Es gibt eine dritte Option, und die ist seit den frühen 2010er Jahren Production Standard für Routing Probleme in Adtech und Recommender Systemen. Es hat nur bis AAAI 2026 gedauert, bis jemand ein Tutorial gebaut hat, das es explizit auf LLM Agent Routing anwendet. IBM Research präsentierte zwei davon im Januar, "Bandits, LLMs, and Agentic AI" und "Multi-Armed Bandits Meet Large Language Models". Das vLLM Semantic Router Team machte den gleichen Punkt in ihrem Vision Paper vom April 2026 und empfahl Multi Armed Bandits zur Routing von Queries nach kontextuellen Features.
Das Muster ist älter als die LLM Ära. Das Multi Armed Bandit Problem nimmt an, dass du eine feste Anzahl von Optionen hast (Slot Machines, Ad Creatives, Content Blöcke, oder in unserem Fall Worker Agents) und ein endliches Budget an Versuchen. Du willst lernen welche Optionen sich lohnen und sie ausnutzen, aber gelegentlich die anderen ausprobieren um sicherzustellen, dass deine Überzeugungen noch aktuell sind. Production Code macht das in Dutzenden Zeilen.
Der AdaptOrch Benchmark aus dem Augment Code Orchestration Guide maß den Routing Overhead bei unter 50 Millisekunden. Im Vergleich dazu liegt LLM Inferenz bei 2 bis 15 Sekunden pro Agent Call. Die Mathe ist praktisch gratis.
Zwölf Zeilen Mathematik
Hier ist die Formel, die ich gestern Nacht geshippt habe. Es ist Bayesianisches additives Smoothing, auch bekannt als Laplace Smoothing oder Beta Binomial Conjugate Prior, je nachdem auf welchem Wikipedia Artikel man zuerst landet. Die Additive Smoothing Seite hat die sauberste Version.
export function bayesianMean(
observed: Array<number | null>,
priorMean: number,
priorWeight: number,
): number {
const valid = observed.filter(
(x): x is number => x !== null && Number.isFinite(x),
);
if (valid.length === 0) return priorMean;
const sum = valid.reduce((acc, x) => acc + x, 0);
return (priorWeight * priorMean + sum) / (priorWeight + valid.length);
}
Das ist der komplette Kern. Die Intuition. Man startet nicht mit "ich habe keine Daten, also kann ich nicht ranken". Man startet mit einer prior Überzeugung, ausgedrückt als Mittelwert und Pseudo Sample Count. Mit priorMean = 0.6 und priorWeight = 5 sagt der Prior, jeder Worker sei ordentlich gut (0.6 auf einer Skala von 0 bis 1), und ich sei so sicher darin als hätte ich schon fünf Samples beobachtet.
Wenn der erste echte Sample ankommt, wird er mit den fünf Pseudo Samples verrechnet. Die Schätzung bewegt sich, aber nicht heftig. Nach fünf echten Beobachtungen hat der Prior genau so viel Gewicht wie die Daten. Nach zwanzig echten Beobachtungen ist der Prior im Wesentlichen Rauschen und die tatsächlichen Messungen dominieren.
Worauf wird jeder Worker bewertet? In unserem Fall auf drei Signale, alle aus dem Worker Report selbst extrahiert.
Die Verify Confidence ist ein Wert zwischen 0 und 1, den der Worker sich selbst am Ende jedes Reports in einem dafür vorgesehenen Block zuweist. Wir haben das in Session 1068 zur Pflicht gemacht, als Teil der Schicht gegen Halluzinationen. Jetzt ist es das primäre Input fürs Ranking.
Der Source Citation Count zählt, wie viele Tool Calls und externen Quellen der Worker in seinem Datenquellen Block zitiert hat. Eine hohe Zahl heißt evidenzgestützte Arbeit. Eine niedrige Zahl heißt, der Worker hat sich auf seine Trainingsdaten gestützt.
Die Domain Lock Pass Rate ist ein Ja oder Nein pro Lauf. Ist der Worker auf der tatsächlichen Customer Domain geblieben oder ist er auf Staging Subdomains oder Konkurrenz Sites abgedriftet?
Der Composite Score ist eine gewichtete Summe.
rankScore =
smoothedConfidence * 0.5 +
normalize(smoothedSourceDensity) * 0.3 +
domainLockPassRate * 0.2;
Fünfzig Prozent auf die Selbstauskunft des Workers, dreißig Prozent auf Evidenzdichte, zwanzig Prozent auf Hygiene. Drei Stellschrauben, die später feintunbar sind, wenn genug Daten da sind um über die richtige Ratio zu diskutieren. Keines dieser drei Signale brauchte neue Infrastruktur. Sie waren schon in jedem Worker Report, geschrieben von den Agents selbst, für den Guard gegen Halluzinationen. Die Rankingschicht liest sie nur.
Cold Start ist das eigentliche Problem
Die meisten Tutorials zum Multi Armed Bandit beginnen mit Exploration versus Exploitation. Das klassische Dilemma. Soll man weiter an dem Slot Machine spielen, der bisher am besten ausgezahlt hat, oder den ausprobieren, den man eine Weile nicht gezogen hat?
In Produktion ist das nicht das schwere Problem. Das schwere Problem ist, was man Tag eins macht, wenn man null Daten hat, oder Tag drei, wenn man Daten zu drei von neun Workern hat und nichts zu den restlichen sechs.
Das Facebook Reels Team hat das 2023 mit Thompson Sampling auf Posterior Samples für Content Cold Start gelöst, indem sie aus der Posterior Verteilung statt aus einem Punkt Schätzer zogen, sodass brandneuer Content noch eine faire Chance bekam. Die 2026er Papers zu Bandits, die einen LLM einbinden, gehen weiter. Sie lassen einen LLM die fehlenden Beobachtungen vorhersagen und füttern sie in den Bandit als Pseudo Daten ein, gewichtet danach wie gut die LLM Vorhersagen bisher mit der Realität übereinstimmten.
Ich habe beides erwogen. Geshippt habe ich für jetzt etwas einfacheres, einen harten Guard für Cold Start. Wenn die Gesamtzahl beobachteter Worker Runs unter drei liegt, gibt die Empfehlungsfunktion einfach "alle neun Worker, Exploration Phase" zurück. Es wird keine Routingentscheidung auf einem so kleinen Datensatz getroffen. Nach drei Runs haben wir neun Worker mal drei Samples plus den Prior, was reicht um eine weiche Empfehlung zu geben. Nach zehn bis zwanzig Runs ist der Prior im Rauschen verschwunden.
if (totalRunsObserved < MIN_SAMPLES_FOR_RECOMMENDATION) {
return {
coldStart: true,
recommendedWorkers: rankings.map((r) => r.agentKuerzel), // alle 9
...
};
}
Das ist ein bewusster Trade-off. Ein ausgefeilterer Bandit wie LinUCB oder Thompson Sampling würde auch Tag eins schon eine weiche Empfehlung machen. Aber eine weiche Empfehlung Tag eins ist genau die Sorte Ding, die einen Woche drei einholt, wenn man merkt das System hat unverhältnismäßig den Agent bevorzugt, der bei seinem ersten Run Glück hatte. Lieber neun volle Runs durchs Fenster für Cold Start zahlen und Woche sechs eine selbstbewusste Routingentscheidung shippen als eine wackelige sofort.
Tools im Closure, oder warum Tenant Isolation hier auch nichts kostet
Der Master Synthesizer muss das tatsächlich aufrufen. Das machen wir mit zwei Inline Tools, track_worker_performance und get_worker_ranking. Beide werden beim Master Agent zur Buildtime registriert.
Das Pattern mit dem Customer Slug im Closure ist einen Absatz wert, weil es die Sorte Ding ist, die einen am Tag beißt, an dem man Kunde Nummer zwei onboardet. Hier ist die relevante Signatur.
export function buildTrackPerformanceInlineTool(
customerSlug: string,
agentResolver: (kuerzel: string) => SmaAgentDef | undefined,
options: { dryRun?: boolean } = {},
): SdkMcpToolDefinition {
return {
name: "track_worker_performance",
description: `... Customer-Slug locked auf "${customerSlug}". ...`,
handler: async (args) => {
// customerSlug im Closure gefangen, NICHT als Tool-Argument
const metrics = buildMetricsFromReport({ customerSlug, ... });
return await recordWorkerPerformance(metrics);
},
};
}
Der LLM sieht den Customer Slug nie als Parameter, den er schreiben kann. Der Slug ist zur Buildtime ins Tool eingebacken. Selbst wenn der Master Synthesizer mitten im Lauf halluziniert "eigentlich lass mich auch diesen Report für den anderen Kunden tracken", gibt es keinen Parameter, den er übergeben könnte, und keinen Pfad, der den Write in jemand anderes Bucket routen könnte. Das ist das gleiche Isolationsmuster, das wir für das Inline Tool fürs Analytics aus Session 1069 nutzen, und es hat uns über etwa dreißig Master Runs hinweg nicht einmal im Stich gelassen.
Für Defense in Depth validiert die Datenbankschicht zusätzlich noch das Slugformat selbst, falls jemand später ein Script baut, das die Library direkt aufruft, und versehentlich einen Wert übergibt, der wie ein Path Traversal aussieht. Unser Code Critic Agent hat das in derselben Session gefunden und mich gezwungen es einzubauen.
Was Phase 1 shippt, und was Phase 2 shippen wird
Phase 1, die gestern Nacht live ging, ist informativ. Der Master sammelt Performance Daten aus jedem Worker Report, den er liest, persistiert sie in einer neuen Tabelle sma_worker_performance mit einem harten Cap von 5000 Zeilen pro Kunde, damit der Speicher gebounded bleibt, und bietet eine Rankingsicht an für wen auch immer fragt. Die eigentliche Routinglogik, der Teil der entscheidet "feuere nur smasicht und smakonk für Tourismus Kunden", ist noch nicht verdrahtet. Die Flotte feuert weiterhin alle neun Agents pro Cycle.
Das ist absichtlich. Die Flotte ist erst eine Handvoll Male produktiv gelaufen. Wir haben noch nicht genug Daten um Schlüsse zu ziehen. Hätte ich Routing direkt geshippt, würden wir jetzt gegen ein Rauschmuster optimieren.
Phase 2 ist die Routingschicht. Sie wird in sma-run-all.ts leben, dem Script das den Cron Schedule feuert. Sie liest die Empfehlung aus der Rankingschicht, pickt die Top Zwei aus dem Website Modul plus alle drei aus dem GEO Modul plus die Top Zwei aus dem Business Modul, ein Default von sieben statt neun, und respektiert einen Anti Stale Guard. Jeder Worker, der seit sechzig Tagen nicht gelaufen ist, läuft trotzdem, egal welcher Rank. Das hält Exploration am Leben, auch nachdem Exploitation greift.
Die Kostenersparnis im Tokenbudget durch zwei Agents weniger pro Run, alle zwei Wochen, über zwei Kunden, liegt bei ungefähr zwanzig bis fünfundzwanzig Prozent weniger Tokens aus dem Anthropic Max Plan pro Cycle. Über das Jahr gerechnet entspricht das in etwa einem zusätzlichen Kunden an Spielraum im gleichen Flat Rate.
Worauf ich achten werde
Ein paar Dinge, die schiefgehen könnten und die ich abfangen will, bevor sie es tun.
Der Verify Confidence Score wird vom Worker selbst angegeben. Worker könnten lernen ihn aufzublasen, genauso wie Mitarbeiter lernen, was ihre Performance Metrik ist, und sie gamen. In unserem Fall wissen die Worker eigentlich nicht, dass der Score fürs Ranking benutzt wird. Der System Prompt erwähnt es nicht. Aber sobald wir das in den Prompt packen, taucht dieser Incentive auf. Ich werde die Signalquellen für das Ranking in den Worker Prompts unerwähnt lassen.
Die Regel "alle neun bei Cold Start" könnte uns einsperren. Wenn ein Kunde grundlegend nie den KI Visibility Agent braucht, weil er ein B2B SaaS ist ohne öffentliches Branding, wird das System ihn ewig feuern, ihn ewig niedrig scoren, und nie ganz die Schwelle überschreiten um ihn fallenzulassen. Eine zukünftige Verfeinerung ist ein Floor für niedrige Confidence. Wenn ein Worker über mehr als fünf Runs unter 0.4 liegt, frage den Master, ob er für oder gegen das Fallenlassen argumentiert, mit dem Kundenprofil im Kontext.
Die Gewichtung von 50 zu 30 zu 20 ist eine Vermutung. Nach zehn Cycles in Phase 2 sollten wir genug Varianz haben um zu fragen, ob die Aufteilung wirklich mit der Qualität des Berichts beim Kunden korreliert. Wenn nicht, sollten sich die Gewichte bewegen.
Der replizierbare Teil
Ich komme immer wieder hierauf zurück. Die Matheschicht sind zwölf Zeilen, das SQL ist eine Tabelle, die Integration sind zwei Inline Tools. Phase 1 zu shippen kostete eine fokussierte Session. Phase 2 wird ähnlich teuer, hauptsächlich weil das gesamte Plumbing für die Daten schon existiert.
Wenn du irgendeine Art Flotte aus mehreren Agents betreibst, ob es eine Pipeline für Customer Onboarding ist, eine Research Squad, ein System zur Content Generierung oder ein Code Review Orchestrator, dasselbe Muster greift. Du hast vermutlich schon irgendwo ein Signal für Confidence in deiner Pipeline, sei es Eval Scores, Judge Models, Retry Rates, Output Längen oder einfach eine selbst gemeldete Zahl. Du hast vermutlich schon ein Signal für Hygiene, also ist der Agent bei der Aufgabe geblieben, hat er Quellen zitiert, hat er mehr als 500 Zeichen tatsächlichen Content geschrieben? Was du nicht hast, bis du es einbaust, ist ein Record dieser Signale über die Zeit, normalisiert über Kunden oder Queries hinweg, und eine Funktion unter 100 Millisekunden, die den Record in eine Routingentscheidung verwandelt.
So sieht AutoML tatsächlich aus, wenn man es nicht von einem Vendor kauft. Es sieht aus wie eine Tabelle, eine Funktion und ein Guard. Das "ML" ist eine 1.96 KB große SQL Datei und ein Bayesianischer Schätzer, den ein Bachelor Student schreiben könnte. Das "Auto" kommt daher, dass niemand auf die Daten schauen muss. Das System aktualisiert sich bei jedem Run selbst.
Die Vendor Rechnung ist null, weil der LLM das Ding ist, das geroutet wird, nicht das Ding, das routet. Die Mathematik braucht kein Modell mit einer Milliarde Parametern. Sie braucht einen Prior, einen Counter und ein Sort.
Wenn du die volle Implementierung sehen willst, die Migration als SQL, das Wiring der Inline Tools am Master Synthesizer und die Test Suite, die Bayesianisches Smoothing, Extract Logik und Cold Start abdeckt, der Source von StudioMeyer Agents ist auf studiomeyer.io/services/agents dokumentiert. Oder wenn du ein ähnliches Muster für deine eigene Flotte gebaut haben willst, der gleiche Service erledigt die Umsetzung.
