Full article text retrieved via xmcp plain_text (per [[feedback_xmcp_article_body_via_plain_text]]),
not skimmed from the preview. Codebase is open source at github.com/qaml-ai/camelAI, so the
claims are checkable against code rather than taken on the author's word — unusual for a
company architecture post and worth weighting up.
What they did
Three redesigns, stated in order:
- VM era. Launched on the Claude Code harness, which requires a full VM. Tried several providers, built their own container service. Worked, but an always-on VM plus fast attached disk per user was too expensive to scale.
- Agent out of the VM. Built their own harness on
pi(Mario Zechner's open-source coding agent), importing only its lower layers — the agent loop and state management, which don't assume an OS. Ran that inside a Cloudflare Durable Object, calling into VMs remotely. Explicitly the "brain separated from the hands" split. Fixed latency, not cost. - VM removed. Filesystem now lives in the Durable Object's SQLite (10 GB cap), with files over ~1.5 MB spilled to R2 and the row holding a pointer. Built on Cloudflare's experimental Shell. Git history via Cloudflare Artifacts, so no git server.
- bash removed. Agent writes JavaScript executed through Code Mode on dynamic
Worker loaders — a fresh V8 isolate per execution, booting in milliseconds.
Credentials never enter the sandbox: the agent calls a connection's methods and
authentication happens on their side. Containers retained for exactly two jobs that
genuinely need Linux (app builds via
bun install, Python notebooks), spun up and torn down per job through the Cloudflare Sandbox SDK.
Their reported result: cheaper by orders of magnitude (dynamic Workers bill per execution, not per second of uptime), lower latency, no external container service to operate.
Synthesis for RDCO
1. It is the same conclusion as our 2026-07-28 sandbox work, reached from the opposite
direction. That day's finding
([[2026-07-28-external-model-delegation-codex-grok]]) was that a general-purpose coding
agent cannot be read-confined by its own flags — codex exec -s read-only and
grok --cwd both read ~/CLAUDE.md from outside their working directory, and only a
kernel sandbox-exec profile held. camelAI's answer is to stop trying to confine a
general capability and instead not grant it: no bash, only explicit methods. Where
we hardened the cage, they shrank the animal. Both are valid; theirs removes a whole class
of problem rather than containing it.
2. The most actionable line for the bandwidth goal. Quoting directly: cheap models "struggle in open-ended environments" and with "a smaller set of explicit methods they perform noticeably better." That is a lever on the same problem the multi-provider delegation work is trying to solve — constraining the tool surface makes cheaper models viable, which buys capacity without adding a vendor.
3. Direct CAF engine relevance. The CAF target architecture ([[2026-07-27-caf-technical-architecture-and-backlog]]) specifies "CAF engine on remote sandboxed agent harness." This is a production, open-source instance of precisely that shape, with tradeoffs named. It is also a candidate answer to the logged pain point that "certain portions cannot be run in headless mode; they must be run interactively to pass the enterprise approval guardrails" — explicit, enumerated methods are auditable in a way an open bash prompt is not, which is usually what such guardrails are actually asking for.
4. Buildable here, not theoretical. RDCO already runs on Cloudflare — Workers, R2, Access, and the quick-sites Worker. The stack described is reachable with existing infrastructure and existing skills ([[cloudflare]], [[publish-site]]).
Where to discount it
- Company showcasing its own migration. No sponsor to disclose, but the incentive is to present the destination as vindicated. The admission of "three redesigns" is a point in its favour; the absence of any quantified before/after cost figure is a point against. "Orders of magnitude" is asserted, not evidenced.
- The admitted downside is the one that would bite CAF hardest. They state it plainly: "we have to anticipate what the agent needs... if a capability is missing, we have to add it." An explicit-methods harness is excellent where the task space is known and stable. CAF's task space shifts per client engagement, which is the adversarial case for this design. They argue the constraint improved their product; that argument is weaker for bespoke client work than for a single SaaS surface.
- n=1, and their workload is not ours. User app-building with a fixed toolchain (Vite/Tailwind/React Router) is far more enumerable than open-ended research or document-generation work.
- Durable Object SQLite's 10 GB cap and the Worker 128 MB memory limit are real ceilings they had to design containers around — inherited constraints, not solved ones.
Related
[[2026-07-28-external-model-delegation-codex-grok]] · [[2026-07-27-caf-technical-architecture-and-backlog]] · [[2026-07-28-amazon-engineer-agentic-signal-loop-not-reading-the-diff]]