Federated Factory im Enterprise-Maßstab

Unsere Position. Eine Factory kann niemand kaufen oder kopieren. Sie hängt an der Codebasis und den Konventionen, auf denen sie läuft. Deshalb baut jede Organisation sie als eigene Fähigkeit auf (You can’t copy someone else’s factory (öffnet in einem neuen Tab)).

Eine Factory zu bauen und viele zu betreiben, sind darum zwei verschiedene Designprobleme. Ein Enterprise gleicht Dutzenden kleiner Stripes, keinem einzelnen Stripe. Die Plattform, die sie bedient, braucht deshalb eine eigene Form. Das Ebenenmodell und die Aufteilung der Fähigkeiten folgen dem Vendor-Whitepaper Software Factories at Enterprise Scale.

Warum lassen sich die veröffentlichten Factories nicht auf ein Enterprise übertragen?

Alle veröffentlichten Factories laufen unter Bedingungen, die kaum jemand teilt.

• Stripes Minions sitzen auf einem Monorepo mit rund drei Millionen Tests und etwa 500 internen MCP-Tools. Menschliche Engineers haben diese Tools über ein halbes Jahrzehnt gebaut.
• Das Harness-Team von OpenAI hatte eine Codebasis und eine Toolchain für sich allein.
• Ramps Inspect deckt Frontend- und Backend-Repos in einer einzigen Org ab.

Der Durchsatz kommt aus dem System. Dieses System entstand langsam, lange bevor die Agents kamen. Den Aufbau jeder dieser Factories beschreibt Software Factories und Harness Engineering.

Ein echtes Enterprise hat Produktlinien unterschiedlicher Reife, regulierte und unregulierte Systemlandschaft und Teams in verschiedenen Ländern. Übernommene Firmen arbeiten noch nach ihren eigenen Konventionen. Auch ein großes Unternehmen mit einem einzigen Produkt hat Platform-, Product-, Data-, ML- und Security-Teams. Deren Anforderungen an den Harness unterscheiden sich wirklich.

Warum scheitern eine zentrale Factory und eine Factory pro Team gleichermaßen?

Eine zentrale Factory für alle. Sie passt zu dem Team, das sie gebaut hat. Für alle anderen stimmen Konventionen, Testreife, Risikoprofil und Stack nicht. Also lehnen Teams sie ab, und die Plattform wird zur Shelfware. Oder sie übernehmen sie widerwillig und verlieren Tempo an der Fehlanpassung. In beiden Fällen bekommt das zentrale Team die Schuld. An der Umsetzung liegt das nicht. Eine Plattform für einen neuen TypeScript-Core mit moderner Testsuite passt nicht zugleich zu einem fünfzehn Jahre alten Java-Monolithen mit dünner Coverage. Wer sie trotzdem erzwingt, baut etwas, das keinem von beiden dient.

Jedes Team baut seine eigene. Dann fehlen ein gemeinsames Identity-Verzeichnis, eine gemeinsame MCP-Registry, ein gemeinsames Audit-Log und eine gemeinsame Blueprint-Bibliothek. Die Wartungskosten fallen vielfach an. Security und Compliance zerfallen, und was ein Team lernt, erreicht das nächste nie. Damit entfällt der Grund, überhaupt eine Organisation zu sein.

Was sind die drei Ebenen?

Der Mittelweg ordnet jede Fähigkeit der Ebene zu, die sie tatsächlich besitzen kann. Zwischen den Ebenen gilt ein expliziter Vertrag.

• Plattform-Ebene: die zentrale Control Plane, die genau einmal läuft. Dazu gehören die versionierte Blueprint-Registry, das Identity-Verzeichnis und das unveränderliche Audit-Log. Dazu kommt der Tool-Router mit Scopes, der festlegt, welche MCP-Tools jede Agent-Rolle erreicht. Darunter sitzt ein sicherer API-Proxy mit den echten Credentials. Agents sehen sie nie. Der Proxy injiziert beim Egress Tokens mit Scope und schreibt den Aufruf auf dem Rückweg ins Audit-Log.
• Domänen-Ebene: Kontext, den Gruppen von Teams teilen. Eine Domäne kann regulatorisch sein, etwa wenn alle Teams mit Zahlungsdaten PCI-Blueprints teilen. Sie kann technisch sein (alle auf dem neuen Core-Stack), fachlich oder geografisch (EU-Teams teilen DSGVO-Muster). Domänen sind von Grund auf plural: Ein Team sitzt in mehreren Domänen zugleich.
• Team-Ebene: Hier läuft die Ausführung, mit lokalen Sandboxes, MCP-Servern im Besitz des Teams und lokalen Konventionen auf geforkten Blueprints.

Das wichtigste Detail steckt im Audit-Log. Jeder Agent trägt eine eigene nicht-menschliche Identität, getrennt von der jedes menschlichen Users. Jede geloggte Aktion hält beides fest: welcher Mensch die Arbeit delegiert hat und welcher Agent sie ausgeführt hat. Fallen beide zusammen, erscheint jede Aktion entweder als Proxy oder als delegierender Mensch. Bei der Menge an Agent-Aktionen verschwindet dann die Verantwortlichkeit.

Die Runtime richtet sich danach, was die Arbeit tut, und nicht danach, wie schwer sie wirkt. Alles mit Dateisystem, Shell, Paketinstallation oder Kompilieren braucht einen Kernel darunter: einen Container, eine MicroVM oder eine Sandbox mit Userspace-Kernel. Leichte Edge-Isolates booten in Millisekunden und kosten einen Bruchteil. Sie haben aber weder Dateisystem noch Shell. Damit passen sie zu zustandsloser Datentransformation und API-Routing, nicht zu Coding-Arbeit. Interaktive Arbeit läuft in einer lokalen Devbox. Die Plattform unterstützt alle drei, weil die Blueprint-Runtime von der Ausführungsschicht entkoppelt ist.

Welche Ebene besitzt welche Fähigkeit?

In jeder funktionierenden Factory tauchen sechs Fähigkeiten auf: Orchestrierung, isolierte Umgebungen, Kontext und Memory, Validierung, Governance und Lernen. Im Enterprise-Maßstab fragt ihr bei keiner, ob ihr sie braucht. Ihr fragt, welche Ebene sie besitzt.

Zwei Zeilen tragen das Argument.

Validierung sieht auf jeder Ebene gleich aus und unterscheidet sich im Detail. Eine Änderung an einem Zahlungssystem muss die PCI-Prüfung bestehen, bevor ein Mensch sie sieht. Eine Änderung an einer Marketing-Website muss das nicht. Das Harness-Pattern ist geteilt, die Checks sind lokal.

Lernen wandert nach oben, die Daten bleiben, wo sie sind. Findet ein Team ein Review-Pattern, das 30 % mehr Bugs fängt, fließt die Lektion anonymisiert in die Domänen-Referenz. Andere Teams übernehmen sie, ohne je den Ursprungscode zu sehen. Standardisierung entsteht durch gezeigten Nutzen statt durch Anordnung.

Blueprint-Forks sind sichtbar statt verboten. Fährt ein Team einen eigenen Build-and-Deploy-Blueprint, während alle anderen Teams der Domäne die kanonische Version nutzen, zeigt die Registry das an. Ob dieser Fork sich verbreiten oder auslaufen soll, wird so zur Datenfrage statt zur Meinungsfrage.

Warum ist MCP die Naht zwischen den Ebenen?

Die folgenreiche Architekturentscheidung macht MCP zur Standardschnittstelle zwischen Agents und jedem internen System. Buchhaltung, Kundendatenbank, CRM und Deployment-Pipeline werden alle als MCP-Server gekapselt. Jeder Server bietet ein kleines, klar geschnittenes Tool-Set an. Jeder gehört dem Team, dem auch die Anwendung gehört. So wird das zentrale Plattform-Team nie zum Bottleneck für neue Integrationen. Eine zentrale Registry weiß, welche Server es gibt und wem sie gehören. Das Gateway sitzt vor jedem Aufruf, prüft RBAC, entfernt Credentials und loggt die Transaktion.

Das Gateway filtert außerdem die Tool-Oberfläche pro Agent. Das ist ebenso eine Security-Kontrolle wie eine Hilfe fürs Reasoning. Ein Agent, der drei Tools braucht, sollte keinen Katalog von vierhundert sehen. Übergroße Kataloge verschlechtern das Reasoning des Modells und vergrößern die Angriffsfläche. Das Information Sheet der NSA zu MCP-Security benennt das direkt. Daneben nennt es ungeprüfte Task-Weitergabe zwischen MCP-Servern und Session-Wiederverwendung über Tokens ohne Scope. Das sind Governance-Probleme, keine Protokollprobleme, und gelöst werden sie am Gateway.

Das ist eine echte Verpflichtung. Jedes Team, das eine interne Anwendung baut, akzeptiert einen Vertrag: den Service über MCP anbieten, dem Schema folgen, das Auditing hinnehmen. Dafür kann jeder Agent in jedem Team die Anwendung sofort nutzen. Governance setzt dann der Weg selbst durch, keine Checkliste. Ohne diese Verpflichtung zerfällt die Plattform wieder in Punkt-zu-Punkt-Integrationen, und der Netzwerkeffekt ist weg.

Wie teilen sich zwei Factory-Patterns eine Plattform?

Das Dark-Factory-Pattern funktioniert, aber nur unter Vorbedingungen: eine aktuelle Testsuite, eine standardisierte Dev-Umgebung und Konventionen, die in einer AGENTS.md stehen. Greenfield-Arbeit erfüllt sie meist. Brownfield-Arbeit erfüllt sie meist nicht, also die Altlandschaft, die über Übernahmen kam. Dort gibt es dünne Tests, Konventionen in den Köpfen und eine Umgebung Marke Eigenbau. Ein unbeaufsichtigter Agent produziert dort kaputte PRs in Masse.

Beide Positionen stimmen, jeweils für einen anderen Teil der Landschaft. Das ehrliche Design betreibt beide auf derselben Runtime. Dark-Factory-Blueprints laufen gegen Repos, die die Vorbedingungen erfüllen, Interactive-Assistant-Blueprints gegen die übrigen. Die Einordnung liegt als Metadaten in der Blueprint-Registry. Wer Dark-Factory-Autonomie für eine Altlandschaft verspricht, verspielt am häufigsten die Glaubwürdigkeit solcher Initiativen. Dieser Fehler lässt sich vollständig vermeiden.

Was passiert, wenn eine Übernahme auf die Plattform kommt?

Steht die Plattform, wird das Onboarding eines Teams zur Routine:

• einen Tenant aufsetzen,
• die operative Dokumentation des Teams in seine MCP-Schicht einspielen,
• Zugriff auf die Blueprint-Bibliotheken geben,
• das Team auf seine Art weiterarbeiten lassen, während es Standards dort übernimmt, wo sie sich bewähren.

Ein neues internes Team, eine neue Produktlinie, ein Regionalbüro und ein übernommenes Unternehmen durchlaufen denselben Flow.

Am sichtbarsten wird die Ökonomie bei Übernahmen. Klassisch verschlingt die Integration einer Engineering-Organisation 12 bis 24 Monate und einen großen Teil der zentralen IT-Kapazität. Mit der Plattform dauert der operative Teil nur noch Wochen. Gemeint ist der Teil, der Agents gegen die übernommene Codebasis arbeiten lässt. Die Plattform nimmt neue Teams auf, ohne dass der zentrale Headcount proportional wächst. Diese Aussage stammt vom Vendor und hat keine veröffentlichte unabhängige Replikation. Der Mechanismus ist aber nachvollziehbar.

Was macht die Plattform schwer kopierbar?

Foundation Models nehmen allgemeine Engineering-Praxis schnell auf. Das operative Wissen in einer Organisation nehmen sie nicht auf. Dazu gehören die besonderen Entscheidungen dieser Codebasis, die Vendor-Beziehungen, auf die sich dieses Team stützt, und das institutionelle Gedächtnis aus Tausenden Designdiskussionen. Nichts davon steht in einem öffentlichen Korpus, und nichts davon wird je dort stehen. Wer dieses Wissen in die MCP-Server der Team-Ebene schreibt, baut einen Vorsprung auf, der sich aufschichtet. Deshalb lässt sich der Vorteil auch nicht kaufen. Architektur, Kontextbasis und Validierungs-Harness müssen über die Zeit entstehen. Dasselbe gilt für das Verständnis des Teams, was Agents können und was nicht.

Welche Probleme sind noch ungelöst?

Die fünf offenen Probleme im Maßstab eines einzelnen Teams überstehen die Föderation alle: Memory und Kontext im großen Maßstab, Evaluation gegenüber Realität, Spec-Qualität, Governance-Tempo und die Talent-Pipeline. Drei weitere kommen dazu.

• Wissen zwischen Teams verbreiten, ohne Daten preiszugeben. Die Lektion soll reisen, die Daten dahinter dürfen es nicht. In den veröffentlichten Implementierungen erfolgt der Anonymisierungsschritt unter menschlicher Mitwirkung und ist langsam. An diesem Problem entscheidet sich auch, wie viel Wert die Föderation tatsächlich liefert. Die Alternative ist, dass jedes Team für sich lernt. Das verschenkt den Netzwerkeffekt, mit dem die Plattform begründet wurde.
• Forken oder übernehmen. Forkt ein Team einen Plattform-Blueprint, ist das dann legitime lokale Anpassung oder Tech Debt? Die Antwort verlangt Urteilsvermögen, und ein Fehlurteil kostet Jahre paralleler Wartung. Eine plausible Heuristik misst, ob der Fork bessere Ergebnisse liefert als die kanonische Version. Dafür braucht es eine Messinfrastruktur, die keine veröffentlichte Implementierung hat.
• Identität im Maßstab der Föderation. Im Prinzip ist das Auth-Modell einfach: Der Agent erbt die Rechte des Users und nicht mehr. Dann arbeitet ein User in zwei Teams. Ein Domänen-Blueprint muss aus drei Teams lesen. Und die interne Revision braucht Lesezugriff auf die Daten eines Teams, ohne dass dieses Team die Prüfung sieht.

Wie fangt ihr an?

Baut die föderierte Plattform nicht in einem Zug. Baut eine Factory für ein Team und beweist, dass sie funktioniert. Entwerft die Plattform-Ebene parallel dazu. Dann kommt das zweite Team als Tenant einer bestehenden Plattform dazu und nicht als Kopie der Maßanfertigung des ersten Teams. Beim dritten Team sollte der Föderationseffekt sichtbar sein:

• Teams übernehmen geteilte Blueprints, weil sie ihren Nutzen gezeigt haben.
• Lektionen wandern über die Domänen-Ebene.
• Die MCP-Registry wächst mit jeder Anwendung, die ein Team kapselt.

Vier Prinzipien aus der Praxis gelten in jedem Maßstab:

• Nutzt langweilige, gut dokumentierte Technik, weil Agents damit verlässlicher arbeiten.
• Haltet Kontext im Repo, weil der Agent alles außerhalb nicht sieht.
• Prüft getrennt vom Ort der Generierung, weil Agents auf jedes Signal optimieren, das ihr ihnen gebt.
• Behandelt die Agent-Plattform als Produkt.

Im Enterprise-Maßstab kommt ein fünftes dazu: Die Plattform spannt sich über viele Teams, steuert aber von einem Ort aus.

Verwandte Seiten

• Federated Context Platform für KI-Agenten im Unternehmen: dieselbe Föderation, angewandt auf Kontext statt auf die Factory.
• Die Plattformschicht: Gateway und Registry aus Sicht des Kontexts.
• Sicherheit und Runtime-Isolation: Gateway, Sandbox und Audit-Kontrollen aus Security-Sicht.
• Das Enabling Environment: was jede Team-Ebene braucht, bevor ihre Agents ihre eigene Arbeit prüfen können.
• Dark Factory Patterns: die Patterns für Repositories, die die Dark-Factory-Vorbedingungen erfüllen.
• Build-or-Buy-Framework: wie ihr entscheidet, welche Teile der Plattform ihr selbst baut.

Quellen

Forschung

• NSA Cybersecurity Information Sheet on MCP security (öffnet in einem neuen Tab) - Behördliche Leitlinie zur Angriffsfläche von MCP: übergroße Tool-Kataloge, ungeprüfte Task-Weitergabe, Session-Tokens ohne Scope.
• Software Factories at Enterprise Scale (öffnet in einem neuen Tab) - Vendor-Whitepaper zur föderierten Plattform mit drei Ebenen, zur Aufteilung der Fähigkeiten nach Ebene und zu MCP als Naht der Föderation; nur über ein Formular erhältlich.