Durable agent orchestration becomes a reusable serverless platform layer
Source → Observed → Interpretation → Model implication
Project Think: building the next generation of AI agents on Cloudflare
View source →Cloudflare presents Project Think as a set of Agents SDK primitives for long-running agents: durable execution, subagents, sandboxed code execution, and persistent sessions, together with an opinionated base class that connects them.
Cloudflare says Agents SDK instances use Durable Objects for per-agent identity, SQLite-backed state, wake-on-message operation, and hibernation without active compute; fibers register work before execution, support checkpoints, and can recover after the execution environment restarts.
Project Think stores tree-structured session messages, supports conversation forks and full-text history search, and uses non-destructive compaction while retaining the complete history in SQLite. Context blocks provide persistent memory that an agent can update across sessions.
Cloudflare describes an execution ladder spanning a durable workspace, network-disabled Dynamic Workers, runtime npm dependencies, browser automation, and full sandbox environments with repositories and development toolchains.
Dynamic Workers begin without ambient network authority. Developers grant resource-specific capabilities through bindings, and self-authored extensions declare network and workspace permissions that remain auditable and revocable.
The Think base class handles the agent loop, message persistence, streaming, tool execution, stream resumption, output truncation, and lifecycle hooks. The article shows hooks being used to record tool calls and alter tools or models between turns.
Project Think can create isolated child agents with their own conversation tree, memory, tools, model, and SQLite state. A parent delegates work and receives streamed results through typed RPC.
Cloudflare says code-mode execution lets a model write one sandboxed program that invokes multiple tools and processes their results instead of returning every intermediate result through the model context.
Project Think makes several engineering-environment variables explicit agent variants: durable or ephemeral execution, different compute tiers, scoped capabilities, persistent context, and single- or multi-agent configurations. This refines Selection by identifying mechanisms that may let longer-running and more numerous agents remain operable without proportional idle cost or ambient authority. Isolated state and typed subagent RPC make Cooperation a first-class infrastructure concern. Distinct parent, child, tool, and execution roles are adjacent to Specialization, but the source describes configurable architecture rather than evidence of stable differentiated cooperation emerging through repeated engineering work.
REFINES. The source refines the environment-as-fitness-function hypothesis by showing durability, context persistence, capability-scoped execution, coordination, observability, and idle economics converging in a reusable platform layer. It independently reinforces the shift from isolated agent capability toward engineering the surrounding system. Because the article reports available mechanisms rather than comparative engineering outcomes, it does not establish that subagent cooperation improves fitness or that persistent specialization has formed.
What this does not establish
- The source does not compare Project Think with an isolated agent or another harness on task quality, latency, reliability, total cost, or human attention.
- The 10,000-agent example is scaling arithmetic based on assumed activity, not evidence of a Project Think deployment operating at that scale.
- The statement that the broader Agents SDK powers thousands of production agents does not establish equivalent production use or reliability for Project Think, which the source labels experimental and available in preview.
- Typed RPC and isolated child state establish a coordination mechanism, not a durable cooperation advantage across repeated software-engineering tasks.
- Configurable child models, tools, memory, and roles do not establish stable Specialization or a cooperating system that has become a meaningful higher-order engineering object.
- Persistent memory and self-authored extensions do not establish that failures reliably improve later executions.
- The architectural, efficiency, and security properties are first-party claims and are not independently evaluated in the source.
Across repeated software-engineering tasks, which combinations of durability, execution isolation, persistent context, and subagent coordination improve useful outcomes relative to a simpler isolated agent after total compute, coordination, failure-recovery, and human-attention costs are included?