Cloudflare Agents turns an agent session into a durable runtime: each agent instance has stable identity, local SQLite, WebSockets, scheduled work, recoverable execution, and tools. It is not just a chat example; it composes Workers, Durable Objects, AI models, Browser, Sandbox, AI Search, and MCP into a deployable agent app.
An AI app should not put conversations, artifacts, memory, retrieval documents, locks, and eval traces into one store. D1 fits queryable product data, R2 fits large files and artifacts, Durable Objects fit named coordination and per-session state, and Agent Memory / AI Search / Vectorize handle memory and retrieval.
Rivumi's old synchronous M6 path completed one real deployed coding run. It has since grown into an asynchronous control plane with RunSession, SSE, approvals, cancellation, and artifacts, but that newer path has not been live-revalidated. Audience-separated HMAC capabilities enter the Sandbox while provider credentials stay in the Worker; this is not production-traffic or SLO proof.
Cloudflare Containers let a Workers app call on-demand serverless containers for workloads that need a full filesystem, a specific runtime, existing container images, or more CPU, memory, and disk. They do not replace Workers; Workers still handle entry, routing, and platform bindings while containers run the heavy runtime-specific work.
A local sandbox limits the blast radius of an agent on your machine; a cloud sandbox is about moving code safely onto someone else's machine. All five mature projects solve the first problem; only rivumi actually deployed the second. Lessons from production: mocks can't catch SSE framing, green CI can't catch a stale wheel, and cleanup paths deserve timeouts just as much as success paths.
Agent Platform uses a Cloudflare-first architecture: local `npm run dev` runs Node-based simulations, while production maps to Workers + Workers Assets + D1 + KV + R2 + Vectorize + Queues + Workflows + Durable Objects + Workers AI. The Runtime interfaces stay the same (InMemory → Cloudflare implementations), so upper layers migrate without noticing. Deployment requires only `wrangler login` → create resources → fill in IDs → `wrangler secret put` → `wrangler deploy`. CI/CD watches the main branch and runs typecheck + build + dry-run + migration + deploy.
Cloudflare Sandboxes uses a Worker as the entry point, a named Durable Object as the control plane, and a Container inside an isolated VM as the execution plane. It fits Cloudflare-native fleets of ephemeral Linux workspaces, but persistence, security boundaries, and three layers of billing remain your responsibility.
Durable Objects map a name or ID to a globally unique, single-threaded actor with private SQLite storage. They fit per-room, per-user, per-tenant, and per-run coordination boundaries; the real design question is where the object key belongs.