Kategorie: Erklärer

Netflix betreibt Large Language Models in eigener Infrastruktur, nicht über externe APIs. Die Integration erfolgt tief in die bestehende Produktionsumgebung. Kein separater ML-Silo, sondern eine durchgängige Einbettung.

Der Netflix Technology Blog beschreibt vier Design-Entscheidungen: Wahl der Inference-Engine, Verpackung der Modelle, Gestaltung der API-Oberfläche und Deployment-Strategie. Jede baut auf der vorherigen auf. In der Theorie klar, zeigten sich unter Produktionslast unerwartete Nebenwirkungen.

Die Architektur im Überblick

Netflix betreibt ein einheitliches JVM-basiertes Serving-System für Routing, A/B-Tests, Candidate Generation, Feature Fetching, Inferenz, Post-Processing und Logging. Es gibt einen Echtzeit-Pfad (gRPC) und einen Batch-Pfad (HTTP). Kleine CPU-Modelle laufen direkt im Prozess des Serving-Systems – das spart Remote-Call-Overhead. Größere Modelle benötigen GPUs. Das Serving-System übernimmt Vor- und Nachbereitung, delegiert die Inferenz an den Model Scoring Service (MSS). MSS ist der gemeinsame Inference-Backend für XGBoost, TensorFlow, PyTorch und LLMs. Darunter liegt NVIDIA Triton Inference Server für Modell-Loading, Batching und GPU-Scheduling. Darüber ein Java-Control-Plane für Deployment, Versioning, Health Checks, Autoscaling und Multi-Region-Rollout. Modellautoren packen Artefakte und konfigurieren das Deployment; das Control Plane stellt GPU-Instanzen bereit, konfiguriert Triton und orchestriert Zero-Downtime-Upgrades.

Engine-Wahl: Warum vLLM der Standard wurde

Ursprünglich setzte Netflix auf TensorRT-LLM. Leistungsfähig, in Triton integriert. Bis Sommer 2025 hatten Open-Source-Engines den Performance-Vorsprung spezialisierter Stacks weitgehend aufgeholt. Der Workload-Mix wurde vielfältiger – Embedding-Generierung, Prefill-only-Inferenz für Ranking und Retrieval, autoregressives Decoding und kundenspezifische Modelle mit komplexer Constraint-Logik. Netflix benchmarkte erneut und wählte vLLM aus operativen Gründen: vLLM lädt benutzerdefinierte Modellarchitekturen ohne mehrstufige Compilation-Pipeline – das beschleunigt Iterationen bei nicht-standardisierten Modellen. Es bietet Erweiterungshooks für eigene Decoding-Logik, die für das spätere Constrained Decoding entscheidend sind. Die Debugbarkeit ist besser als bei einem kompilierten Engine wie TensorRT-LLM, weil Fehler und Zwischenzustände leichter inspizierbar sind. Viele ML-Praktiker nutzen vLLM bereits in der Forschung, was den Übergang zur Produktion vereinfacht.

Integration von vLLM in Triton: Zwei Wege, eine Entscheidung

Nach der Engine-Wahl musste Netflix entscheiden, wie die Modelle für vLLM verpackt werden. Triton unterstützt zwei Backends. Das Python-Backend erfordert, dass der Autor explizite Input/Output-Tensor-Spezifikationen zur Packzeit definiert. Diese Spezifikationen werden im Artefakt eingefroren und müssen mit dem Request-Builder des Frontends übereinstimmen. Jedes Frontend-Update, das I/O-Spezifikationen ändert, erfordert eine koordinierte Änderung des Verpackungscodes. Das vLLM-Backend erwartet nur eine JSON-Config, die auf Modellgewichte und Tokenizer verweist. Tritons vLLM-Backend generiert I/O-Tensor-Spezifikationen dynamisch zur Deployment-Zeit – der Autor definiert sie nie. Modelle und Frontend entwickeln sich unabhängig voneinander. Für Netflix ist das vLLM-Backend der architektonisch korrekte Standard. Zwei Probleme traten in der Produktion auf: Triton/vLLM-Versionsinkompatibilitäten (Tritons vLLM-Backend ist gegen eine spezifische vLLM-API-Version kompiliert) und benutzerdefinierte Modelllogik, die das Python-Backend erfordert, wenn das Modell nicht standardkonform ist. Dieser Escape-Hatch wird wohl für eine Teilmenge der Modelle nötig bleiben.

API-Design: OpenAI-kompatibel als zweite Front

Jedes Modell – XGBoost-Ensemble oder großes LLM – wird über denselben gRPC-Aufruf gescort. Das ermöglicht Wiederverwendung von Client-Bibliotheken, Health Checking und Deployment-Pipelines. Die OpenAI-kompatible API ist inzwischen der De-facto-Standard für das LLM-Ökosystem. Inference-Engines, Orchestrierungs-Frameworks, Evaluierungstools und Client-Bibliotheken sprechen sie alle. Netflix entschied sich, diese API als zusätzliches Frontend neben gRPC anzubieten. Der Vorteil: Der Weg von der Experimentierphase zur Produktion – von einem gehosteten Modell zu einem feinabgestimmten, selbst gehosteten – wird nahezu nahtlos. Gleiche API, minimale Code-Änderungen. Hinter der API nutzt Netflix das Triton OpenAI-kompatible Frontend von NVIDIA. Es startet einen eingebetteten Triton-Server, wickelt Requests in Triton-Inferenz-Requests um und liefert Antworten über FastAPI. Zusätzlich sind KServe-HTTP/gRPC-Frontends aktiv, sodass dieselbe Triton-Instanz auch über gRPC erreichbar bleibt. Eine Lücke zeigte sich: Das response_format-Feld wurde stillschweigend verworfen, bevor es vLLM erreichte. Ein Caller, der JSON-Output anforderte, bekam keine Guided-Decoding-Constraints – und konnte malformed JSON erhalten, ohne dass die Plattform einen Fehler meldete. Netflix patchte das Frontend, um response_format in vLLMs Guided-Decoding-Parameter zu übersetzen.

Deployment-Strategien: Rot-Schwarz oder Versioniert

GPU-Deployments brauchen länger zum Hochfahren als CPU-Dienste. Das I/O-Schema kann sich zwischen Modellversionen ändern – ein Koordinationsproblem. Netflix bietet zwei Strategien an. Red-Black deployt die neue Version neben der aktuellen. Wenn die neue Instanz die Health Checks besteht, wird der Traffic phasenweise umgeschaltet – die neue skaliert hoch, die alte herunter. Bei Fehlern erfolgt ein atomarer Rollback. Red-Black ist die richtige Wahl bei stabilem Modell-Interface. In der Praxis zeigte sich eine Koordinationslücke: Wenn eine neue Version ein I/O-Schema-Update erfordert (z.B. neue Tensor-Dimensionen), kann der Upstream-Consumer seine Konfiguration erst aktualisieren, wenn das neue Modell vollständig live ist. Während des Migrationsfensters sendet er „alte“ Requests an das „neue“ Deployment – die schlagen fehl. Versioned schließt diese Lücke, indem es für jedes (modelId, modelVersion)-Paar ein unabhängiges Deployment unterhält. Mehrere Versionen laufen gleichzeitig, was Modell-Deployment von Consumer-Updates entkoppelt: Der Consumer wartet, bis die neue Version bereit ist, dann schaltet er um. Die alte Version bedient solange Legacy-Traffic. Das erhöht temporär die GPU-Kosten. Netflix empfiehlt, variable Konfigurationen (z.B. Tensor-Shapes) direkt in das Inferenz-Modell einzubetten, um es versionsagnostisch zu machen, sodass der günstigere Red-Black-Pfad genutzt werden kann. Versioned bleibt seltenen Fällen mit breaking changes vorbehalten.

Operative Details: Boot-Sequenz und Metriken

Zwei operative Details verdienen besondere Aufmerksamkeit. Erstens die Boot-Sequenz: Das Herunterladen großer LLMs von S3 oder Hugging Face beim Start ist zu langsam – es übersteigt die Cold-Start-Latenz, die Scheduler tolerieren. Netflix materialisiert die Modelle auf Amazon FSx zum Zeitpunkt der Modell-Ankündigung, sodass Warm-Starts auf ein High-Performance-Dateisystem zugreifen. Wenn Consumer die OpenAI-kompatible API benötigen, läuft Triton als eingebetteter Server im OpenAI-Frontend-Prozess; sonst eigenständig. Der Rest der Boot-Sequenz ist mechanisch: Paket extrahieren, benutzerdefinierte vLLM-Plugins installieren, Prometheus-Multiprocess-Verzeichnis bereinigen und gRPC-Port erst öffnen, wenn die Engine bereit ist.

Zweitens die Metriken: vLLM schreibt Metriken in PROMETHEUS_MULTIPROC_DIR als .db-Dateien; Triton meldet Server-Metriken über einen eigenen Prometheus-Endpunkt. Keiner weiß vom anderen. Tritons eingebaute Brücke liefert nur 9 von über 40 vLLM-Metriken – wichtige wie Token-Durchsatz, KV-Cache-Auslastung und Prefix-Cache-Trefferquote fehlen. Netflix baute einen leichten HTTP-Proxy, der beide in einem einzigen /metrics-Endpunkt zusammenführt: Er holt Triton-Metriken über HTTP, liest vLLM-Metriken von der Festplatte mit Prometheus’ MultiProcessCollector und gibt die kombinierte Ausgabe zurück. Bestehende Dashboards und Alarme funktionieren ohne Änderung.

Constrained Decoding im Produktionsmaßstab

Einige Netflix-Produktionsworkloads erfordern fein granulare Kontrolle über die Token-Generierung. Statt Geschäftslogik nach der Inferenz anzuwenden – ungültige Generierungen bezahlen und dann wiederholen oder reparieren – schiebt Netflix die Constraints in die Decode-Schleife. Das Modell erzeugt Ausgaben, die von Natur aus konform sind. Umsetzung erfolgt über vLLMs Custom-Logits-Processor-Schnittstelle: Jede Constraint wird als Zustandsmaschine modelliert, die sich mit der generierten Token-Historie entwickelt und bei jedem Schritt Token-Eligibility-Masken ausgibt. Jeder Request bekommt seinen eigenen konfigurierten Processor, da verschiedene Requests unterschiedliche Regeln haben.

Die Skalierung dieser Constraint-Logik war eine Herausforderung. In der ersten Implementierung auf vLLM V0 lief die Logit-Processing pro Request – der GPU produziert Logits für den gesamten Batch, die CPU kopiert sie rüber und wartet auf den Transfer, dann läuft die Constraint-Logik sequenziell für jeden Request – sequenziell, weil die GIL Python daran hindert, die Arbeit pro Request zu parallelisieren. CPU-Zeit im Logit-Processing wurde zum Flaschenhals. Netflix migrierte später auf vLLM V1, das diese Einschränkung adressiert. Die Details der V1-Architektur und wie sie das Problem löst, sind im Originalblog nachzulesen – aber die Lektion ist klar: Nicht jeder Algorithmus, der funktioniert, skaliert auch linear. Besonders bei LLMs müssen Engine und Decoding-Logik aufeinander abgestimmt sein.

Was bedeutet das konkret?

Netflix zeigt, dass die Kontrolle über die gesamte LLM-Infrastruktur Vorteile bringt – wenn man bereit ist, in die Tiefe zu gehen. Die Entscheidungen sind nicht trivial, und unter Produktionslast tauchen immer wieder unerwartete Details auf. Der Vorteil ist eine Architektur, die nicht an die Grenzen eines Drittanbieters gebunden ist. Entwickler und Architekten können diese Erkenntnisse nutzen, auch wenn sie nicht im Netflix-Maßstab denken. Die Lektionen sind universell: Wähle eine Engine, die zu deinem Workload-Mix passt – nicht nur nach Benchmark-Zahlen. Setze auf standardisierte APIs, um den Ökosystem-Zugang zu öffnen. Baue Deployment-Strategien, die Schemamigrationen einkalkulieren. Teste die Skalierung von Constraints in der Decode-Schleife unter realistischer Last. Die Frage ist nicht, ob eigene LLMs betrieben werden sollten, sondern wie tief die Detailarbeit gehen muss. Netflix hat den Weg gezeigt.

Quelle: netflixtechblog.com

Eine Fabrik umzurüsten, während die Produktion läuft – so ähnlich fühlt es sich an, Code von einer Programmiersprache in eine andere zu übersetzen. Manuelles Vorgehen ist zeitaufwendig und fehleranfällig. Anthropic, das Unternehmen hinter dem KI-Assistenten Claude, setzt auf einen systematischen Prozess, der große Sprachmodelle mit Prüfmechanismen verbindet. Dieser Beitrag beschreibt, wie Anthropic solche Migrationen plant und umsetzt.

Der Ausgangspunkt jeder Migration ist nicht der erste Code, sondern ein verlässlicher Richter. Ohne ein klares Kriterium für den Erfolg tappt man im Dunkeln. Dieser Richter – „Judge“ genannt – muss alten und neuen Code nach denselben Maßstäben bewerten. Das klingt einfacher, als es ist: Testsuiten für die ursprüngliche Sprache greifen oft auf interne Funktionen zurück, die es in der Zielsprache nicht gibt. Anthropic löst das, indem es bestehende Tests kategorisiert: Welche lassen sich als externe Aufrufe formulieren? Welche hängen von Interna ab, die nicht portiert werden? Aus den brauchbaren Tests werden portable Assertions gebaut – Prüfungen, die gegen beide Versionen laufen. Und damit diese Prüfungen nicht schwächer werden, setzt man gegnerische KI-Agenten ein, die versuchen, die neuen Tests zu umgehen. Ein guter Judge besteht nicht nur den Originalcode, sondern fällt auch gezielt durch, wenn man manipulierten Code einschleust.

Ein konkretes Beispiel: Mike, ein Entwickler bei Anthropic, portierte einen Python-Code nach TypeScript. Da die vorhandenen Tests nicht einfach übertragbar waren, baute er ein kleines „Parity-Harness“ aus sieben realen Szenarien. Jede Abweichung im Verhalten galt als Bug. Das zeigt: Ein Judge muss nicht riesig sein, sondern treffsicher.

Der Sechs-Schritte-Plan: Vom Regelbuch zur finalen Prüfung

Anthropic hat den Prozess in sechs Schritte gegliedert, die auf zwei großen Migrationen basieren: Jarreds Portierung von Zig nach Rust (über 1.400 Dateien) und Mikes Python-zu-TypeScript-Übersetzung. Die Abläufe sind generalisiert, die Prinzipien gelten sprachübergreifend.

Schritt 1: Fundament legen – Regelbuch, Abhängigkeitskarte und Lückeninventar

Bevor eine Zeile Code geschrieben wird, entsteht ein Regelwerk. Es legt fest, wie die Übersetzung ablaufen soll. Es gibt zwei Szenarien: Entweder die neue Codebasis folgt derselben Struktur wie die alte (dann ist das Regelbuch eine Übersetzungstabelle für Typen und Idiome), oder sie wird komplett neu designt (dann ist es ein Architekturdokument). Jarred erstellte sein Regelbuch, indem er mit Claude diskutierte und für jede Unklarheit eine Policy formulierte. Acht spezialisierte Unteragenten prüften das Regelbuch auf typische Fehlermuster – basierend auf Jarreds eigener Erfahrung.

Parallel entsteht eine Abhängigkeitskarte. Denn wenn man mehrere Dateien parallel migriert, muss man wissen, welche Dateien zuerst kommen müssen. Für moderne Sprachen gibt es oft Manifestdateien, aber bei Legacy-Codebasen oder Sprachen wie C/C++ und Python müssen die Abhängigkeiten erst ermittelt werden. Claude Code kann hier Agenten losschicken, die ein deterministisches Skript schreiben und ausführen, um die Karte zu erstellen.

Zum Fundament gehört auch das Lückeninventar: Welche Konzepte der alten Sprache haben in der neuen keine direkte Entsprechung? Beispiel: Python verlangt keine Verträge über die Form von Objekten oder Rückgabewerten, TypeScript schon. Solche impliziten Annahmen müssen erfasst werden. Jarred inventarisierte die Lücken vor der Übersetzung, Mike übersetzte erst und auditierte dann. Beide Vorgehensweisen sind möglich, oft eine Kombination sinnvoll.

Schritt 2: Die Generalprobe – Regeln im Kleinen testen

Bevor der große Angriff startet, folgt ein Stresstest. Drei Dateien werden nach dem Regelbuch übersetzt, drei weitere von einem Agenten, der sich wie ein „Senior Rust Engineer“ verhält. Aus dem Unterschied zwischen beiden Versionen werden neue Übersetzungsregeln abgeleitet. Dieser Schritt deckte bei Jarreds Migration zwei kritische Probleme auf, die sonst tausendfach durchgeschlagen wären. Die erzeugten Dateien werden verworfen. Ziel ist es, die Regeln zu schärfen, nicht Fortschritt zu machen.

Für Design-getriebene Migrationen (wie Mikes) ist der Ersatztest eine konfrontative Prüfung des Entwurfsdokuments durch gegnerische Gutachter, gefolgt von einem komplett durchlaufenen E2E-Durchlauf, der ebenfalls verworfen wird.

Schritt 3: Die Übersetzungswelle

Jetzt geht es an die Massenfertigung. Eine Multi-Agenten-Schleife aus Implementierung, Review und Korrektur kommt zum Einsatz. Die Implementierer können kleinere, günstigere Modelle sein – Anthropic nutzte hier Claude Sonnet für zwölf Subagenten. Die Warteschlange ist mechanisch: Ein Batch-Skript prüft, ob die Zieldatei bereits auf der Festplatte existiert, und teilt die restlichen Dateien in Batches auf. Die Migration ist jederzeit fortsetzbar, auch nach einem Abbruch.

Ein Problem: Agenten neigen zur Übervorsicht. Die Lösung ist eine deutliche Anweisung: „Der Compiler fängt Fehler im nächsten Schritt – mach einfach.“ Alles, was der Übersetzer nicht sicher kann, markiert er mit // TODO(port): <Grund>. Diese offenen Punkte werden in Schritt 4 abgearbeitet. Zwei gegnerische Reviewer bewerten die Arbeit der Implementierer. Wenn ein Reviewer immer denselben Fehler sieht, wird nicht jede Datei einzeln geflickt, sondern das Regelbuch um einen Satz ergänzt und der betroffene Batch neu generiert. Der Code wird niemals von Hand gegen das Regelbuch korrigiert.

Ein wichtiger Design-Entscheid: Wo sitzt der Compiler? Mike ließ den TypeScript-Compiler in jeder Schleife laufen (weil er in Sekunden fertig ist), Jarred verbannte ihn aus der Schleife (weil cargo Minuten braucht) und verschob ihn in den nächsten Schritt.

Schritte 4–6: Kompilieren, Testen, Verhalten abgleichen

Diese drei Schritte teilen sich dieselbe Schleifenarchitektur und brauchen zunehmend weniger menschliches Eingreifen. Schritt 4 (Kompilieren) kann je nach Sprache und Umfang in Schritt 3 aufgehen. Bei Jarred rief ein Orchestrator-Skript den Compiler einmal über das gesamte Workspace auf. „Fixer Agents“ arbeiteten die Fehlerliste parallel ab, wieder mit gegnerischem Review. Dabei half es, systematische Fehler zu erkennen – zum Beispiel Tausende von Rust-Modul-Fehlern, die durch zyklische Importe entstanden, welche Zigs lazy compilation toleriert hatte. Der Fix war eine Logik im Loop, die entscheidet, welche Abhängigkeit gelöscht, verschoben oder neu strukturiert wird.

Schritt 5 (Ausführen) hat eine ähnliche mechanische Wahrheitsquelle: Abstürze aus dem Smoke-Test. Wieder werden die Fehler nach Ursache gruppiert und durch gegnerische Subagenten geprüft. Schritt 6 vergleicht das Verhalten beider Codebasen. Die übersetzten Dateien sind kompiliert, getestet – jetzt wird die Testsuite aus dem Prerequisites-Schritt gegen sie laufen gelassen. Fixer Agents untersuchen fehlgeschlagene Tests anhand beider Codebasen. Ein Build-Daemon ist der einzige Prozess, der das Binary neu bauen darf. Die Fixer schreiben Patches, der Daemon sammelt sie, baut einmal neu, führt die betroffenen Tests aus und liefert die Ergebnisse zurück. Das serialisiert den teuersten Vorgang.

Wiederholt sich derselbe Fehler in vielen Tests, wandert der Fix nach oben: Die Regel, die den Bug verursacht hat, wird geändert und nur die Dateien werden neu generiert, die diese Regel betrifft. Mikes Ansatz ist hier aufschlussreich: Da er keine portierte Testsuite hatte, ließ er Claude ein kleines Skript bauen, das sieben reale Szenarien gegen beide Versionen laufen ließ und die Ergebnisse per Diff verglich. Jedes fehlschlagende Szenario bekam einen eigenen Fix-Agenten. Dann ging er noch weiter: Claude entwarf eine eigene E2E-Testsuite und ließ sie autonom über Nacht laufen, reparierte, was kaputtging, und wiederholte das vier Nächte lang. So wurden auch die kleinen Fehler erwischt, die keine Szenarioliste vorhergesehen hätte. Fehlt eine Testsuite, baut Claude eine.

Best Practices für Code-Migrationen

Jede Migration lehrt etwas Neues. Einige Grundsätze haben sich bei Anthropic bewährt:

• Befolge diesen Leitfaden nicht blind. Jede Migration ist anders. Nutze die Struktur als Ausgangspunkt und plane deine spezifische Migration mit Claude, bevor du loslegst.
• Konzentriere dich nicht auf einzelne Fehler. Einzelfehler sind der Job der Fixer-Agenten. Deine Aufmerksamkeit gehört den Mustern.
• Mache Reviews gegnerisch und Verifikation mechanisch. Gegnerisches Review lohnt sich bei langlebigen Aufgaben oft. Lass Skripte – Compiler, Diff, Testsuite – den Schiedsrichter spielen.
• Nutze nicht das größte Modell für alles. Tokens kosten Geld, besonders in Schleifen. Kleinere Modelle bewältigen die Massenimplementierung gut; spare dir das große Modell für Reviewer und für alles, was Regeln schreibt, die andere Agenten befolgen.
• Investiere Zeit am Anfang. Das Regelbuch und der Stresstest sind der zeitaufwändigste Teil. Danach brennen im Wesentlichen die Warteschlangen ab.
• Mache die Warteschlange mechanisch und fortsetzbar. „Erledigt“ bedeutet: Die Ausgabedatei existiert auf der Festplatte.

Ergebnisse und Einordnung

Jarreds Bun-Migration läuft inzwischen in Produktion. Keine Migration ist perfekt: Etwa 4 % des Rust-Codes liegen in „unsafe“-Blöcken – meist einzeilige Zeigeroperationen an C/C++-Grenzen. Aber die neue Codebasis ist messbar besser. Alle vom Tooling erfassbaren Speicherlecks sind behoben: Ein Benchmark mit 2.000 Wiederholungen sank von 6.745 MB Speicher auf 609 MB. Das Binary ist auf Linux und Windows 19 % kleiner. Sprachübergreifende Optimierungen brachten 2–5 % mehr Geschwindigkeit bei HTTP-Serving und realen Workloads.

Wenn du vor einer ähnlichen Aufgabe stehst – Legacy-System in eine moderne Sprache überführen oder kritische Infrastruktur erneuern –, zeigt dieser Prozess, dass KI nicht nur beim Schreiben von Code hilft, sondern vor allem bei der Systematik. Die Kunst liegt nicht im Übersetzen, sondern im Entwerfen der Regeln und Prüfmechanismen. Der Rest ist Mechanik – und die kann man automatisieren.

Quelle: claude.com

Du kaufst eine teure Küchenmaschine, aber hast kein Rezept und keine Ahnung, wie sie funktioniert. Was bringt dir das Gerät? Nichts. Mit KI-Modellen ist es ähnlich. Unternehmen hören ständig von neuen Sprachmodellen. Entscheidend ist nicht, welches das beste ist, sondern wie sie es gewinnbringend einsetzen. Hier liegt ein Milliardengeschäft, das jetzt Gestalt annimmt.

Anthropic, das Labor hinter Claude, hat mit Blackstone, Hellman & Friedman und Goldman Sachs ein Joint Venture gegründet: Ode. Die Firma soll KI in Unternehmen implementieren. 1,5 Milliarden Dollar schwer, versteht sich Ode als Übersetzer zwischen Technologie und betrieblicher Realität. Die Beteiligung der Private-Equity-Häuser ist kein Zufall. Sie wollen ihre Portfoliounternehmen produktiver machen und sehen in Ode den Schlüssel dazu.

Die Idee entstand bei Blackstone. Der Finanzinvestor sah, dass große Beratungshäuser und kleine KI-Boutiquen oft an der Umsetzung scheiterten. Eine Boutique, Fractional AI, stach hervor. Ode übernahm Fractional und machte sie zum Kern. Fractional hatte zuvor mit OpenAI zusammengearbeitet. Chris Taylor, CEO von Ode und Mitgründer von Fractional, sagt: „Wenn wir richtig umsetzen, könnte dies irgendwann ein Billionen-Dollar-Unternehmen werden.“ Nicht das Modell ist der Hebel, sondern die Dienstleistung drumherum. Taylor betont: Nicht-KI-Unternehmen können große Gewinner sein, wenn sie die Technologie richtig adaptieren.

Ode beschäftigt rund 100 Ingenieure. Das Team arbeitet eng mit Anthropics angewandter KI-Abteilung zusammen, um maßgeschneiderte Systeme zu entwickeln. Anders als reine Beratung geht es um technische Umsetzung: Code, Integration, Testing. Ein idealer Kunde ist ein Unternehmen, dessen CEO persönlich von der KI-Transformation überzeugt ist. „Vieles, was wir tun, ist die oberste Priorität des CEOs“, sagt Taylor. Es geht um die wichtigsten Produktfeatures der nächsten zwei Jahre oder die Neugestaltung zentraler Geschäftsprozesse. Das ist kein Experiment am Rande. Die Private-Equity-Partner führen ihre Portfoliounternehmen als Kunden zu, doch der Markt steht allen offen.

Eine Besonderheit: Ode arbeitet „Claude-first“ mit Anthropics Technologie. Aber die Firma ist nicht dogmatisch. Wenn ein anderes Modell besser passt, wird es genutzt. Eddie Siegel, Chief Technologist bei Ode, erklärt: Die Modellauswahl sei nur eine Zutat in einem komplexen System – vergleichbar mit der Wahl zwischen Python und Java. Nicht unwichtig, aber nicht entscheidend. Die wahre Kunst liegt in der Qualität der Implementierung. Siegel spricht von „erwachsenen Ingenieuren“ – Spezialkräften, die ein Problem von Anfang bis Ende verstehen und lösen können. Über die Hälfte des Teams sind ehemalige Gründer, die unternehmerisch denken gelernt haben. Diese Denkweise erinnert an die alte Schule der Softwareentwicklung, wo man das volle Problem löste.

Quelle: techcrunch.com

Öffnest du die Motorhaube eines modernen Autos, um das Bremssystem zu verstehen, siehst du tausende Kabel, Schläuche und Steuergeräte – aber wo genau sitzt die Logik, die bei einer Vollbremsung die Räder blockiert? Genau so geht es Entwicklern, die den Quellcode eines KI-Agenten studieren. Sie sehen Tausende von Dateien, aber die entscheidende Frage „Fragt der Agent den Benutzer, bevor er eine Datei löscht?“ ist nicht auf einen Blick zu beantworten.

Das Problem ist nicht fehlender Code. Es ist die fehlende Verbindung zwischen was das System tut (seinem Verhalten) und wo dieses Verhalten im Code umgesetzt wird. Ein Forscherteam um Ruhan Wang von Tencent HY LLM Frontier entwickelte dafür das Harness Handbook. Es ist kein weiterer Code-Index, sondern eine navigierbare Verhaltenslandkarte. Sie ordnet den verstreuten Implementierungscode in logische Verhaltenseinheiten und verknüpft jeden Schritt mit überprüfbaren Codebelegen. So können Entwickler, Auditoren und andere KI-Agenten das System verstehen, überprüfen und anpassen – ohne sich durch 2000 Dateien quälen zu müssen.

Warum ein Agenten-Harness ein Handbuch auf Verhaltensebene braucht

Bei KI-Agenten denken wir oft zuerst an die Fähigkeiten des Modells. Sobald der Agent echte Arbeit erledigt, verschiebt sich die Frage: Nicht „Was kann das Modell?“, sondern „Was erlaubt das System dem Modell zu tun?“. Ob ein Befehl ausgeführt wird, ob der Benutzer um Erlaubnis gefragt wird oder ob ein Fehler abgefangen wird – das entscheidet nicht das Modell allein, sondern der sogenannte Harness, die ausführende Hülle um das Modell herum.

Ein solcher Harness ist nicht trivial. In einem Produktionssystem wie Codex – hier als Beispiel – koordiniert der Harness das Modell, die Werkzeuge, den Zustand, die Berechtigungen und die Ausführungsumgebung. Das Ergebnis: 2.267 Dateien, über 34.000 Funktionen und fast 160.000 Code-Verbindungen. Eine klassische Dateistruktur zeigt nur, wo Code liegt, nicht wie die Teile zusammenwirken, um ein bestimmtes Verhalten zu erzeugen. Suchst du nach „delete“ oder „confirm“, erhältst du Fragmente, die du mühsam zusammensetzen musst.

Besser: Starte beim Verhalten und folge den Spuren zurück zum Quellcode. Genau das bietet das Handbook. Es erfüllt drei Zwecke: Verstehen – wie der Harness einen Benutzerauftrag durchläuft. Auditieren – ob die Sicherheitsversprechen der Dokumentation tatsächlich im Code eingehalten werden. Anpassen – um einen eigenen Agenten auf Basis des bestehenden Harness zu bauen. Alle drei Zwecke beginnen mit einer konkreten Verhaltensfrage und enden im Code als Beleg.

Warum ist ein Verhalten an so vielen Stellen verstreut?

Die Regel „Frage den Benutzer, bevor du eine Datei löschst“ klingt einfach. Um sie im Code zu überprüfen, musst du eine Kette von Entscheidungen nachvollziehen: Fordert das Modell eine Bestätigung an? Kann der Werkzeugaufruf abgefangen werden? Wo wird die Benutzerantwort gespeichert? Unter welchen Bedingungen wird die Löschung endgültig ausgeführt? Jedes Glied dieser Kette kann das Ergebnis verändern.

Ein Verhalten wird nicht von einer einzigen Funktion entschieden. Es wird gemeinsam von Prompts, Tool-Wrappern, Berechtigungskonfiguration, Zustandsverwaltung, Sandbox-Ausführung und Fallback-Pfaden bestimmt. Es gibt keine Funktion confirmBeforeDelete(). Du musst Prompts, Wrapper, Berechtigungen und Zustand bis zur Sandbox-Ausführung und zu den Ausweichpfaden verfolgen, bevor du sagen kannst, ob die Anfrage ausgeführt, abgelehnt oder in einen anderen Fluss umgeleitet wird.

Die Forscher nennen diese Suche Behavior Localization. Die Vollständigkeit der Rekonstruktion bestimmt die Qualität der Erklärung, der Risikoanalyse und der Änderungsgrenzen. Das Harness Handbook verwandelt diese versteckten Verhaltensketten in eine Karte, die du Schicht für Schicht durchblättern und gegen den Quellcode prüfen kannst.

Harness Handbook: Eine navigierbare Verhaltenskarte

Da ein einzelnes Verhalten viele Implementierungsorte haben kann, kann das Handbook nicht einfach den Dateibaum neu verpacken. Stattdessen stellt es den Harness aus Verhaltensperspektive dar, mit drei Ebenen – L1, L2, L3 – die die Frage Schritt für Schritt eingrenzen. Jede Ebene bewahrt überprüfbare Codebelege, sodass du jede Erklärung nachvollziehen und spätere Änderungen im Quellcode verankern kannst.

L1 – Systemüberblick: Statt Dateien und Funktionen aufzulisten, folgt L1 einem Benutzerauftrag durch das gesamte System: Wie tritt der Auftrag ein, welche Stufen durchläuft er, wie bewegt sich der Zustand zwischen ihnen, und wie wird die Modellausgabe zu einer echten Aktion? Sie beantwortet zuerst: Wie läuft dieser Harness im Ganzen ab?

L2 – Verhaltenseinheiten-Überblick: Diese Ebene zerlegt den Systemablauf in Verhaltenseinheiten. Jede Einheit erfasst eine zusammenhängende Klasse von Verhalten und dokumentiert ihre Verantwortlichkeiten, Ein- und Ausgaben, Abhängigkeiten und Schlüsselzustände. Auf dieser Ebene siehst du, wie komplexes Verhalten zerlegt wird und wie die Teile im Gesamtablauf wieder zusammenhängen.

L3 – Verhaltenseinheit im Detail: Hier zoomst du in eine einzelne Einheit hinein: Wann ein Verhalten ausgelöst wird, wie es ausgeführt wird, wie sich der Zustand ändert, welcher Pfad nach einer Ausnahme oder einem Fehler genommen wird und welche Dateien und Funktionen den Beleg liefern. „Vor dem Löschen einer Datei bestätigen“ ist keine allgemeine Regel mehr, sondern eine überprüfbare Kette einzelner Entscheidungen.

Ein konkretes Beispiel aus der Arbeit der Forscher: Die L3-Einheit für „Bestätigung vor Dateilöschung“ listet auf, welcher Trigger (das Modell sendet delete_file(path)), welche Berechtigungsregel (Dateilöschung ist als risikoreich markiert), welche Zustandsänderung (Bestätigungsanfrage und Antwort werden aufgezeichnet), welcher Ausführungspfad (Benutzer genehmigt → Sandbox-Runner, Ablehnung → Abbruch) und welche Randfälle (Headless-Modus, Auto-Approval) relevant sind. Für jeden Schritt gibt es Code-Belege wie tools/file_ops.py:32-78.

Wie wird die Verhaltenskarte aus dem Code erzeugt?

Damit das Handbook vertrauenswürdig ist, darf

Quelle: ruhan-wang.github.io

Du installierst eine neue Software, liest dich durch eine ellenlange Dokumentation und fühlst dich wie ein Tourist ohne Karte. Die meisten Produkte setzen darauf, dass du dir das Wissen selbst aneignest. Bei MCPs – Model Context Protocols – war das bisher nicht anders. Doch das ändert sich gerade.

Der Autor des ursprünglichen Beitrags, Moe, CTO bei Webhound, hat in den letzten Wochen gearbeitet, das Onboarding seines Produkts für KI-Agenten nahtlos zu gestalten. Er entdeckte mehr als nur eine Verbesserung. Der Nutzer interagiert nicht mehr direkt mit dem Produkt, sondern ein Agent übernimmt: Er erfasst die Absicht des Nutzers und setzt sie auf einer vom Produkt bereitgestellten Oberfläche um. Das wirft bisherige UX-Prinzipien über den Haufen – Touchpoints, Edge Cases, Frustrationsquellen. Es entsteht ein völlig neues Problemfeld.

Der Fehler der traditionellen MCP-Dokumentation

MCPs haben ihre Nutzer beim Einstieg oft vernachlässigt. Die meisten setzen auf API-Dokumentation, die man mühsam durcharbeiten muss. Niemand liest freiwillig Endpunkt-Beschreibungen, nur um ein Tool zum ersten Mal zu benutzen. Moe hält das für falsch. Onboarding soll den Umgang mit dem Produkt vermitteln. Die besten Beispiele haben immer das Produkt selbst in den Onboarding-Prozess integriert. Warum bei MCPs anders?

Seine Lösung ist einfach: Er baute ein Onboarding-Tool direkt ins MCP ein. Es führt den Agenten Schritt für Schritt durch die erste Nutzung. Danach kennt der Nutzer das Produkt und hat bereits einen echten Mehrwert daraus gezogen. Der Agent navigiert den Nutzer sicher durch den Einstieg – ohne dass vorher die Landkarte studiert werden muss. Das ist bequemer und effektiver.

Den Arbeitsbereich des Nutzers verstehen

Jeder Nutzer hat eine andere Arbeitsumgebung, andere Ziele und Motivationen. Jede Sitzung eines Agenten startet mit anderen Gedanken. Der Arbeitsbereich sollte so eingerichtet sein, dass der Nutzer den größten Nutzen aus dem Produkt zieht. Agenten sind darauf programmiert, Code zu schreiben und einen Rechner zu bedienen – sie brauchen nur die richtigen Anweisungen. Diese Anleitung muss das Onboarding liefern.

Moes Ansatz: Der Onboarding-Prozess fordert den Agenten auf, den Nutzer um Erlaubnis zu bitten, eine Meta-Analyse des Arbeitsbereichs durchzuführen – komplett lokal, ohne dass Daten an den Server gesendet werden. Danach gibt der Agent Vorschläge, wie der Nutzer seine Umgebung anpassen kann, um das volle Potenzial des Produkts zu nutzen. Stimmt der Nutzer zu, führt der Agent die Änderungen aus. Das respektiert die Privatsphäre und schafft Vertrauen. Vertrauen ist die Grundlage jeder Beziehung.

Das erste Vertrauen als Kipppunkt

Moe ist überzeugt, dass der Moment des ersten Vertrauens entscheidet, ob ein Nutzer bleibt. Die Bitte um Erlaubnis ist ein Teil davon. Ein noch größerer Teil – vor allem wenn man die lokale Arbeitsumgebung verändert – ist die einfache Rückgängigmachbarkeit. Ein funktionierendes Produkt unterscheidet sich von einem Virus dadurch, wie leicht man es wieder loswird. Deshalb sollte jedes MCP so gestaltet sein, dass es sich mühelos deinstallieren lässt.

Für sein Team hat Moe einen Endpunkt geschaffen, der dem Agenten die gleiche Schritt-für-Schritt-Anleitung bietet – nur diesmal rückwärts. Der Agent entfernt alle Regeln, Dateien und Einstellungen, die das MCP mitgebracht hat, und löscht sich selbst. Der Nutzer kann jederzeit zum Ausgangszustand zurückgehen, ohne Angst haben zu müssen, dass sein System verseucht bleibt. Das zeigt Respekt für die Kontrolle des Nutzers über sein Gerät.

Ein lebendiges Dokument für die Hilfe

Moe betont die Bedeutung eines sogenannten „Company Brains“. Viele Unternehmen haben umfangreiches Wissen in Code-Kommentaren und internen Dokumenten gespeichert. Ein Agent, der darauf zugreifen kann, kennt das Produkt so gut wie die Entwickler selbst. Falls so etwas noch nicht existiert, reicht es, den Agenten zu öffnen, ihm per Sprache das gesamte Wissen über das Produkt zu diktieren und ihn den Code analysieren zu lassen. Das schafft einen Kontext.

Diesen Wissensschatz sollte man über das MCP zugänglich machen: einen Help-Endpoint, der FAQ, Produktinfo und alles andere enthält, was Nutzer fragen könnten. Und das Ganze sollte ein lebendiges Dokument sein – regelmäßig aktualisiert, mit neuen Erkenntnissen und Feedback der Nutzer. Wenn ein Agent sofort die richtige Antwort parat hat, schätzt man das Produkt. Es wirkt wie ein persönlicher Assistent.

Ein realistischer Blick in die Zukunft

Agenten-Erst-Interfaces sind noch neu. Moe selbst räumt ein, dass seine Erkenntnisse in Zukunft widerlegt werden könnten. Sollte das passieren, würde er den Fehler eingestehen und das Produkt anpassen. Das zeigt Demut und Offenheit für Diskussion. Er lädt alle ein, ihre Gedanken zu teilen.

Für den Nutzer bedeutet das: Die Tür steht offen. Produkte, die MCPs auf diese Weise gestalten, respektieren Zeit, Privatsphäre und Arbeitsumgebung. Man muss nicht mehr stundenlang Dokumentationen wälzen, sondern wird direkt in die Nutzung geführt. Der Agent wird zum Verbündeten, nicht zum Hindernis. Und wenn es nicht passt, verschwindet er spurlos.

Das klingt nach einer menschenzentrierten Technologie. Der Einstieg ist nicht mehr Hürde, sondern Beginn einer produktiven Zusammenarbeit. Das macht MCP Onboarding zu einer interessanten Entwicklung – wegen des menschenzentrierten Ansatzes.

Wer ein Produkt mit diesen Prinzipien nutzt, wird sich fragen, warum es nicht schon immer so war. Bisher stand das Produkt im Mittelpunkt, nicht der Mensch. Das ändert sich jetzt. Das ist ein Fortschritt.

Quelle: moekhalil.substack.com