Project Think: Aufbau von KI-Agenten der nächsten Generation mit Cloudflare

• Cloudflare hat Project Think angekündigt, die nächste Version des Agents SDK, und bietet damit neue Kernprimitiven für langlebig laufende Agenten: dauerhafte Ausführung, Sub-Agenten, Sandbox-Codeausführung und persistente Sessions
• Bisherige Coding-Agenten hatten Grenzen: Sie liefen nur auf lokalen Laptops, verursachten auch im Leerlauf Kosten und erforderten manuelle Einrichtung und Verwaltung
• Anders als klassische Anwendungen arbeiten Agenten im 1:1-Modell (eine Instanz pro Nutzer und pro Aufgabe). Um zig Millionen gleichzeitige Sessions zu unterstützen, ist eine containerbasierte Kostenstruktur nicht nachhaltig
• Mithilfe des auf Durable Objects basierenden Actor-Modells erreichen Agenten ökonomische Skalierbarkeit im großen Maßstab: keine Computing-Kosten im Ruhezustand und automatisches Aufwachen bei eingehenden Nachrichten
• Als dritte Welle der KI-Agenten zielt Cloudflare auf Agenten als Infrastruktur (Langlebigkeit, Verteilung, Serverless, strukturelle Sicherheit) und auf eine Plattform, mit der alle Entwickler Agenten für Milliarden Nutzer bauen und bereitstellen können

---

Überblick über Project Think

• Die nächste Version des Cloudflare Agents SDK bietet einen neuen Satz an Primitiven zum Aufbau langlebig laufender Agenten sowie eine Basisklasse, die diese integriert
• Zentrale Primitiven: dauerhafte Ausführung (Fibers), Sub-Agenten, persistente Sessions, Sandbox-Codeausführung, Execution Ladder, selbst verfasste Erweiterungen
• Die Primitiven lassen sich einzeln verwenden oder für einen schnellen Start über die Think-Basisklasse

Aktuelle Grenzen von Coding-Agenten

• Tools wie Pi, OpenClaw, Claude Code und Codex haben gezeigt, dass LLMs mit Fähigkeiten zum Lesen von Dateien, Schreiben, Ausführen und Lernen von Code wie universelle Assistenten agieren können
• Solche Coding-Agenten lassen sich nicht nur für Code einsetzen, sondern auch für Kalenderverwaltung, Datensatzanalyse, Einkaufsverhandlungen, Steuererklärungen und die Automatisierung von Business-Workflows
• Das Muster ist immer gleich: Der Agent liest Kontext, schlussfolgert, schreibt Code, handelt, beobachtet das Ergebnis und wiederholt den Vorgang → Code ist das universelle Medium des Handelns
• Aktuelle Grenzen:
  • Laufen nur auf Laptops oder teuren VPS: kein Teilen, keine Zusammenarbeit, kein Wechsel zwischen Geräten
  • Kosten auch im Leerlauf: fixe Monatskosten steigen bei Skalierung auf Teams und Unternehmen stark an
  • Manuelle Installation und Verwaltung nötig: Abhängigkeiten installieren, Updates verwalten, Authentifizierung und Secrets konfigurieren

Das strukturelle Problem von Agenten: das 1:1-Modell

• Traditionelle Anwendungen bedienen mit einer Instanz viele Nutzer, aber Agenten sind 1:1 — jeder Agent ist eine eigene Instanz für einen Nutzer und eine Aufgabe
• Wenn 100 Millionen Wissensarbeiter jeweils einen Agenten-Assistenten nutzen, sind zig Millionen gleichzeitige Sessions nötig
• Mit der heutigen Kostenstruktur pro Container ist das nicht tragfähig; es braucht ein anderes Fundament

Langlebig laufende Agenten

• Heutige Agenten sind ephemeral: Sie verschwinden nach Ende einer Session und stoppen, wenn der Laptop in den Ruhezustand geht
• Das Agents SDK verleiht jedem Agenten auf Basis von Durable Objects eine Identität, persistenten Zustand und die Fähigkeit, beim Empfang von Nachrichten automatisch zu starten
• Actor-Modell: Jeder Agent ist eine adressierbare Entität mit eigener SQLite-Datenbank und verursacht im Ruhezustand keine Computing-Kosten
• Bei Ereignissen wie HTTP-Anfragen, WebSocket-Nachrichten, geplanten Alarmen oder eingehenden E-Mails weckt die Plattform den Agenten auf und lädt seinen Zustand
• Vergleich Durable Objects gegenüber VMs/Containern:
  • Leerlaufkosten: VM trägt ständig volle Computing-Kosten, DO null (hiberniert)
  • Skalierung: VM erfordert manuelles Provisioning, DO skaliert automatisch pro Agent
  • Zustand: VM braucht externe DB, DO hat eingebautes SQLite
  • Wiederherstellung: VM muss selbst gebaut werden, DO startet durch die Plattform automatisch neu und behält den Zustand
  • Routing: VM erfordert selbst gebaute Load Balancer und Sticky Sessions, DO hat integriertes Mapping von Name → Agent
  • 10.000 Agenten (je 1 % aktiv): VM braucht 10.000 dauerhaft laufende Instanzen, DO nur rund 100 aktive
• Die Grenzkosten für das Erzeugen eines neuen Agenten sind praktisch null → Modelle wie „einer pro Nutzer“, „einer pro Aufgabe“ oder „einer pro E-Mail-Thread“ werden möglich

Dauerhafte Ausführung: Fibers

• LLM-Aufrufe können 30 Sekunden dauern, mehrstufige Agenten-Loops noch länger, und dazwischen kann die Laufzeitumgebung verschwinden (Deployment, Plattform-Neustart, Ressourcenlimits)
• runFiber(): ein dauerhafter Funktionsaufruf, der vor dem Start in SQLite registriert wird, Checkpoints via stash() ermöglicht und über onFiberRecovered nach einem Neustart wiederhergestellt werden kann
• Das SDK hält den Agenten während der Fiber-Ausführung automatisch aktiv; besondere Konfiguration ist nicht nötig
• Für Aufgaben über mehrere Minuten verhindern keepAlive() / keepAliveWhile() das Verdrängen
• Für längere Jobs wie CI-Pipelines, Design-Reviews oder Videogenerierung wird nach Start des Jobs die Job-ID gespeichert und dann hiberniert, bis ein Callback eintrifft

Sub-Agenten: Facets

• Ein einzelner Agent muss nicht alle Aufgaben selbst ausführen
• Sub-Agenten sind zusammen mit dem Eltern-Agenten platzierte untergeordnete Durable Objects mit jeweils isoliertem SQLite und eigenem Ausführungskontext
• Auf Basis von Facets befinden sie sich am selben Ort wie der Eltern-Agent; Daten werden zwischen Sub-Agenten nicht implizit geteilt
• Die RPC-Latenz zwischen Sub-Agenten liegt auf dem Niveau eines Funktionsaufrufs, und TypeScript erkennt Fehlgebrauch zur Compile-Zeit

Persistente Sessions: Session API

• Agenten, die über Tage oder Wochen laufen, brauchen mehr als eine gewöhnliche flache Nachrichtenliste
• Die experimentelle Session API modelliert Unterhaltungen als Baumstruktur und gibt jeder Nachricht eine parent_id
  • Forking: Alternativen erkunden, ohne den ursprünglichen Pfad zu verlieren
  • Nicht-destruktive Komprimierung: alte Nachrichten nicht löschen, sondern zusammenfassen
  • Volltextsuche: Volltextsuche über den gesamten Gesprächsverlauf auf Basis von FTS5
• Kann direkt in der Agent-Basisklasse verwendet werden und dient als Speicherschicht der Think-Basisklasse

Von Tool-Calls zur Codeausführung

• Bisheriger Tool-Call-Ansatz: Das Modell ruft ein Tool auf → das Ergebnis wird ins Kontextfenster zurückgeführt → Wiederholung; bei vielen Tools steigen Kosten und Ineffizienz
• 100 Dateien = 100 Hin-und-her-Runden mit dem Modell
• Modelle sind besser darin, Code für die Nutzung eines Systems zu schreiben, als ein Tool-Calling-Spiel zu spielen — das ist die Kernidee von @cloudflare/codemode
• Statt sequenzieller Tool-Calls schreibt das LLM ein einziges Programm, das die gesamte Aufgabe erledigt
• Beispiel des Cloudflare-API-MCP-Servers: Nur zwei Tools (search(), execute()) werden freigegeben und verbrauchen rund 1.000 Tokens statt etwa 1,17 Millionen Tokens bei einem Tool-pro-Endpunkt-Ansatz → 99,9 % weniger

Sichere Sandbox: Dynamic Workers

• Wenn das Modell im Namen des Nutzers Code schreibt, ist die Ausführungsumgebung dieses Codes die Kernfrage
• Dynamic Workers: neue V8-Isolates, die zur Laufzeit in Millisekunden erzeugt werden und nur wenige Megabyte Speicher nutzen
  • Gegenüber Containern etwa 100-mal schneller und bis zu 100-mal speichereffizienter
  • Können für jede Anfrage neu erzeugt und nach der Codeausführung verworfen werden
• Zentrales Design: Capability-Modell — statt eine generische Maschine nachträglich einzuschränken, startet sie nahezu ohne Rechte (globalOutbound: null, kein Netzwerkzugang), und der Entwickler gewährt über Bindings explizite Rechte pro Ressource
• Der Fokus verschiebt sich von „Wie verhindere ich, dass das zu viel tut?“ zu „Was genau soll das tun dürfen?“

Execution Ladder

• Ein Spektrum, in dem Agenten je nach Bedarf schrittweise in leistungsfähigere Computing-Umgebungen eskalieren:
  • Tier 0 — Workspace: dauerhaftes virtuelles Dateisystem auf Basis von SQLite + R2, unterstützt Lesen, Schreiben, Bearbeiten, Suchen, grep, diff und führt @cloudflare/shell aus
  • Tier 1 — Dynamic Worker: führt vom LLM generiertes JavaScript in einer sandboxierten isolierten Umgebung ohne Netzwerkzugang aus und betreibt @cloudflare/codemode
  • Tier 2 — npm hinzufügen: @cloudflare/worker-bundler holt Pakete aus dem Registry, bündelt sie mit esbuild und lädt sie in den Dynamic Worker; import { z } from "zod" funktioniert unverändert
  • Tier 3 — Headless Browser: Cloudflare Browser Run für Navigation, Klicks, Extraktion und Screenshots, nützlich für Dienste ohne MCP- oder API-Unterstützung
  • Tier 4 — Cloudflare Sandbox: führt git clone, npm test, cargo build usw. in einer Umgebung mit eingerichtetem Toolchain, Repo und Abhängigkeiten aus; bidirektionale Synchronisierung mit dem Workspace
• Zentrales Designprinzip: Schon Tier 0 allein muss dem Agenten Nutzen bringen; jede weitere Stufe ist optional ergänzend

Building Blocks, kein Framework

• Alle Primitiven werden als unabhängige Pakete bereitgestellt: Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• Sie lassen sich direkt mit der Agent-Basisklasse kombinieren, um Workspace, Codeausführung und Laufzeit-Paketauflösung ohne Einführung eines eigenen Frameworks zu nutzen

Der vollständige Plattform-Stack

• Isolation pro Agent: Durable Objects — jeder Agent hat seine eigene Welt
• Null Kosten im Leerlauf: DO Hibernation — $0, bis der Agent wieder aufwacht
• Persistenter Zustand: DO SQLite — Speicher mit Queries und Transaktionen
• Dauerhaftes Dateisystem: Workspace (SQLite + R2)
• Sandbox-Codeausführung: Dynamic Workers + @cloudflare/codemode
• Abhängigkeiten zur Laufzeit: @cloudflare/worker-bundler — import * from react funktioniert unverändert
• Web-Automatisierung: Browser Run
• Voller OS-Zugriff: Sandboxes — git, Compiler, Test-Runner
• Zeitgesteuerte Ausführung: DO Alarms + Fibers
• Echtzeit-Streaming: WebSockets
• Anbindung externer Tools: MCP
• Koordination zwischen Agenten: Sub-Agenten (Facets) — typisiertes RPC
• Modellzugriff: AI Gateway + Workers AI (oder eigene Modelle)

Think-Basisklasse

• Ein integriertes Harness für den gesamten Chat-Lifecycle einschließlich Agenten-Loop, Nachrichtenpersistenz, Streaming, Tool-Ausführung, Stream-Fortsetzung und Erweiterungen
• Für eine minimale Subklasse muss nur die Methode getModel() implementiert werden; daraus entsteht ein Chat-Agent mit Streaming, Persistenz, Unterbrechung/Abbruch, Fehlerbehandlung, wiederaufnehmbaren Streams und eingebautem Workspace-Dateisystem
• Deployment mit npx wrangler deploy
• Überschreibbare Elemente: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• In jedem Zug läuft der vollständige agentische Loop: Kontext zusammenbauen (Basisanweisungen + Tool-Beschreibungen + Skills + Memory + Gesprächsverlauf) → streamText aufrufen → Tool-Calls ausführen (mit gekürzten Ausgaben zur Vermeidung von Kontextexplosion) → Ergebnisse hinzufügen → Wiederholung bis zum Abschluss durch das Modell oder bis zum Step-Limit

Lifecycle-Hooks

• Think besitzt nicht zwingend die gesamte Pipeline, bietet aber Hooks für jede Phase eines Chat-Zugs:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• Damit lassen sich z. B. in Folgezügen günstigere Modelle wählen, Tools begrenzen, Client-Kontext weiterreichen, Analyselogs für alle Tool-Calls erfassen oder automatisch Folgezüge auslösen — ohne onChatMessage zu ersetzen

Persistentes Memory und lange Gespräche

• Think basiert auf der Session API und hat Baumstruktur-Nachrichten sowie Branching eingebaut
• Persistentes Memory über Kontextblöcke: strukturierte Abschnitte im System Prompt, die das Modell lesen und über die Zeit aktualisieren kann; sie bleiben auch über Hibernation hinweg erhalten
• Das Modell sieht z. B. „MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]“ und kann dadurch proaktiv erinnern
• Pro Agent sind mehrere Gespräche möglich; durch Forking lassen sich alternative Richtungen erkunden, ohne das ursprüngliche Gespräch zu verlieren
• Bei wachsendem Kontext erfolgt nicht-destruktive Komprimierung: Alte Nachrichten werden zusammengefasst statt gelöscht, der gesamte Verlauf bleibt in SQLite erhalten
• Suche auf Basis von FTS5: Der Gesprächsverlauf kann innerhalb einer Session oder über alle Sessions hinweg abgefragt werden; der Agent kann mit dem Tool search_context auch seine eigene Vergangenheit durchsuchen

Integration der vollständigen Execution Ladder

• Think integriert mit einer einzigen Rückgabe von getTools() die gesamte Execution Ladder: Workspace-Tools, Ausführungstools, Browser-Tools, Sandbox-Tools und Erweiterungstools auf einmal

Selbst verfasste Erweiterungen (Self-authored Extensions)

• Agenten können eigene Erweiterungen selbst schreiben: TypeScript-Programme, die in Dynamic Workers laufen und Netzwerkzugang sowie Berechtigungen für Workspace-Operationen deklarieren
• Der ExtensionManager von Think bündelt Erweiterungen (einschließlich npm-Abhängigkeiten), lädt sie in einen Dynamic Worker und registriert neue Tools
• Erweiterungen werden persistent im DO-Speicher abgelegt und überleben auch Hibernation
• Beispiel: Wenn ein Nutzer eine Frage zu einem PR stellt, kann ein github_create_pr-Tool entstehen, das es 30 Sekunden zuvor noch nicht gab
• Kein Fine-Tuning und kein RLHF, sondern eine Selbstverbesserungsschleife über Code — sandboxiertes, auditierbares und widerrufbares TypeScript

Sub-Agenten-RPC

• Think kann auch als Sub-Agent laufen, der vom Eltern-Agenten über chat() per RPC aufgerufen wird, inklusive Unterstützung für Streaming-Events per Callback
• Jedes Kind besitzt seinen eigenen Gesprächsbaum, Memory, Tools und sein eigenes Modell; der Eltern-Agent muss die Details nicht kennen

Erste Schritte

• Project Think befindet sich im experimentellen Status; die API-Oberfläche ist stabil, wird sich aber weiterentwickeln
• Cloudflare nutzt es intern bereits zum Aufbau eigener Infrastruktur für Hintergrund-Agenten
• Think verwendet dasselbe WebSocket-Protokoll wie @cloudflare/ai-chat, daher funktionieren bestehende UI-Komponenten unverändert
• Wer auf Basis von AIChatAgent gebaut hat, braucht keine Änderungen am Client-Code

Drei Wellen von KI-Agenten

• Erste Welle — Chatbots: zustandslos, reaktiv, fragil, beginnen jede Unterhaltung von vorn, ohne Memory, Tools oder Handlungsfähigkeit, nur für Frage-Antwort nützlich
• Zweite Welle — Coding-Agenten: zustandsbehaftet, nutzen Tools; Werkzeuge wie Pi, Claude Code, OpenClaw und Codex können Codebasen lesen, Code schreiben, ausführen und iterieren und zeigen, dass ein LLM mit den richtigen Tools eine universelle Maschine ist; sie laufen jedoch nur auf Laptops, für einen einzelnen Nutzer und ohne garantierte Dauerhaftigkeit
• Dritte Welle — Agenten als Infrastruktur: langlebig, verteilt, strukturell sicher, serverless, im Internet laufend, fehlertolerant, ohne Kosten im Leerlauf und mit durch Architektur erzwungener Sicherheit statt durch reine Verhaltensregeln