Zuletzt aktualisiert: 10. September 2026 · Version: 1.0
Redaktionshinweis: Dieser Artikel wurde mit KI-Unterstützung recherchiert und überarbeitet sowie menschlich redaktionell geprüft. Produkt-, Sicherheits- und Nutzungsangaben stammen überwiegend von Factory; unabhängige Unternehmensdaten zur Produktivitätswirkung sind nur begrenzt verfügbar. Funktionen und Datenflüsse können je nach Tarif, Modell, Region, Laufzeit und Enterprise-Konfiguration abweichen.
In 30 Sekunden
- Factory Droid ist kein reiner Code-Chat, sondern ein Agentenlaufzeitsystem für Entwicklung, Reviews, Migrationen, Incident Response und länger laufende Mehragenten-Aufgaben.
- Droid läuft auf Entwicklergeräten, CI-Runnern, VMs und Kubernetes sowie in Cloud-, Hybrid-, EU- und vollständig abgeschotteten Enterprise-Umgebungen.
- Modus und Autonomie sind getrennt: Normal, Spec oder Mission bestimmen den Arbeitsablauf; Off, Low, Medium oder High bestimmen, welche Aktionen ohne Rückfrage laufen.
- Persistente Droid Computers sparen Einrichtungszeit, behalten aber Dateien, Prozesse, Konfiguration und Credentials über Sitzungen hinweg. Das verändert das Risikomodell grundlegend.
- Öffentliche Tarife beginnen bei 20 US-Dollar monatlich. Business- und Enterprise-Konditionen sind individuell; der Lizenzpreis bildet Modell-, Compute-, Review- und Governance-Kosten nicht vollständig ab.
Was Unternehmen jetzt konkret tun sollten
- Mit einem lokalen Droid beginnen: ein risikoarmes Repository, keine Produktionszugänge und Autonomie zunächst auf Off oder Low.
- Datenwege festschreiben: Modellanbieter, Gateway, Telemetrie, Cloud-Sync, Region und Aufbewahrung pro Betriebsmodell dokumentieren.
- Persistenz separat freigeben: Droid Computers und Missions erst nach Kontrolle von Identitäten, Secrets, Netzwerk und Lebenszyklus aktivieren.
- Nach vier Wochen entscheiden: Qualität, End-to-End-Zeit, Review-Aufwand, Verbrauch und Sicherheitsbefunde gegen eine Baseline messen.
Factory Droid ist für Unternehmen interessant, die aus einzelnen Coding-Assistenten einen kontrollierbaren Entwicklungsbetrieb machen wollen. Die Plattform verbindet mehrere Modelle, Oberflächen, Laufzeiten und Automationsstufen. Das kann Tool-Wildwuchs reduzieren – sofern die zentrale Plattform tatsächlich strengere Regeln durchsetzt als die zuvor verteilten Einzelwerkzeuge.
Genau hier liegt der Zielkonflikt: Je mehr Droid über Code, Tickets, Kommunikation, Incidents und Infrastruktur hinweg erledigt, desto größer werden Reichweite und möglicher Schaden einer Fehlentscheidung. Factory ist deshalb nicht nur eine Entwicklerlizenz, sondern eine Architekturentscheidung für Identität, Datenflüsse, Compute und Freigaben.
Für Entscheider relevant: Der Artikel ordnet strategischen Nutzen, Gesamtkosten, Einsatzgrenzen und die Go/No-Go-Logik ein.
Für Plattform- und Security-Teams relevant: Im Mittelpunkt stehen Laufzeiten, Identitäten, Secrets, Netzwerk, Telemetrie, Persistenz und technische Freigaben.
Was Factory Droid 2026 ist
Factory machte Droids im Mai 2025 allgemein verfügbar. Mit Factory 2.0 vom 15. Juni 2026 positioniert das Unternehmen die Plattform als „Software Factory“ für den gesamten Entwicklungslebenszyklus. Droids können unter anderem Features umsetzen, Repositories untersuchen, Tests und Reviews ausführen, Migrationen unterstützen, Dokumentation pflegen und Incidents analysieren.
Factory wurde 2023 gegründet. Im April 2026 meldete das Unternehmen eine Series C über 150 Millionen US-Dollar bei einer Bewertung von 1,5 Milliarden US-Dollar; TechCrunch bestätigte Runde und Bewertung. Öffentlich genannte Kunden wie NVIDIA, Adobe, EY, Palo Alto Networks, Adyen und Morgan Stanley sprechen für Enterprise-Traktion, ersetzen aber keine eigene Wirksamkeitsprüfung.
Eine Plattform, mehrere Ausführungsflächen
| Fläche | Typische Aufgabe | Enterprise-Prüfpunkt |
|---|---|---|
| Desktop/CLI | Interaktive Arbeit im lokalen Repository mit Datei- und Shell-Zugriff | Projektgrenze, Befehlsregeln, Sandbox und Modellroute |
| Browser/Mobile | Sitzungen starten, verfolgen und Ergebnisse prüfen | Identität, Cloud-Sync, Region und Remote-Compute |
| CI/CD | Automatisierte Reviews, Fixes und wiederkehrende Abläufe | Servicekonto, Runner-Isolation, Trigger und Branch Protection |
| Slack, Teams und Connectoren | Aufgaben aus Kommunikation und Geschäftssystemen ableiten | Berechtigungsumfang des verbundenen Kontos und schreibende Aktionen |
Die Oberflächen teilen den Agentenkern, aber nicht dasselbe Risiko. Ein lokaler, interaktiver Patch ist begrenzter als eine aus einem Chat ausgelöste Mission mit Zugriff auf Tickets, Cloud-Systeme und Pull Requests. Eine zentrale Lizenz darf daher nicht zu einer pauschalen Freigabe aller Flächen führen.
Normal, Spec und Mission: Ablauf ist nicht gleich Autonomie
Factory trennt Interaktionsmodus und Autonomiestufe. Normal Mode arbeitet direkt. Spec Mode untersucht die Aufgabe und legt vor Codeänderungen einen Plan zur Prüfung vor. Mission Mode zerlegt größere Vorhaben in Meilensteine und parallele Agentenarbeit. Separat steuern Off, Low, Medium und High, welche Aktionen ohne Bestätigung ausgeführt werden dürfen.
Diese Trennung ist fachlich sinnvoll: Ein guter Plan sagt, was passieren soll; Autonomieregeln begrenzen, was ohne Freigabe passieren darf. Spec Mode wird dadurch nicht automatisch sicher. Mission Mode vervielfacht zudem nicht nur Arbeit, sondern auch Identitäten, Modellaufrufe und mögliche Seiteneffekte.
Merksatz: Ein Plan reduziert fachliche Überraschungen. Least Privilege reduziert technische Folgen.
Lokale Laufzeit, Cloud-Compute und Airgap sauber unterscheiden
Droid ist laut Enterprise-Dokumentation grundsätzlich eine lokale Agentenlaufzeit: Dateien und Befehle werden dort verarbeitet, wo der Agent läuft. Ausgewählter Kontext wird jedoch an das konfigurierte Modell oder Gateway gesendet. Factory unterscheidet Cloud-, Hybrid-, EU- und vollständig airgapped Betriebsweisen.
| Muster | Daten- und Betriebsgrenze | Geeignet für |
|---|---|---|
| Cloud-managed | Lokale/CI-Laufzeit mit Factory-Control-Plane und konfigurierten Modellendpunkten | Teams mit freigegebener Cloud-Nutzung |
| Hybrid | Laufzeit, Gateway und Telemetrie überwiegend in der eigenen Infrastruktur | Unternehmen mit zentralem LLM-Gateway |
| EU-Region | Sitzungsinhalte in europäischer Datenbank; globale Identitäts- und Abrechnungsdaten bleiben separat | DACH-Organisationen mit EWR-Anforderung für Nutzerinhalte |
| Airgapped | Kein Laufzeitkontakt zu Factory-Diensten; eigene Modelle, Policies und Telemetrieziele | Hochsicherheits- und regulierte Umgebungen |
Die EU-Option ist kein pauschales DSGVO-Siegel. Unternehmen müssen weiterhin Modellanbieter, Identitätsdienst, Unterauftragsverarbeiter, Aufbewahrung und mögliche Drittlandtransfers prüfen. Airgap reduziert externe Datenwege, erhöht aber den eigenen Aufwand für Modellbetrieb, Updates, Artefaktverteilung und Monitoring.
Droid Computers: Produktivitätsvorteil mit dauerhaftem Zustand
Droid Computers sind persistente Entwicklungsumgebungen. Factory kann sie verwalten, oder Unternehmen registrieren eigene Maschinen. Installierte Pakete, Dateien, laufende Dienste, Konfiguration und Prozesszustand bleiben zwischen Sitzungen erhalten. Das spart wiederholte Einrichtung und eignet sich für lang laufende Aufgaben.
Governance-Hinweis
Persistenz verlängert auch die Lebensdauer von Credentials, kompromittierten Abhängigkeiten und Fehlkonfigurationen. Droid Computers brauchen deshalb einen definierten Eigentümer, Patch- und Rebuild-Prozess, kurzlebige Identitäten, Egress-Regeln, Inventarisierung und eine sichere Löschung. Produktionsschlüssel gehören nicht dauerhaft auf eine Agentenmaschine.
Enterprise-Kontrollen: Wo Factory über Einzelwerkzeuge hinausgeht
Factory dokumentiert SAML/OIDC-SSO, SCIM, Rollen und eigene Servicekonten für Automation. Zentral verwaltete Einstellungen können Modelle und Base-URLs begrenzen, Autonomie deckeln, Befehle sperren, MCP-Server und Hooks steuern, Sandboxing erzwingen und Sitzungsaufbewahrung konfigurieren. Für Cloud-Funktionen nennt Factory Audit-Ereignisse; zusätzlich kann Droid OpenTelemetry-Metriken in kundeneigene Systeme exportieren.
Diese Kontrollen sind nur belastbar, wenn sie serverseitig oder außerhalb des Agenten durchgesetzt werden. Team-Guidelines und Prompts bleiben Orientierung. Besonders schreibende Connectoren benötigen eine eigene Prüfung, weil die Rechte des verbundenen Drittanbieter-Kontos die reale Grenze bilden.
Datenschutz und Telemetrie: drei Datenströme statt einer Cloud-Frage
Die Factory-Dokumentation trennt Codezugriff, LLM-Verkehr und Telemetrie. Code wird bei lokaler Ausführung direkt vom Dateisystem gelesen; benötigter Kontext geht an das freigegebene Modell oder Gateway. Bei offiziellen Enterprise-Endpunkten gibt Factory an, Anfragen direkt an die Anbieter-APIs zu routen und Prompts sowie Antworten nicht in der Factory Cloud zu speichern. Die konkrete Garantie hängt dennoch vom Providervertrag und gewählten Endpunkt ab.
OTEL-Metriken werden in verbundenen Installationen standardmäßig an Factory und optional an einen kundeneigenen Collector gesendet. Nachrichteninhalte lassen sich nur zu einem eigenen Collector exportieren und sind standardmäßig deaktiviert. Wird diese Option aktiviert, enthalten Traces laut Telemetry Privacy Controls wörtliche Prompts, Antworten, Tool-Eingaben und Ergebnisse – ohne PII-Bereinigung oder Secret-Erkennung. Das ist ein Auditwerkzeug mit eigenem Hochrisiko-Datenbestand.
Für DACH-Unternehmen sollten Datenschutz, Security und Betriebsrat deshalb festlegen, ob Telemetrie aggregiert oder nutzerbezogen ist, wer sie sieht, wie lange sie bleibt und ob individuelle Leistungsbewertung ausgeschlossen wird.
Preise und vollständige Betriebskosten
Preisstand: 10. September 2026; Änderungen möglich. Die Öffentliche Factory-Preisseite nennt folgende Listenpreise:
| Tarif | Listenpreis | Einordnung |
|---|---|---|
| Pro | 20 US-Dollar/Monat | Einzelentwickler, App/CLI/SDK sowie lokale und Cloud-Hintergrundagenten |
| Plus | 100 US-Dollar/Monat | Etwa fünffache Pro-Nutzung und verwaltete Droid Computers |
| Max | 200 US-Dollar/Monat | Etwa zehnfache Pro-Nutzung und früher Funktionszugang |
| Teams | 60 US-Dollar je Team plus 40 US-Dollar je Sitz/Monat | Bis zu zehn Sitze, zentrale Abrechnung und gemeinsames Computer-Kontingent |
| Business/Enterprise | Auf Anfrage | SSO/SCIM, ZDR, Audit und Admin-Kontrollen; Enterprise zusätzlich unter anderem Airgap, Datenresidenz und eigene Schlüssel |
Individuelle Pläne arbeiten mit mehreren rollierenden Rate-Limit-Fenstern; zusätzliche Nutzung und Modellwahl verändern die Kosten. Für Unternehmen zählt daher: Lizenz und Modellverbrauch + Compute und Gateway + Integration und Security + Review und Nacharbeit – nachweisbar eingesparte End-to-End-Zeit.
Herstellerzahlen und Benchmarks richtig lesen
Factory veröffentlicht starke Kundenwerte, etwa deutlich kürzere Liefer- oder Migrationszeiten. Diese Zahlen stammen aus Fallstudien und sind nicht als repräsentativer Marktvergleich zu verstehen. Auch die vom Hersteller veröffentlichten Terminal- und Legacy-Benchmarks zeigen Fähigkeiten unter definierten Testbedingungen, nicht die Wirtschaftlichkeit im eigenen Unternehmen. Eine unabhängige, herstellerübergreifende Vergleichsstudie, die eine allgemeine Produktivitätswirkung von Factory Droid belegt, ist zum Stichtag 10. September 2026 nicht öffentlich verfügbar.
Im August 2026 berichtete Factory, dass sein Model Router in ausgewerteten Produktionssitzungen die aggregierten Modellkosten gegenüber einer durchgängigen Frontier-Modell-Nutzung um 58 Prozent reduziert habe, ohne Verschlechterung bei acht internen Ergebnismaßen. Das ist eine Herstellerauswertung aus dem eigenen System, kein unabhängiger ROI-Nachweis. Sie liefert eine plausible Hypothese für den Pilot: Modellrouting kann sparen, muss aber gegen Ergebnisqualität und Cache-Effekte gemessen werden.
Wo Factory Droid gut passt – und wo nicht
Der stärkste Fit besteht bei größeren Engineering-Organisationen, die mehrere Modelle und Teams zentral steuern, lange Migrationen oder Reviews automatisieren und unterschiedliche Laufzeitgrenzen benötigen. Kleine Teams mit wenigen Repositories können dieselbe Plattformbreite als unnötigen Betriebsaufwand erleben.
Im Vergleich zu OpenAI Codex, Claude Code, AWS Kiro, JetBrains Junie und Cognition Devin positioniert sich Factory besonders über Modellunabhängigkeit, Deployment-Breite, persistente Compute-Ziele und mehrstufige Missions. Das ist eine Profilbeschreibung, kein pauschales Ranking.
Ein kontrollierter Vier-Wochen-Pilot
Hypothetisches Praxisbeispiel: Ein Industrieunternehmen testet Droid bei der Modernisierung eines internen Java-Dienstes mit synthetischen Daten. Die folgenden Kriterien sind redaktionelle Pilotvorgaben, keine behaupteten Kundenergebnisse.
| Woche | Arbeit | Abnahme |
|---|---|---|
| 1 | Baseline, Datenklassen, Modellroute und zwei Referenzaufgaben festlegen | Freigegebener Datenfluss; keine Produktionszugänge |
| 2 | Lokale CLI, Spec Mode und Autonomie Low testen; Befehle und Netzwerk begrenzen | Plan geprüft; keine unerlaubten Zugriffe; Tests bestehen |
| 3 | CI-Runner und eine kleine Mission getrennt erproben; OTEL-Metriken ohne Inhalte exportieren | Servicekonto minimal; Logs zuordenbar; Abbruch funktioniert |
| 4 | Qualität, End-to-End-Zeit, Review, Defekte, Verbrauch und Akzeptanz vergleichen | Gemeinsames Go, Nachbesserung oder Abbruch durch Engineering, Plattform und Security |
Entscheidungsrahmen in fünf Kriterien
- Qualität: Erfüllen Code, Tests und Dokumentation dieselbe Baseline wie menschlich bearbeitete Aufgaben?
- Kontrollierbarkeit: Greifen Autonomiegrenze, Befehlsregeln, Sandbox, Servicekonto und Branch Protection?
- Datenklarheit: Sind Modellverkehr, Telemetrie, Cloud-Sync, Region und Aufbewahrung vollständig dokumentiert?
- Wirtschaftlichkeit: Übersteigt eingesparte End-to-End-Zeit die vollständigen Betriebs- und Prüfkosten?
- Skalierbarkeit: Lassen sich Policies und Messgrößen zentral auf weitere Teams übertragen?
Ein Go setzt voraus, dass kein schwerer Sicherheits- oder Datenschutzbefund offen ist, die Qualitätsbaseline mindestens gehalten wird und ein messbarer Vorteil bei Zeit oder Planbarkeit entsteht. Sonst wird der Umfang begrenzt oder der Pilot beendet. Ergänzend hilft der AI-Fabrik-Leitfaden zur Governance von KI-Agenten im Unternehmen.
Fazit: Plattformbreite ist Factorys Vorteil – und seine Prüfpflicht
Factory Droid gehört 2026 zu den umfassenderen Plattformansätzen im Markt für Softwareentwicklungsagenten. Modellwahl, lokale und entfernte Laufzeiten, Missions, persistente Computer, Enterprise-Policies und Telemetrie ergeben ein schlüssiges Betriebsmodell für große Organisationen.
Der Nutzen entsteht aber nicht durch maximale Autonomie. Enterprise-Reife bedeutet, Modelle, Identitäten, Compute, Datenwege und Freigaben pro Arbeitsform zu begrenzen. Wer direkt mit persistenten Computern, breiten Connectoren und schreibenden Missions startet, skaliert zunächst das Risiko.
Empfehlung: Starten Sie lokal mit Spec Mode und niedriger Autonomie. Geben Sie CI, Missions, Connectoren und persistente Droid Computers jeweils über ein separates technisches und datenschutzrechtliches Gate frei.
Teil der Reihe: KI-Coding-Agenten 2026
Zum Vergleich aller zehn KI-Coding-Agenten – mit Auswahlmatrix, Governance-Fragen und einem gemeinsamen Pilotrahmen.
Passende Vertiefungen
FAQ zu Factory Droid im Unternehmen
Läuft Factory Droid lokal?
Der Agent kann lokal auf Entwicklergeräten oder eigener Infrastruktur laufen. Für Modellantworten wird benötigter Kontext an den konfigurierten Anbieter oder Gateway übertragen. Nur ein vollständig airgapped Aufbau mit eigenen Modellen vermeidet externe Laufzeitverbindungen.
Was unterscheidet Spec Mode und Autonomie?
Spec Mode bestimmt den Ablauf: erst untersuchen und planen, dann nach Freigabe umsetzen. Die Autonomiestufe bestimmt separat, welche Aktionen ohne Bestätigung zulässig sind.
Was sind Droid Computers?
Das sind persistente Maschinen für entfernte Agentensitzungen. Sie behalten Dateien, Pakete, Dienste und Konfiguration zwischen Sitzungen und benötigen deshalb strengere Credential-, Patch- und Lebenszyklusregeln als kurzlebige Sandboxes.
Ist die EU-Region automatisch DSGVO-konform?
Nein. Sie kann Nutzerinhalte im EWR halten, ersetzt aber nicht die Prüfung von Modellanbietern, Identität, Unterauftragsverarbeitern, Aufbewahrung, Zweck und Drittlandtransfers.
Für wen eignet sich Factory Droid besonders?
Vor allem für größere Engineering-Organisationen, die mehrere Modelle, Teams, Laufzeiten und Automationsformen zentral steuern müssen. Für kleine Teams kann ein enger zugeschnittenes Werkzeug wirtschaftlicher und einfacher zu betreiben sein.
Quellen
- Factory: Droids General Availability, 28. Mai 2025, abgerufen am 10. September 2026.
- Factory 2.0: From coding agents to software factories, 15. Juni 2026, abgerufen am 10. September 2026.
- Factory Enterprise Documentation, abgerufen am 10. September 2026.
- Factory: Deployment Patterns und Airgapped Deployment, abgerufen am 10. September 2026.
- Factory: Data Flows & Privacy, abgerufen am 10. September 2026.
- Factory: Security, Identity & Access und Compliance & Audit, abgerufen am 10. September 2026.
- Factory: Telemetry Privacy Controls, abgerufen am 10. September 2026.
- Factory: Interaction Modes und Droid Computers, abgerufen am 10. September 2026.
- Factory Pricing, abgerufen am 10. September 2026.
- Factory: Why model routing must be in the harness, 24. August 2026, abgerufen am 10. September 2026.
- TechCrunch: Factory hits $1.5B valuation, 16. April 2026, abgerufen am 10. September 2026.
Weiterführende Artikel auf AI-Fabrik
- OpenAI Codex im Unternehmen: App, CLI, Cloud und Governance
- Claude Code Enterprise: Betriebsmodelle, Risiken und Pilotplan
- AWS Kiro im Unternehmen: Spec-Driven Development, Kosten und Governance
- JetBrains Junie im Unternehmen: IDE-Agent, Kosten und Governance
- Cognition Devin im Unternehmen: Plattform und Governance



