Vom Prototyp zur produktiven Unternehmensanwendung: Eine Erweiterung von Andrew Ngs „Three Loops“

In einem Brief von Ende Juni 2026beschrieb Andrew Ng, wie er an einem Wochenende eine App für Schreibübungen für seine Tochter entwickelte. Dass der Coding-Agent etwa eine Stunde lang eigenständig arbeitete und sogar wiederholt einen Browser öffnete, um seine eigene Arbeit zu überprüfen, diente ihm als konkretes Beispiel für seine drei ineinandergreifenden Schleifen für die KI-Produktentwicklung von 0 auf 1: die agentische Coding-Schleife (Minuten), die Entwickler-Feedbackschleife (Stunden) und die externe Feedbackschleife (Tage bis Wochen). Wir haben an anderer Stelle über die Schleifen selbst geschrieben – ihre Taktung, Fehlerquellen und die benötigte Telemetrie – in unserem Begleitartikel zum Betrieb von Schleifen im großen Maßstab. Dieser Beitrag befasst sich mit einem anderen Aspekt von Ngs Modell, den Unternehmenskunden laut einem Bericht von explainx.ai zur Sprache brachten: Was passiert mit der äußeren Schleife, wenn das Produkt keine Wochenend-App, sondern ein Unternehmenssystem ist? Ng räumt in seinem Brief offen ein, dass die externe Schleife aus „Freunden, Alpha-Testern und Produktion mit A/B-Tests“ besteht. Ein Bericht von explainx.ai weist darauf hin, dass Unternehmenskunden argumentierten, in regulierten Umgebungen müsse die externe Schleife auch Richtlinien, Governance, Audits und Verantwortlichkeit umfassen, nicht nur Konsumententests. Genau hier setzt dieser Beitrag an. Die Drei-Schleifen-Methode liefert eine nützliche Unterscheidung und verliert ihre Gültigkeit nicht am Eingang zum Unternehmen – doch die äußere Schleife erhält dort Anforderungen, die ein Wochenendprojekt nie kennt. Diese zu erfüllen, macht den Unterschied zwischen einem Prototyp für Demos und einem Produkt, das innerhalb eines Unternehmens tatsächlich eingesetzt wird. Der zweite Teil ordnet diese Anforderungen dokumentierten Mechanismen zu; die ehrliche Grenze bleibt jedoch, dass Infrastruktur die Methode unterstützt, aber nicht das menschliche Urteilsvermögen ersetzt, das im Mittelpunkt steht.

1. Das Framework bleibt bestehen; die äußere Schleife ändert sich am Unternehmenseingang

Beginnen wir damit, Ngs Modell zu würdigen, denn dieser Beitrag setzt dessen Korrektheit voraus. Die drei Schleifen beschreiben eine reale Dynamik: Die innere agentische Schleife schreibt und verifiziert Code mittlerweile schnell genug, sodass sich die Aufgabe des Menschen auf die Produktebene verlagert (die mittlere Schleife), und das Gesamtergebnis ist nur so gut wie das externe Signal, das die Vision validiert (die äußere Schleife). Ngs Wochenend-App ist das perfekte Beispiel, gerade weil sie klein ist – die äußere Schleife besteht darin, dass seine Tochter die App nutzt und er seine Meinung über Katzenkostüme und den Login-Prozess ändert. Das zu bauen ist keineswegs trivial, aber die Verpflichtungen der äußeren Schleife sind gering: Niemand auditiert die Schreib-App, kein Compliance-Verantwortlicher muss sie absegnen, kein Prüfer fragt nach, wer eine Änderung genehmigt hat. Übertragen wir nun dieselbe Methode auf ein Unternehmen. Die innere Schleife bleibt unverändert – der Agent schreibt und testet weiterhin alle paar Minuten Code. Die mittlere Schleife behält ihre Form – ein Mensch steuert weiterhin im Stundentakt. Doch die äußere Schleife wandelt sich: „An Benutzer ausliefern“ bedeutet nun die Auslieferung an Kunden, unter Einhaltung von Richtlinien, mit Verantwortlichkeit, und das externe Feedback, das zählt, umfasst nicht nur die Frage „Gefällt es den Leuten?“, sondern auch „Erfüllt es die Vorgaben, für die das Unternehmen haftbar ist?“. Dies ist keine Kritik an Ngs Modell; es ist die Unternehmensinstanz davon, auf die Unternehmenskunden laut dem explainx.ai-Bericht hingewiesen haben, und genau hier hört ein Build auf, ein bloßes Experiment zu sein, und wird zu einem Produkt.

2. Die Überführung in die Produktion ist ein Problem der äußeren Schleife

Das Beruhigende für jedes Team, das sich bei einem Prototyp von der Drei-Schleifen-Methode hat überzeugen lassen, ist: Die Überführung in die Produktion erfordert keine Änderung der Arbeitsweise – auch wenn Governance einen wesentlichen Teil des Übergangs ausmacht, ist sie nicht alles: Teams benötigen weiterhin konventionelles Production Engineering (Deployment, Zuverlässigkeit, Kapazitätsplanung, Rollback, Incident Response, Sicherheit, Tests auf Anwendungsebene), wobei die Steuerungsebene die Governance sowie die Modell- und Tool-Traffic-Schicht dieses größeren Systems adressiert. Die innere Schleife – Spezifikation, agentische Iteration, Verifizierungsschranken, Budgetobergrenzen pro Durchlauf – folgt derselben Disziplin, egal ob das Ergebnis eine Schreib-App oder ein Schadensabwicklungssystem ist. Was sich ändert, ist alles darum herum die Schleife, und sie verändert sich, weil die neuen Anforderungen der äußeren Schleife nach innen wirken. Ein Agent, der unter Ihren eigenen Anmeldedaten auf Ihrem Laptop lief, benötigt nun eine eigene Identität, da die Frage „Wer hat das getan?“ nicht mit „der Schlüssel des Entwicklers“ beantwortet werden darf. Ein Agent, dessen Ausgaben am Wochenende über Ihr persönliches Abonnement liefen, benötigt nun ein Budget mit einem Verantwortlichen, da jemand für diesen Posten rechenschaftspflichtig sein muss. Ein Agent, der nur Ihre Testdaten sah, verarbeitet nun echte Benutzerdaten, was bedeutet, dass alles, was hinein- und hinausgeht, überprüft werden muss. Und ein Agent, dessen jede Aktion in Ihrem Terminal sichtbar war, läuft nun an einem Ort, an dem andere ihn überprüfen können müssen, was eine dauerhafte Aufzeichnung erfordert. Nichts davon ist ein Anliegen der Build-Schleife; all dies sind Anliegen der äußeren Schleife im Sinne des Unternehmens – die Dimension von Richtlinien, Governance und Audit der berichteten Unternehmens-Governance-Beobachtung – und vieles davon kann durch die umgebende Infrastruktur erzwungen werden, während der Agent und die Anwendung weiterhin für Aufgabendesign, Datenminimierung, Tool-Semantik und Geschäftslogik verantwortlich bleiben. Das ist ein wesentlicher Grund, warum der Übergang in die Produktion machbar ist. Sobald das Modell einer Anwendung und der registrierte MCP-Datenverkehr über die entsprechenden Gateways integriert sind, können Teams viele Kontrollen auf Verkehrsebene zentralisieren, anstatt sie in jedem Agenten unabhängig neu zu implementieren. Die Integration erfordert weiterhin Anmeldedaten, Endpunkte, Richtlinienzuweisungen, Agentenregistrierung, Metadaten und Tool-Routing.

3. Die drei Schleifen, weiterentwickelt: Wo TrueFoundry jeweils ansetzt

Betrachten wir Ngs Schleifen einzeln und ergänzen sie um die jeweiligen Unternehmensanforderungen, zugeordnet zu den dokumentierten Mechanismen. Die innere Schleife bleibt bestehen – und zwar bewusst. Die agentische Coding-Schleife mit ihren Verifizierungstoren und Ausgabenobergrenzen pro Durchlauf ist genau der Teil, den Sie beibehalten; wenn sie in einer verwalteten Laufzeitumgebung ausgeführt wird, bietet das Agent Harness Orchestrierung, Statusverwaltung, Tool-Ausführung und Beobachtbarkeit auf Schritt-Ebene, die nun für mehr als eine Person sichtbar ist; die Anwendung definiert weiterhin die Spezifikation, Tests, Verifizierungskriterien und Abbruchbedingungen. Die mittlere Schleife wird zu Evaluierung und gestaffeltem Rollout. Ng empfiehlt bereits Evaluierungen, wenn derselbe Fehler wiederholt auftritt; in der Produktion wird dieser Instinkt zur Infrastruktur – Gateway-Telemetrie, die ein verbundenes Online- oder Offline-Evaluierungssystem speist (das Evaluierungsmuster) – wobei Scorer, Sampling-Richtlinie, Kalibrierung, Regressionserkennung und Promotionslogik ein angrenzender Workflow bleiben, den das Team implementiert oder integriert – und virtuelle Modellgewichte, die einen kontrollierten Anteil des Datenverkehrs an ein Ziel-Modell leiten, das durch gezielte Konfiguration erweitert oder zurückgesetzt werden kann, ohne den Modellnamen zu ändern, den die Aufrufer verwenden; die Mechanismen, die unsere Routing-Analyse im Detail beschreibt. Das Steuerungs-Feedback des Entwicklers erhält mit anderen Worten ein Sicherheitsnetz: Spezifikation ändern, an 5 % des Datenverkehrs ausliefern, Evaluierungen beobachten, erweitern oder zurücksetzen. Die äußere Schleife erhält ihre Governance-Dimension. Hier wird die gemeldete Governance-Beobachtung zur Konfiguration: Zugriffskontrolle für Modellkonten regelt, welche Benutzer, Teams und Anwendungen genehmigte Modelle aufrufen dürfen. Für die agentenbasierte Zuordnung bei MCP-Gateway- und Agent-Gateway-Datenverkehr präsentiert jeder unabhängig gesteuerte Agent eine registrierte Agentenidentität, wobei die Agentenregistrierung und die zugehörigen Richtlinien definieren, wer den Agenten aufrufen darf, für wen er handeln kann und auf welche nachgelagerten Ressourcen er zugreifen darf; Budgets weisen Ausgaben einem Eigentümer zu und setzen bei aktivierter Durchsetzung ein hartes Limit – der Warnmodus bietet Benachrichtigungen, ohne den Datenverkehr zu blockieren; konfigurierte Gateway-Richtlinien können Modellanfragen und -antworten sowie registrierte MCP-Tool-Aufrufe, die die relevanten Gateways durchlaufen, überprüfen – jeder MCP-Tool-Aufruf wird separat bewertet; dies deckt keine anwendungsseitigen Tools ab, und Output-Guardrails erfordern eine vollständige, nicht-gestreamte Antwort – zum Schutz der echten Benutzerdaten, die der Prototyp nie gesehen hat (Guardrail-Dokumentation); und das Metriken-Dashboard bietet aggregierte Transparenz über Ausgaben, Volumen, Fehler, Latenz, Routing und Guardrail-Ergebnisse, während Anfragetraces und Anfrageprotokolle die Beweise auf Anfrageebene liefern, die „Verantwortlichkeit“ konkret bedeutet – die Protokollierungskonfiguration bestimmt separat, ob Anfrage- und Antwortkörper gespeichert und geschwärzt werden; Kosten, Token, Latenz und Anfragemetadaten bleiben aufgezeichnet. Ngs Kontextvorteil-Punkt bleibt eine Verantwortung innerhalb der Entwicklungsschleife: Teams kodieren Benutzerbedürfnisse, Domänenbeschränkungen, Compliance-Anforderungen und Produktabsichten durch Spezifikationen, Prompts, Datensätze, Bewertungen und Überprüfungen. Unabhängig davon kann Agent Harness sensible Tool-Aufrufe pausieren, bis eine explizite Genehmigungsentscheidung vorliegt – ein Ausführungs-Checkpoint, kein Ersatz für Autorisierung oder vorgelagertes Kontext-Engineering. Für sensible Aktionen, die eine explizite Überprüfung erfordern, erstellt eine Genehmigungsrichtlinie einen menschlichen Checkpoint, bevor das Tool den entscheidenden Schritt ausführt – das Muster, das unsere aufgabenbasierte Zugriffskontrolle entwickelt. Die Methode ist unverändert; die äußere Schleife hat lediglich an Schärfe gewonnen, und diese ist dokumentiert.

‍