Wer Agenten produktiv baut, muss nicht nur Modelle und Tools wählen, sondern auch die Ausführungsumgebung. Kurzlebige, isolierte Compute-Instanzen werden dabei zum zentralen Architekturbaustein.
Viele Diskussionen über KI-Agenten kreisen fast ausschließlich um Modelle, Prompts und Tools. Das ist nachvollziehbar, aber unvollständig. Denn ein Agent, der wirklich arbeitet, braucht nicht nur Denken und Zugriff, sondern auch Ausführung.
Sobald Agenten Python-Code laufen lassen, Daten transformieren, Dokumente konvertieren, Skripte starten oder kundenspezifische Aufgaben bearbeiten, stellt sich eine viel praktischere Frage: Wo soll das eigentlich laufen?
Genau hier beginnt ein Architekturproblem, das in vielen Agenten-Demos noch ausgeblendet wird. Code-Ausführung ist nicht kostenlos, nicht neutral und vor allem nicht risikofrei. Wer Agenten produktiv baut, muss deshalb die Laufzeitumgebung genauso mitdenken wie das Modell selbst.
Seit sich KI-Agenten von reinen Chat-Interfaces zu echten Arbeitsprozessen entwickeln — orchestriert durch Frameworks wie LangGraph, AutoGen oder OpenHands — rückt genau diese Infrastrukturfrage ins Zentrum. Skalierung, Sicherheit und Kosten hängen dann weniger vom Prompt allein ab als von der Art, wie Ausführung orchestriert, isoliert und wieder beendet wird.
Cloudflares Dynamic Workers, die im März 2026 in die Open Beta gegangen sind, sind in diesem Zusammenhang ein präzises Signal. Nicht als allgemeine Antwort auf alles — sondern weil sie ein konkretes Ausführungsmodell für die spezifischen Anforderungen agentischer Systeme liefern: kurzlebig, isoliert, ohne vorheriges Deployment.
Das Architekturproblem
Ein Agent, der nur antwortet, braucht keine eigene Compute-Strategie. Ein Agent, der handelt, schon.
Das verändert den Threat-Modell grundlegend. Traditioneller Servercode wird von den eigenen Entwicklern geschrieben, gereviewed und deployt. Agent-generierter Code entsteht zur Laufzeit — er ist nicht vorhersagbar, nicht vorab prüfbar und kann nicht durch statische Analyse vollständig kontrolliert werden. Wenn dieser Code auf einer geteilten, persistenten Infrastruktur läuft, akkumuliert sich Risiko: Ein fehlerhafter oder kompromittierter Ausführungsschritt kontaminiert den nächsten.
Typische agentische Tasks sind heute:
- Python- oder JavaScript-Code ausführen, den das Modell selbst generiert hat
- Daten transformieren (CSV, JSON, XML, PDF, API-Antworten)
- kleine Tools für Kundenaufgaben dynamisch starten
- Workflow-Schritte in einer größeren Task-Kette isoliert ausführen
- Browser-Automation oder Terminal-Operationen mit eingeschränkten Rechten
Sobald das produktiv geschieht, wird die Ausführungsumgebung zur Sicherheits-, Kosten- und Betriebsfrage.
Warum klassische Server für agentische Workloads suboptimal sind
Viele Teams greifen zunächst zu dem, was sie kennen: bestehende Server, Container, Background Worker oder klassische App-Instanzen. Das funktioniert technisch — ist aber für agentische Workloads konzeptionell schief.
Die vier Kernprobleme:
Falsche Lebensdauer. Agentische Tasks sind kurzlebig und ungleichmäßig. Ein dauerhaft laufender Server, der für Spitzenlast dimensioniert ist, kostet bei Idle genauso wie unter Last.
Zu wenig Isolation. Mehrere parallele Agent-Sessions auf derselben Instanz teilen Prozessraum, Dateisystem und Netzwerkidentität. Bei mandantenfähigen Produkten ist das ein Daten- und Privilege-Eskalation-Risiko.
Zu breite Rechte. Geteilte Infrastruktur hat typischerweise weitreichende Netzwerk- und Dateisystemzugriffe, die für den einzelnen Agenten-Task nicht notwendig sind.
Kein erzwungenes Ende. Agenten-Tasks sollten nach ihrer Ausführung spurlos enden. Dauerprozesse akkumulieren Zustand, der spätere Tasks beeinflussen kann.
Diese Entwicklung passt in einen größeren Wandel der Cloud-Architektur. Wo früher dauerhafte APIs und Server dominierten, setzt sich zunehmend das Prinzip ephemeral compute durch — von AWS Lambda über Azure Container Apps bis hin zu Cloudflares Isolates. Für Agenten ist das kein Nice-to-have, sondern ein Sicherheitsprinzip.
V8 Isolates: das Ausführungsmodell im Detail
Cloudflares Workers basieren auf V8 Isolates — dem Ausführungsmodell, das ursprünglich für Browser-Multi-Tenancy entwickelt wurde: mehrere Tabs, mehrere Websites, ein OS-Prozess, keine gemeinsamen Objekte.
Jedes Isolate hat:
- einen eigenen unabhängigen Heap und Garbage Collector
- keinen geteilten Laufzeitstatus mit anderen Isolates
- keine Möglichkeit, auf Objekte anderer Isolates zuzugreifen (erzwungen durch V8s Memory Model)
Was das in der Praxis bedeutet, wird im Vergleich klarer:
| Dimension | V8 Isolate | Linux Container | Firecracker microVM |
|---|---|---|---|
| Startup | ~5 ms | 50–500 ms | ~125 ms |
| Memory overhead | ~3 MB | 35–100 MB | ~5 MB + Guest-Kernel |
| Isolation-Grenze | V8 Heap | Linux namespaces | eigener Linux-Kernel |
| Angriffsfläche | V8-Bugs | Kernel-Bugs | Hypervisor-Bugs |
| Sprach-Support | JS/TS + Wasm | beliebig | beliebig |
| Concurrent/Host | Tausende | Dutzende–Hunderte | Dutzende |
Die 10-100-fach bessere Speichereffizienz entsteht dadurch, dass die V8-Runtime selbst geteilt wird — nur der isolate-spezifische Heap ist exklusiv. Ein leerer Node.js Lambda-Container benötigt bereits rund 35 MB. Ein V8 Isolate kommt mit ~3 MB aus.
Cloudflare ergänzt die V8-Isolation durch einen zweiten Sandbox-Layer, Hardware Memory Protection Keys und eigene Spectre-Mitigationen. Der Trade-off bleibt: V8-Bugs treten häufiger auf als Hypervisor-Bugs. Für JavaScript- und TypeScript-Code ist das ein akzeptierter Kompromiss — für beliebigen Python-Code mit nativen Erweiterungen oder für stark regulierte Umgebungen ist ein MicroVM-Ansatz konservativer.
Code Mode: 81 Prozent weniger Token durch dynamische Ausführung
Cloudflares Dynamic Workers setzen die Idee des „Code Mode” in ein allgemeines Produkt um. Das Prinzip ist konzeptionell einfach, aber in seinen Konsequenzen erheblich:
Statt 10 bis 20 sequenzieller Tool-Calls — jeder mit eigenem LLM-Overhead, Token-Kosten und Latenz — generiert ein Agent eine einzelne TypeScript-Funktion, die alle Operationen in einem Schritt verbindet. Diese Funktion wird einmal in einem frischen Isolate ausgeführt.
Cloudflares eigene Messung: 81 Prozent Reduktion des Token-Verbrauchs gegenüber traditionellem Tool-Calling. Zite, eine Plattform für KI-gestützte CRUD-Apps, verarbeitet nach eigenen Angaben Millionen täglicher Anfragen über dieses Modell.
Das ist keine marginale Optimierung. Bei nennenswerten Agenten-Workloads macht dieser Unterschied den produktiven Einsatz überhaupt erst wirtschaftlich.
Das Pattern funktioniert aber nur mit schneller, on-demand-Code-Ausführung. Ein dauerhafter Background Worker kann dieselbe Semantik nicht liefern — er existiert bereits und akkumuliert Zustand zwischen Aufrufen.
Die Dynamic Workers API
Was Dynamic Workers technisch von älteren Ansätzen wie Workers for Platforms unterscheidet: Es ist kein vorheriges Deployment nötig. Code wird zur Laufzeit nachgeladen.
Die API besteht im Kern aus zwei Methoden:
// One-shot: frisches Isolate, kein Caching
const stub = workerLoader.load({
mainModule: 'entry',
modules: {
'entry': { js: agentGeneratedCode }
},
globalOutbound: null // kein Netzwerkzugriff aus dem Child
});
// Cached: Isolate nach ID abrufen oder erstellen
const stub = await workerLoader.get('task-id-123', async () => ({
mainModule: 'entry',
modules: { 'entry': { js: taskCode } }
}));Das WorkerCode-Objekt steuert, was der Child-Worker darf:
globalOutbound: null— vollständige Netzwerkisolationenv— explizite Bindings (KV, D1, R2, Service Bindings)tails— Tail Worker für Logs und Metriken des Child
Die Kommunikation zwischen Parent und Child läuft über Cap’n Web RPC — ein typisiertes Binary-Protokoll über die Isolate-Grenze. Der Parent definiert TypeScript-Interfaces, der dynamisch geladene Worker implementiert sie.
Seit Ende März 2026 ist das Feature für alle Workers-Nutzer im bezahlten Plan verfügbar. Die Abrechnung in der Beta: kostenlos. Danach 0,002 USD je eindeutig geladenem Worker pro Tag, plus Standard-Workers-CPU- und Invocation-Kosten.
Das Sandbox-Spektrum: Dynamic Workers im Vergleich
Dynamic Workers sind nicht das einzige Modell für agentische Code-Ausführung. Das Feld hat sich zuletzt stark entwickelt.
| Service | Isolation | Cold Start | Besondere Stärke |
|---|---|---|---|
| Cloudflare Dynamic Workers | V8 Isolate | ~5 ms | JS/TS-Geschwindigkeit, Edge-Netz |
| E2B | Firecracker microVM | ~150 ms | OSS, Filesystem-Snapshots |
| Modal | gVisor | <1 s | GPU-Workloads, ML/AI |
| Daytona | Docker/Kata | ~90 ms | Git/LSP-Integration, Coding Agents |
| Morph Cloud | Full VM + Snapshot | <250 ms | Branching, parallele Agent-Pfade |
| Azure Container Apps | Hyper-V | <100 ms | Azure-Ökosystem, pre-warmed Pools |
| AWS Bedrock AgentCore | Firecracker | Session-based | AWS-Deep-Integration, lange Sessions |
Die Wahl hängt vom konkreten Use Case ab. V8 Isolates sind unschlagbar schnell für JavaScript- und TypeScript-Code. Wer Python mit nativen C-Extensions, GPU-Zugriff oder mehrere Stunden lange Sessions braucht, ist mit Firecracker-basierten Diensten wie E2B oder AWS Bedrock AgentCore besser aufgehoben.
Morph Cloud ist interessant für Evals und parallele Exploration: Die „Infinibranch”-Technologie erlaubt es, von einem VM-Snapshot in unter 250 Millisekunden mehrere Instanzen zu branchen und gleichzeitig zu betreiben. Das ist besonders relevant für Agenten, die mehrere Lösungspfade parallel erkunden.
WebAssembly als Alternative
Zwischen V8 Isolates und MicroVMs gibt es eine dritte Option, die für agentische Systeme zunehmend relevant wird: WebAssembly Components.
Wasm erzwingt Isolation nicht durch Betriebssystemgrenzen, sondern auf Sprachebene. Code kann nur über explizit definierte Capability-Interfaces nach außen kommunizieren — keine impliziten Syscalls, kein Filesystem-Zugriff, kein Netzwerk ohne explizite Gewährung.
Fermyon Spin und wasmCloud (beide CNCF-Projekte) machen das produktiv nutzbar. Der architektonische Vorteil für Agenten: KI-generierter Code, der als Wasm-Komponente deployed wird, kann vor der Ausführung programmatisch inspiziert werden — welche Capabilities exportiert und importiert die Komponente? Ungültiger Code scheitert bereits beim Compile, nicht erst zur Laufzeit.
Der Nachteil: Python mit nativen C-Extensions oder CUDA-Code lässt sich nicht problemlos zu Wasm kompilieren. Wasm ist am stärksten für TypeScript-, Rust- und Go-basiertes Agent-Tooling.
Fermyon Spin 3.0 erreicht Cold Starts unter 0,5 Millisekunden — deutlich unter jedem Container- oder MicroVM-Ansatz.
Typische Use Cases
Kurzlebige Datenverarbeitung
CSV, JSON, XML, Markdown, PDFs, API-Antworten: Viele Agenten-Tasks sind im Kern Transformationsschritte. Dafür ist eine kurzlebige Compute-Einheit pro Task architektonisch sauberer als ein geteilter Dauerprozess.
Code ausführen, den der Agent selbst geschrieben hat
Das ist der Kernfall für Dynamic Workers. Der Agent generiert TypeScript oder JavaScript, das in einem frischen Isolate ausgeführt wird — ohne Persistenz, ohne geteilten Zustand, ohne Netzwerkzugriff, wenn nicht explizit gewährt.
Mandantenfähige Plattformen
Wenn Agenten Tasks für verschiedene Kunden oder Nutzer ausführen, ist die Trennung der Ausführungskontexte nicht optional. Kurzlebige Isolates oder MicroVMs pro Session verhindern Datenlecks und Privilege-Eskalation zwischen Mandanten.
Parallele Agent-Evaluation
Das Morph-Cloud-Pattern: Mehrere Agenten-Pfade werden gleichzeitig erkundet, um den besten Lösungsweg zu finden. Dafür braucht man nicht nur Isolation, sondern auch die Fähigkeit, Zustände zu branchen und wiederherzustellen.
Worauf man trotzdem achten muss
Kurzlebig ist nicht automatisch sicher. Auch bei isolierter Ausführung bleiben zentrale Architekturfragen.
Mandantentrennung ist explizit, nicht implizit
Technische Isolation erzwingt noch keine semantische Trennung. Welche Daten, Rechte und Seiteneffekte zu welchem Kontext gehören — das bleibt Designaufgabe.
Beobachtbarkeit gegen ephemeren Charakter
Temporäre Ausführung macht Debugging schwerer, nicht einfacher. Logs, Fehlermuster, Task-Herkunft und Laufzeit müssen aktiv instrumentiert werden. Dynamic Workers unterstützen Tail Workers als Logging-Sidecar — das muss aber bewusst konfiguriert werden.
Rechte eng schneiden
Isolierte Compute-Umgebungen sind nur dann ein Gewinn, wenn ihre Capabilities ebenfalls eng definiert sind. globalOutbound: null ist für viele Agent-Tasks die richtige Standardkonfiguration. Netzwerkzugriff sollte nur explizit gewährt werden.
Governance und Auditierbarkeit
Wer Code ausführt, den ein Modell generiert hat — ob direkt vom Agenten erzeugt oder aus Nutzer-Kontext übernommen — braucht mehr als technische Isolation. Logging-Pflicht, Datenherkunft, Aufbewahrungsregeln und nachvollziehbare Task-Zuordnung werden zu Governance-Themen.
Das gilt besonders in regulierten Branchen oder bei Verarbeitung personenbezogener Daten. Temporäre Compute-Instanzen helfen, Scope und potenzielle Seiteneffekte sauberer zu begrenzen — sie ersetzen aber keine Richtlinien dazu, was ausgeführt werden darf und wie diese Ausführung später geprüft werden kann.
V8 ist nicht für beliebigen Code geeignet
Für JavaScript und TypeScript ist das Isolate-Modell stark. Für beliebigen Python-Code mit nativen Erweiterungen, für GPU-Zugriff oder für Workloads, die echte Prozessisolation benötigen, ist eine MicroVM-basierte Lösung wie E2B oder AWS Bedrock AgentCore die sichere Wahl.
Einordnung
Der eigentliche Punkt an Dynamic Workers ist nicht, dass Cloudflare einen neuen Dienst eingeführt hat. Der Punkt ist die Architekturidee dahinter, die über Cloudflare hinaus gilt.
Agentische Systeme verändern den Threat-Modell von Infrastruktur. Wenn Code nicht mehr ausschließlich von menschlichen Entwicklern stammt, sondern zur Laufzeit von Modellen generiert wird, müssen Ausführungsumgebungen dafür ausgelegt sein: kurze Lebensdauer, enge Isolation, explizite Capabilities, spurloses Ende.
Das ist keine Spezialoptimierung für Edge-Compute-Enthusiasten. Es ist ein Designprinzip, das für jede ernsthaft betriebene Agenten-Plattform gilt — unabhängig davon, ob die Ausführung auf V8 Isolates, Firecracker MicroVMs, WebAssembly Components oder etwas anderem basiert.
Wenn Modelle zu Infrastrukturkomponenten werden, müssen Architekturen sich genauso dynamisch verhalten wie die Agenten selbst. Dynamic Execution dürfte deshalb zu einem der zentralen Designmuster agentischer Systeme werden — und der Blick auf Dynamic Workers, E2B, Morph Cloud oder Wasm-basierte Sandboxes ist weniger ein Blick auf konkrete Produkte als auf eine Architekturrichtung, die gerade Form annimmt.