Part of the DEPLOY Method — Engineer phase
Fast niemand hat ein Multi-Agent-System im Produktionsmaßstab ausgeliefert. Die Distanz zwischen einer LangGraph-Demo, die im Notebook funktioniert, und einem System, das für zahlende Kunden läuft, ist genau die Stelle, an der jedes andere Team ins Stocken gerät — und sie gerät aus Gründen ins Stocken, die erst offensichtlich werden, wenn man eines gebaut hat. Das sind die ENGINEER- und PILOT-Phasen der DEPLOY Method, verdichtet auf ein 12-wöchiges eingebettetes Engagement für Teams, die bereits einen Agent-Prototyp mit echten Nutzern haben und ihn industrialisieren müssen. Ich habe Auralink architektiert — 1,7 Millionen Zeilen Produktionscode, rund 20 autonome Agenten, die 78 % der Vorfälle ohne menschliches Eingreifen lösen, peer-reviewed auf arXiv. Ein vergleichbares Multi-Agent-System existiert heute nicht in Produktion. Die Arbeit, die ich mit Ihrem Team leiste, ist dieselbe Arbeit, die ich mit meinem geleistet habe — adaptiert auf Ihre Codebasis, Ihre Agenten und Ihre operativen Randbedingungen. Ich habe acht KI-Ventures in die Produktion gebracht. Ich weiß, welche Entscheidungen aufgeschoben werden können und welche Sie sechs Wochen nach Launch einholen, wenn Sie sie jetzt überspringen.
Jede Agent-Demo funktioniert im Notebook und zerfällt unter produktivem, gleichzeitigem Traffic. Das Tutorial nutzt synchrone Calls, einen einzigen Happy-Path und gemockte Tools. Produktion fährt Dutzende Agent-Sessions parallel, jede mit echten Tool-Aufrufen und echten Failure Modes, und das naive Orchestrierungsmuster, das in der Demo sauber wirkte, wird zu einer donnernden Herde aus Retries, Deadlocks und halb-committetem Zustand. Ihr Team weiß, dass das ein Problem ist, und hat die Referenzarchitektur dafür nicht.
Ihre Eval-Strategie für Single-Turn-LLM-Calls lässt sich nicht auf mehrstufige Agent-Trajektorien ausdehnen. Sie können einen Prompt bewerten. Sie können noch keinen 14-Schritte-Plan bewerten, bei dem der fünfte Schritt das falsche Tool wählte, der neunte das falsche Argument übergab und die Endantwort dennoch technisch korrekt war. Fehler in Agent-Trajektorien akkumulieren sich über Schritte, und die Eval-Methodik aus Single-Turn-Arbeit erzeugt irreführende Scores. Ohne Trajektorie-basierte Evaluation können Sie nicht sagen, ob ein Modell-Update das System verbessert oder verschlechtert hat, und Sie können nicht mit Vertrauen ausliefern.
Die Kosten pro Aufgabe explodieren unvorhersehbar, weil jeder Agent-Schritt den Token-Verbrauch multipliziert. Eine einzelne Nutzeranfrage löst einen Plan aus, der Tool-Aufrufe auslöst, die Sub-Agenten auslösen, die weitere Tool-Aufrufe auslösen. Ihre Token-Zahl pro Session liegt jetzt beim 40-fachen eines regulären LLM-Calls, und Ihr CFO möchte ein Modell, das erklärt, warum ein Power-User letzten Dienstag 18 € an Tokens kostete. Sie haben keine Instrumentierung, um das zu beantworten — kein Schritt-für-Schritt-Token-Accounting, keine Routing-Logik, die günstigere Modelle für einfachere Schritte wählt, keine Budget-Caps, die sauber abfangen, wenn eine Session außer Kontrolle gerät.
Wenn ein Agent in Produktion etwas Falsches tut, fehlt der Observability-Stack, der Ihnen sagt, welcher Schritt, welcher Prompt, welcher Tool-Aufruf es verursacht hat. Der Nutzer beklagt, „der Agent hat eine seltsame Antwort gegeben“. Ihre Logs zeigen die Endantwort und sonst nichts. Sie können die Trajektorie nicht reproduzieren, weil der Agent nicht-deterministisch ist. Sie können nicht sagen, ob der Bug im Planner, im Tool-Router, in der Retrieval-Schicht oder in einem bestimmten Prompt-Template liegt. Jeder Vorfall wird zu einer mehrtägigen Forensik-Übung, und Ihr Team verliert das Vertrauen in das System schneller als die Nutzer.
Das Engagement läuft in vier dreiwöchigen Phasen. Ich arbeite eingebettet mit Ihrem Engineering-Team — Ihre Engineers bauen, ich bringe Topologie-Entscheidungen, Eval-Methodik und Observability-Muster aus Auralink. Keine Arbeit entsteht auf einer Beratungsfolie. Am Ende von Woche zwölf betreibt Ihr Team das System ohne mich.
Ich gehe tief in Ihren aktuellen Prototyp — der Agent-Graph, das Tool-Inventar, das State-Management, die bereits aufgetretenen Failure Modes. Ich liefere ein schriftliches Topologie-Design: welche Agenten, welche Verantwortlichkeiten, welche Kommunikationsmuster, welche Zustandsgrenzen, welche Failure-Isolation-Zonen. Das Design ist spezifisch für Ihre Domäne und Ihre Codebasis, keine aus einem Blog-Post kopierte Referenzarchitektur. Am Ende von Woche drei verfügt Ihr Team über einen Bauplan, den es vor einem Senior Reviewer verteidigen kann, und einen Migrationspfad vom aktuellen Prototyp, der kein Rewrite verlangt.
Ihre Engineers implementieren die Topologie. Ich arbeite neben ihnen an den härteren Calls — den Orchestrierungs-Primitiven, der Concurrency-Strategie, der State-Machine für langlaufende Sessions, der Retry- und Kompensations-Logik bei Tool-Fehlern. Wir liefern ab Woche fünf inkrementell gegen echten Traffic aus, kein Big-Bang-Cutover in Woche sieben. Am Ende von Woche sieben bedient die neue Topologie produktiven Traffic, und der alte Prototyp ist außer Betrieb.
Trajektorie-basierte Evaluation, gebaut auf den Mustern, die ich für Auralink entwickelt habe — Evaluation pro Schritt, Ground-Truth-Trajektorien für Regressionstests, LLM-as-Judge mit kalibrierten Prompts und die statistische Methodik, mit der Sie sagen können: „Dieses Modell-Update verbesserte das System um 4,2 % bei p < 0,01“ statt „Die neue Version fühlt sich besser an“. Token-Accounting pro Schritt und Cost-per-Task-Dashboards, damit Ihr CFO die Fragen beantworten kann, die kommen werden. Ihr Team fährt die Eval ab Woche neun bei jeder Änderung.
Der Observability-Stack, den Ihr On-Call-Engineer nutzen wird, wenn der Pager um 3 Uhr losgeht — Trajektorie-Traces, die an User-Sessions geknüpft sind, Prompts und Completions pro Schritt, Eingaben und Ausgaben von Tool-Aufrufen, Token-Accounting, Latenz-Breakdowns, Kostenzuordnung. Runbooks für die Top-10-Incident-Typen, die Ihr System produzieren wird. Arbeitssitzungen mit Ihrem SRE-Team, damit es Alarmschwellen, Dashboards und Incident-Response-Playbooks besitzt. Wenn ich gehe, betreibt Ihr Team das System. Kein Retainer, keine laufende Abhängigkeit.
Enterprise-Technologieorganisationen und Series-B+-Startups mit einem Agent-Prototyp, der echte Nutzer hat, Budget für ein 12-wöchiges eingebettetes Engagement und ein Engineering-Team mit der Kapazität, das System nach Übergabe zu besitzen. Produktteams, bei denen CTO oder VP Engineering bereits an die Wand zwischen „Agent-Demo funktioniert“ und „Agent-System operiert“ gestoßen ist und erkannt hat, dass diese Lücke ein Topologie-, Eval- und Observability-Problem ist — kein Prompt-Engineering-Problem. Das ist nicht für Teams ohne LLM-Produktionserfahrung — diese brauchen zuerst das Readiness-Audit oder den Strategy Sprint. Es ist auch nicht für Teams ohne bestehende Codebasis; das Engagement setzt einen zu industrialisierenden Prototyp voraus, keinen Greenfield-Build.
Nicht sonderlich. Das Orchestrierungs-Framework ist ein Vehikel — die Entscheidungen, die zählen, sind Topologie, State-Management, Eval-Methodik und Observability. Ich habe über die großen Frameworks hinweg und mit eigenem Orchestrierungscode gearbeitet. In Woche eins bewerte ich, ob Ihr aktuelles Framework das richtige Vehikel ist für den Ort, an den Sie wollen; manchmal lautet die Antwort ja und wir bauen darauf auf, manchmal lautet die Antwort, dass ein bestimmter Engpass eine Migration nahelegt. Diesen Ruf mache ich mit Evidenz, nicht auf Basis dessen, welches Framework das beste Marketing hat.
Eine Senior-KI-Engineerin, die Sie 2026 einstellen, hat wahrscheinlich kein produktives Multi-Agent-System ausgeliefert, weil fast niemand das getan hat. Ich habe es einmal getan, bei 1,7 Millionen Zeilen Code und 78 % autonomer Lösungsrate. Die Mustererkennung ist auf dem Contractor-Markt noch nicht verfügbar. Ihre Engineers übernehmen die Implementierung; ich bringe die Topologie-Entscheidungen, die Eval-Methodik und die Observability-Muster mit, für die sie sonst drei Iterationen und zwölf Monate bräuchten. Wenn ich gehe, besitzt Ihr Team alles und braucht mich nicht wieder.
Nein. Agent-Topologie, Eval-Harness und Observability sind jeweils Dreiwochen-Probleme, wenn man sie gut macht, und jeweils Einwochen-Probleme, wenn man sie schlecht macht. Die komprimierte Version produziert ein System, das läuft, bis es nicht mehr läuft, und die Debugging-Kosten in Monat vier übersteigen die Beratungseinsparungen in Monat eins. Wenn Sie keine zwölf Wochen haben, ist das richtige Engagement der Pilot-to-Production-Hardening-Service, der die Produktionsreife-Arbeit ohne vollständiges Topologie-Redesign abdeckt. Ich empfehle das ehrlich, wenn es passt.
Fast nie. In den Engagements, die ich geführt habe, bewahrt das Topologie-Design 60–80 % des bestehenden Codes und verändert die Orchestrierungsschicht, die Zustandsgrenzen und die Failure-Isolation-Muster. Die Geschäftslogik, die Ihr Team geschrieben hat, ist in der Regel in Ordnung; ändern muss sich, wie die Agenten koordinieren, wie Zustand verwaltet und wie Fehler behandelt werden. Komplett-Rewrites sind ein Zeichen für einen Berater, der Ihren Code nicht lesen will. Ich lese Ihren Code.
Es ist eine gemessene Zahl aus Auralinks Produktionssystem, im arXiv-Paper berichtet. 78 % der an den Agent-Pool zugewiesenen Incidents werden ohne Human-in-the-Loop gelöst — inklusive der Fälle, in denen ein Agent korrekt eskaliert, nicht nur jener, in denen er Ende-zu-Ende löst. Die Methodik dafür ist Teil dessen, was ich in Ihr Engagement einbringe. Jedes Team, mit dem ich gearbeitet habe, landet bei einer anderen Zahl, weil das Aufgabenprofil anders ist; der Sinn ist nicht, 78 % zu replizieren, sondern die Mess-Infrastruktur zu bauen, die Ihnen Ihre reale Zahl nennt.
Entdecken Sie weitere Services, die dieses Angebot ergänzen
30 Minuten. Ich diagnostiziere Ihre Situation und sage Ihnen ehrlich, ob dieser Service passt — und wenn nicht, welcher.