Factory startet OpenCompute: Agenten-Sandboxes laufen auf der Infrastruktur der Kunden

Factory hat OpenCompute vorgestellt, einen selbst gehosteten Orchestrator, der Agenten-Sandboxes auf einer vom Kunden gewählten Infrastruktur bereitstellt und verwaltet. Das Produkt befindet sich in der privaten Preview und ist in Factorys Funktionen Environments, Automations und Remote Control integriert.
- Factory hat OpenCompute vorgestellt, einen selbst gehosteten Orchestrator für Agenten-Sandboxes, derzeit in der privaten Preview.
- Er stellt Sandboxes auf vom Kunden gewählten Laufzeitumgebungen über Driver pro Anbieter bereit und verwaltet sie; integriert ist er in Environments, Automations und Remote Control.
- OpenCompute verbindet sich ausgehend per TLS-gesichertem WebSocket mit Factory, ein eingehender Firewall-Port ist nicht nötig.
- Laut Factory dauerte der erste On-Premises-Kundeneinsatz sechs Wochen ab dem frühen Prototyp; die erste Sandbox wurde nach zwei Tagen vor Ort bereitgestellt.
Von einer Maschine zur ganzen Flotte
Laut Factory wird aus dem Wandel von Agenten im Chatfenster hin zu Agenten, die Alarme untersuchen, asynchrone Anfragen beantworten, geplante Automations ausführen und im Tagesverlauf Issues übernehmen, ein Problem der Rechenleistung auf Abruf. Teams bräuchten nicht mehr bloß einen Ort, an dem ein Agent laufen kann, sondern eine Compute-Flotte, die mit der Arbeit Schritt hält.
Factory zufolge bringt OpenCompute bedarfsgesteuerte Bereitstellung und Lebenszyklusverwaltung auf kundenkontrollierte Infrastruktur. Das Unternehmen stellt das Produkt unter eine Überzeugung: Wer autonome Softwareentwicklung einführt, sollte dafür nicht die Schlüssel zur eigenen Infrastruktur an Dritte abgeben müssen.
Das Produkt baut auf Remote Control und Droid Computers auf. Droid Computers hatte Factory im April 2026 als persistente Maschinen zur Orchestrierung von Droids eingeführt. Kunden konnten eine solche Maschine in Factorys Cloud erstellen oder ihre eigene Maschine über Remote Control registrieren. Weil die Ausführungsschleife des Agenten auf dieser Maschine läuft, kann Droid auf private Repositories, Paketregister und interne Dienste zugreifen, ohne dass diese Systeme öffentlich erreichbar sein müssen.
Factory sagt, dass bei Unternehmenskunden dennoch eine Lücke blieb: Sie müssten Flotten verwalten, nicht einzelne Rechner. Ein Alarm sollte eine Untersuchung auslösen können, ohne dass zuvor jemand eine VM bereitstellt, und eine erledigte Aufgabe sollte keine ungenutzten Ressourcen zurücklassen. Selbst gehosteten Maschinen fehlten die native Bereitstellung, Suspendierung und Wiederaufnahme, die Factorys verwaltetes Angebot bereits bot. Die Kunden mussten die Flotte daher selbst betreiben.
Eine Schicht über dem Compute-Anbieter
Factory beobachtete große Unterschiede in der Infrastruktur seiner Kunden. Manche wollten Agenten auf bestehenden Kubernetes-Clustern betreiben, manche auf spezialisierter Hardware, andere auf einer internen Plattform, die ihre Entwickler bereits nutzten. Als Beleg für die Nachfrage nach Bring-your-own-Cloud- und Bring-your-own-Infrastructure-Ansätzen verweist das Unternehmen auf Sandbox-Plattformen von Drittanbietern wie E2B, Daytona und Modal sowie auf Projekte wie Kubernetes Agent Sandbox, Googles Agent Substrate und AWS Lambda MicroVMs.
Statt sich für ein Backend zu entscheiden, baute Factory eine Schicht oberhalb der Compute-Infrastruktur. OpenCompute verantwortet den gemeinsamen Lebenszyklus: einen Rechner anfordern, ihn in den gewünschten Zustand bringen, seine Aktivität verfolgen und ihn gemäß Richtlinien und Fähigkeiten des Anbieters suspendieren oder beenden. Der Anbieter verantwortet die Infrastrukturmechanismen hinter diesen Operationen.
Die Integration pro Anbieter heißt Driver. Factory sagt, man habe Integrationen für AWS Lambda MicroVMs, Kubernetes, EC2, Agent Sandbox, Agent Substrate und weitere experimentelle Anbieter entwickelt und evaluiert. Dabei habe es sich nicht um identische Implementierungen oder gleich ausgereifte Backends gehandelt, und die Architektur sei darauf ausgelegt, diese Unterschiede aufzufangen.
Außerdem sei die Arbeit von Anfang an agentennativ gewesen. Ingenieure legten Grenzen, Verhalten und Konformitätstests fest, den Rest übernahmen Droids unter menschlicher Anleitung. Eine Aufgabe wie die Umsetzung eines Vertrags samt erfüllter Konformitätstests gebe einem Agenten ein klar umrissenes Problem mit überprüfbarem Ergebnis, argumentiert das Unternehmen.
Architektur und erster Einsatz
OpenCompute läuft in der Umgebung des Kunden und baut eine ausgehende, per TLS gesicherte WebSocket-Verbindung zu Factory auf, über die Factory autorisierte Compute-Anfragen sendet. Laut Factory sind weder ein öffentlicher OpenCompute-Endpunkt noch ein eingehender Firewall-Port nötig. Bei der Registrierung hinterlegt die Installation einen öffentlichen Schlüssel bei Factory und weist den Besitz des privaten Schlüssels nach, indem sie eine frische Challenge signiert. Der private Schlüssel bleibt unter Kontrolle des Kunden und kann in einem unterstützten Cloud-KMS liegen.
Jede Sandbox baut eine eigene ausgehende Verbindung zu Factory auf, so wie es ferngesteuerte Rechner heute tun. Factory weist darauf hin, dass die Platzierung der Rechenleistung getrennt von Inferenz-Routing und Sitzungsspeicherung erfolgt. Ob Sitzungsdaten vollständig lokal bleiben, hängt daher von der Konfiguration für Inferenz und Synchronisierung ab.
Für die Lebenszyklusverwaltung beschreibt Factory ein deklaratives Modell. Eine Control Plane in Go hält den gewünschten und den beobachteten Zustand der Rechner in einer Postgres-Datenbank in der Umgebung des Kunden fest, ein Reconciler arbeitet darauf hin, beide in Einklang zu bringen. Damit sollen abgebrochene Verbindungen, Drosselung durch den Anbieter und Neustarts bewältigt werden, die nach einer erfolgreichen Anfrage, aber vor Eintreffen der Antwort auftreten.
Der erste Kundeneinsatz war eine maßgeschneiderte On-Premises-Umgebung mit einer hauseigenen Anbieterschnittstelle. Factory sagt, man habe kurz vor dem Einstieg in ein Flugzeug zum Kunden eine Mission für den ersten Driver gestartet, und bei der Landung sei der Driver fertig gewesen. Nach zwei Tagen vor Ort stellte der Kunde über OpenCompute seine erste Sandbox bereit, die in seinem eigenen Rechenzentrum läuft. Vom frühen Prototyp bis zu diesem Einsatz vergingen laut Factory sechs Wochen; Persistenz, Wiederherstellung, Deployment-Werkzeuge und betriebliche Härtung seien danach weiterentwickelt worden.
Was das für Kunden bedeutet
Für Organisationen, die Agenten nicht in der Cloud eines Anbieters betreiben können oder wollen, soll OpenCompute eine Bereitstellung wie im verwalteten Angebot auf der eigenen Laufzeitumgebung ermöglichen. Factory sagt, die Bedienung gleiche dem Anlegen eines verwalteten Droid Computers, auch wenn die Sandbox im Rechenzentrum des Kunden läuft. Der Zugang ist derzeit auf eine private Preview beschränkt; zu Preisen oder allgemeiner Verfügbarkeit macht die Quelle keine Angaben.
Factory: Introducing OpenCompute


