Project Think: Cloudflare में अगली पीढ़ी के AI एजेंट बनाना

• Cloudflare ने Agents SDK के next-generation version, Project Think, की घोषणा की है, जो long-running agents के लिए durable execution, sub-agents, sandboxed code execution, persistent sessions जैसे नए core primitives प्रदान करता है
• मौजूदा coding agents की सीमाएँ थीं कि वे केवल local laptop पर चलते हैं, idle रहने पर भी लागत आती है, और manual setup तथा management की ज़रूरत होती है
• पारंपरिक applications के विपरीत, agents 1:1 model पर काम करते हैं (एक user और एक task के लिए एक instance), इसलिए tens of millions concurrent sessions को container-based cost structure पर support करना टिकाऊ नहीं है
• Durable Objects आधारित actor model का उपयोग करके, agent के idle होने पर compute cost शून्य हो जाती है, और message मिलते ही वह अपने-आप जाग जाता है, जिससे large-scale expansion economics संभव होती है
• AI agents की तीसरी लहर के रूप में यह infrastructure as agents (durability, distribution, serverless, structural security) की दिशा में बढ़ता है, और लक्ष्य एक ऐसा platform बनाना है जहाँ हर developer अरबों users के लिए agents बना और deploy कर सके

---

Project Think का परिचय

• Cloudflare Agents SDK का next-generation version, जो long-running agents बनाने के लिए नए primitives का set और उन्हें integrate करने वाली base class प्रदान करता है
• मुख्य primitives: durable execution (fibers), sub-agents, persistent sessions, sandboxed code execution, execution ladder, self-authored extensions
• इन primitives को अलग-अलग इस्तेमाल किया जा सकता है, या Think base class के साथ जल्दी शुरुआत की जा सकती है

Coding agents की मौजूदा सीमाएँ

• Pi, OpenClaw, Claude Code, Codex जैसे tools ने साबित किया है कि जब LLM को file पढ़ने, code लिखने, execute करने और सीखने की क्षमता दी जाती है, तो वह general-purpose assistant की तरह काम कर सकता है
• ऐसे coding agents का उपयोग सिर्फ code ही नहीं, बल्कि calendar management, dataset analysis, purchase negotiation, tax filing, business workflow automation जैसी चीज़ों में भी हो सकता है
• pattern हमेशा एक जैसा है: agent context पढ़ता है, reasoning करता है, code लिखकर action लेता है, result देखता है, और फिर दोहराता है → code action का universal medium है
• मौजूदा सीमाएँ:
  • सिर्फ laptop या महंगे VPS पर चलना: sharing, collaboration, devices के बीच switching संभव नहीं
  • idle रहने पर भी लागत: fixed monthly cost team या company स्तर पर तेज़ी से बढ़ती है
  • manual install और management की ज़रूरत: dependency install, update management, authentication और secrets setup

Agents की संरचनात्मक समस्या: 1:1 model

• पारंपरिक applications में एक instance कई users को serve करता है, लेकिन agents 1:1 होते हैं — हर agent एक unique instance के रूप में एक user और एक task को संभालता है
• अगर 10 करोड़ knowledge workers में से हर एक agent assistant इस्तेमाल करे, तो tens of millions concurrent sessions की ज़रूरत होगी
• मौजूदा per-container cost structure पर यह टिकाऊ नहीं है, इसलिए अलग foundation की आवश्यकता है

Long-running agents

• मौजूदा agents ephemeral हैं: session खत्म होते ही गायब हो जाते हैं, और laptop sleep होने पर रुक जाते हैं
• Agents SDK, Durable Objects के आधार पर, हर agent को identity, persistent state, और message मिलते ही auto-start होने की क्षमता देता है
• Actor model में हर agent एक addressable entity होता है, जिसके पास अपनी SQLite database होती है, और idle रहने पर compute cost शून्य होती है
• HTTP request, WebSocket message, scheduled alarm, incoming email जैसे event होने पर platform agent को जगाता है और state load करता है
• VM/container की तुलना में Durable Objects:
  • idle cost: VM में हमेशा full compute cost बनाम DO में zero (hibernation)
  • scaling: VM में manual provisioning बनाम DO में per-agent automatic scaling
  • state: VM में external DB की ज़रूरत बनाम DO में built-in SQLite
  • recovery: VM में खुद बनाना पड़ता है बनाम DO में platform auto-restart और state preservation
  • routing: VM में load balancer और sticky sessions खुद बनानी पड़ती हैं बनाम DO में name → agent built-in mapping
  • 10,000 agents (हर एक 1% active): VM में 10,000 always-on instances बनाम DO में लगभग 100 ही active
• नया agent बनाने की marginal cost लगभग zero है → “प्रति user एक”, “प्रति task एक”, “प्रति email thread एक” जैसे agent model संभव होते हैं

Durable execution: Fibers

• LLM call 30 सेकंड तक चल सकती है, और multi-turn agent loop उससे भी ज़्यादा चल सकता है; इस बीच execution environment गायब हो सकता है (deployment, platform restart, resource limits)
• runFiber(): execution शुरू होने से पहले SQLite में register होने वाला durable function call, जो stash() के जरिए checkpoint बनाता है और onFiberRecovered के जरिए restart पर recover हो सकता है
• SDK fiber execution के दौरान agent को अपने-आप alive रखता है, किसी special setup की ज़रूरत नहीं
• मिनटों में चलने वाले tasks के लिए keepAlive() / keepAliveWhile() eviction रोकते हैं
• CI pipeline, design review, video generation जैसे लंबे tasks में job शुरू करके job ID save कर, agent को hibernate कराया जा सकता है, और callback आने पर वह फिर जाग जाता है

Sub-agents: Facets

• ज़रूरी नहीं कि एक ही agent हर task करे
• Sub-agents parent के साथ co-located child Durable Objects होते हैं, जिनमें से हर एक के पास isolated SQLite और execution context होता है
• Facets के आधार पर वे parent agent के साथ place होते हैं, और sub-agents के बीच data implicit रूप से share नहीं होता
• Sub-agent RPC latency function call के स्तर की होती है, और TypeScript compile time पर misuse पकड़ लेता है

Persistent sessions: Session API

• दिन या हफ्तों तक चलने वाले agents के लिए सामान्य flat message list से अधिक की ज़रूरत होती है
• experimental Session API conversations को tree structure के रूप में model करती है, जहाँ हर message के साथ parent_id होता है
  • forking: original path खोए बिना alternatives explore करना
  • non-destructive compaction: पुराने messages को delete करने के बजाय summarize करना
  • full-text search: FTS5 आधारित पूरी conversation history में search
• इसे Agent base class में सीधे इस्तेमाल किया जा सकता है, और यह Think base class की storage layer का काम करता है

Tool calling से code execution तक

• पारंपरिक tool-calling model: model tool call करता है → result context window में वापस आता है → फिर दोहराव; tools बढ़ने पर cost और inefficiency बढ़ती है
• 100 files = model के साथ 100 round trips
• model, tool-calling game खेलने से ज़्यादा system इस्तेमाल करने के लिए code लिखने में बेहतर है — यही @cloudflare/codemode की मुख्य insight है
• sequential tool calls के बजाय LLM पूरे task को संभालने वाला एक single program लिखता है
• Cloudflare API MCP server के उदाहरण में सिर्फ 2 tools (search(), execute()) expose करने पर लगभग 1,000 tokens लगे, जबकि per-endpoint tool model में लगभग 11.7 लाख tokens लगते — यानी 99.9% reduction

सुरक्षित sandbox: Dynamic Workers

• अगर model user की ओर से code लिखता है, तो सवाल यह बनता है कि वह code कहाँ execute होगा
• Dynamic Workers: runtime पर milliseconds में बनने वाला नया V8 isolated environment, जिसमें कुछ megabytes memory होती है
  • container की तुलना में लगभग 100x तेज़ और अधिकतम 100x memory-efficient
  • हर request पर नया बनाया जा सकता है और code execution के बाद discard किया जा सकता है
• मुख्य design: capability model — general-purpose machine को restrict करने के बजाय, लगभग no-permission state (globalOutbound: null, network access नहीं) से शुरू करना, और developer bindings के जरिए resource-by-resource explicit permission देना
• “इसे बहुत ज़्यादा करने से कैसे रोकें?” से “इसे ठीक-ठीक क्या करने की अनुमति दें?” की ओर बदलाव

Execution Ladder

• एक spectrum जिसमें agent ज़रूरत के अनुसार step-by-step ऊँचे compute environment तक escalate करता है:
  • Tier 0 — Workspace: SQLite + R2 आधारित durable virtual filesystem, read/write/edit/search/grep/diff support, @cloudflare/shell चलता है
  • Tier 1 — Dynamic Worker: LLM-generated JavaScript को network access के बिना sandboxed isolated environment में execute करना, @cloudflare/codemode चलता है
  • Tier 2 — npm add-ons: @cloudflare/worker-bundler registry से packages लाता है, esbuild से bundle करता है, और Dynamic Worker में load करता है; import { z } from "zod" सीधे काम करता है
  • Tier 3 — Headless browser: Cloudflare Browser Run के साथ navigation, click, extraction, screenshot; MCP या API support न करने वाली services के लिए उपयोगी
  • Tier 4 — Cloudflare Sandbox: ऐसे environment में git clone, npm test, cargo build जैसे commands जहाँ toolchain, repo, dependencies configured हों; Workspace के साथ bidirectional sync
• मुख्य design principle: सिर्फ Tier 0 से भी agent उपयोगी होना चाहिए, और हर tier अतिरिक्त होना चाहिए

Building blocks, framework नहीं

• सभी primitives independent packages के रूप में उपलब्ध हैं: Dynamic Workers, @cloudflare/codemode, @cloudflare/worker-bundler, @cloudflare/shell
• इन्हें Agent base class के साथ सीधे जोड़कर workspace, code execution, runtime package resolution जैसी capabilities अपना अलग framework अपनाए बिना इस्तेमाल की जा सकती हैं

Platform का पूरा stack

• प्रति-agent isolation: Durable Objects — हर agent की अपनी दुनिया
• idle पर zero cost: DO Hibernation — agent के फिर जागने तक $0
• persistent state: DO SQLite — query और transaction योग्य storage
• durable filesystem: Workspace (SQLite + R2)
• sandboxed code execution: Dynamic Workers + @cloudflare/codemode
• runtime dependencies: @cloudflare/worker-bundler — import * from react सीधे काम करता है
• web automation: Browser Run
• full OS access: Sandboxes — git, compiler, test runner
• scheduled execution: DO Alarms + Fibers
• real-time streaming: WebSockets
• external tool connectivity: MCP
• agent-to-agent orchestration: sub-agents (Facets) — typed RPC
• model access: AI Gateway + Workers AI (या अपना model)

Think base class

• एक unified harness जो agent loop, message persistence, streaming, tool execution, stream resume, extensions आदि सहित पूरे chat lifecycle को संभालता है
• न्यूनतम subclass: सिर्फ getModel() method implement करने पर streaming, persistence, interruption/cancellation, error handling, resumable streams, built-in workspace filesystem वाला chat agent चलने लगता है
• npx wrangler deploy से deploy किया जा सकता है
• override किए जा सकने वाले हिस्से: getModel(), getSystemPrompt(), getTools(), maxSteps, configureSession()
• हर turn पर पूरा agentic loop चलता है: context assembly (base instructions + tool descriptions + skills + memory + conversation history) → streamText call → tool calls execute करना (context explosion रोकने के लिए output trimming) → result जोड़ना → model के complete होने या step limit तक दोहराना

Lifecycle hooks

• Think पूरा pipeline अपने हाथ में लिए बिना भी chat turn के हर stage पर hooks देता है:
  • beforeTurn() → streamText() → beforeToolCall() → afterToolCall() → onStepFinish() → onChatResponse()
• follow-up turns में low-cost model पर switch करना, tool restriction, client context pass करना, सभी tool calls की analysis logging, automatic follow-up turn trigger करना — यह सब onChatMessage बदले बिना संभव है

Persistent memory और लंबी conversations

• Think Session API पर बना है, इसलिए tree-structured messages और branching built-in हैं
• Context blocks के जरिए persistent memory: system prompt के structured sections जिन्हें model पढ़ सकता है और समय के साथ update कर सकता है, और जो hibernation के बीच भी बने रहते हैं
• model इसे “MEMORY (Important facts, use set_context to update) [42%, 462/1100 tokens]” जैसे रूप में देख सकता है और सक्रिय रूप से याद रख सकता है
• प्रति agent multiple conversations चल सकती हैं, और forking से original conversation खोए बिना अलग दिशा explore की जा सकती है
• context बढ़ने पर non-destructive compaction: पुराने messages delete करने के बजाय summarize किए जाते हैं, जबकि पूरी history SQLite में बनी रहती है
• FTS5-based search: session के भीतर या सभी sessions में conversation history query की जा सकती है, और agent भी search_context tool से अपना अतीत खोज सकता है

पूरी execution ladder का integration

• Think, getTools() के एक ही return के जरिए पूरी execution ladder को integrate करता है: workspace tools, execution tools, browser tools, sandbox tools, extension tools — सब एक साथ configure किए जा सकते हैं

Self-authored Extensions

• agent अपने extension programs खुद लिख सकता है: ऐसे TypeScript programs जो Dynamic Workers में चलते हैं और network access तथा workspace operations की permissions declare करते हैं
• Think का ExtensionManager extension को bundle करता है (npm dependencies सहित), Dynamic Worker में load करता है, और नए tools register करता है
• extensions DO storage में persist रहते हैं, इसलिए hibernation के दौरान भी बचे रहते हैं
• उदाहरण: user PR के बारे में पूछे और 30 सेकंड पहले तक मौजूद न रहा github_create_pr tool बन जाए
• fine-tuning या RLHF नहीं, बल्कि code के जरिए self-improvement loop — sandboxed, auditable, revocable TypeScript

Sub-agent RPC

• Think, parent से chat() over RPC द्वारा बुलाए जाने वाले sub-agent के रूप में भी काम करता है, और callback के जरिए streaming events support करता है
• हर child के पास अपनी conversation tree, memory, tools, model होते हैं; parent को अंदरूनी विवरण जानने की ज़रूरत नहीं

शुरुआत कैसे करें

• Project Think अभी experimental स्थिति में है; API surface स्थिर है, लेकिन आगे भी विकसित होती रहेगी
• Cloudflare इसे अपने internal background agent infrastructure बनाने में पहले से इस्तेमाल कर रहा है
• Think, @cloudflare/ai-chat के समान WebSocket protocol इस्तेमाल करता है, इसलिए मौजूदा UI components वैसे ही काम करते हैं
• अगर आपने AIChatAgent पर build किया है, तो client code बदलने की ज़रूरत नहीं

AI agents की तीन लहरें

• पहली लहर — chatbots: stateless, reactive, fragile, हर conversation की शुरुआत शून्य से, memory/tool/action capability नहीं, सिर्फ सवाल-जवाब के लिए उपयोगी
• दूसरी लहर — coding agents: state बनाए रखते हैं, tools इस्तेमाल करते हैं; Pi, Claude Code, OpenClaw, Codex जैसे tools codebase पढ़ सकते हैं, code लिख सकते हैं, execute कर सकते हैं, iterate कर सकते हैं; यह साबित हुआ कि सही tools के साथ LLM एक general-purpose machine है, लेकिन यह सिर्फ laptop पर एक user के लिए चलता है और durability guarantee नहीं देता
• तीसरी लहर — infrastructure as agents: durable, distributed, structurally safe, serverless, internet पर चलने वाले, failures से बचने वाले, idle पर zero cost, और security को behavior नहीं बल्कि architecture के जरिए enforce करने वाले