Two Classes of Agents: Codebase-Native vs Workers-Native

Agent frameworks split cleanly into two classes, and the split is about tool access, not cost. Miss this and you’ll keep rediscovering why MoltBot needs a container, why Cloudflare built a separate Agents SDK, and why your orchestrator’s compute bill can be zero while your executor’s can’t.

This article names the divide, explains why it exists, and gives a concrete rule for picking the right class for each agent in your system.

What you’ll learn:

Why OpenClaw / Claude Code / MoltWorker cannot run on bare Cloudflare Workers
Why Cloudflare built a Workers-native Agents SDK anyway
The precise tool-access line that separates the two classes
Why orchestrator agents belong on Workers and executor agents belong in containers
How to decide where Jane, Prime, Mulan, and future agents sit
Why “just run it on Workers to save money” is the wrong question

The Thesis

Agents split into two classes by the tools they need. Codebase-native agents (shell, filesystem, subprocess) require a container. Workers-native agents (fetch, HTTP, remote APIs) run on Cloudflare Workers at zero idle cost. The tradeoff is tools, not cost.

This is downstream of goal-generation-is-agency: once you accept that executors are commodity and goal-generation is the moat, the next question is which executor class fits each job. That’s this article.

The Two Classes

Codebase-Native Agents

Tools the agent uses assume a real POSIX environment:

Shell execution — Bash, Zsh, sh -c
Real filesystem — Read, Edit, Write, Glob, Grep over a mounted tree
Subprocess spawn — git, rg, jq, npm, python, make, language runtimes
Long-running tasks — minutes to hours of wall-clock per session

Deployment options:

Your laptop (Claude Code, local OpenClaw)
A VM or container on any platform (MoltWorker = OpenClaw in a Cloudflare Sandbox DO container)

Cost shape: pays for compute while running. CF Sandbox standard-1 instance is ~$5-34/mo per agent depending on sleep policy. Your laptop is “free” only because you already paid for the hardware.

Examples: OpenClaw, Claude Code, NanoClaw, MoltWorker, Agent Zero.

Workers-Native Agents

Tools the agent uses are fetch-based:

Remote API calls — fetch() against GitHub, LLM providers, MCP servers
Object storage — R2, D1, KV, Durable Object SQLite
Scheduled wakes — DO alarms, Worker cron
Short bursts — 30s (free) to 5min (paid) CPU per request

Deployment options:

Cloudflare Workers + Durable Objects
Other edge runtimes (Vercel, Deno Deploy) with similar constraints

Cost shape: zero idle. Pays per request. At our scale (one Jane, hourly wakes), sub-dollar per month.

Examples: Cloudflare Agents SDK-based agents, our packages/coordinator (S2 goal-gen), most SaaS agents.

Why the Container Is Forced

MoltWorker isn’t a container because Cloudflare made a style choice. It’s a container because OpenClaw’s tool library is structurally incompatible with the Workers runtime:

OpenClaw tool	What it needs	Workers provide?
`Bash`	exec a shell process	❌ no exec
`Edit` on local files	open file, seek, write bytes	❌ no filesystem
`Glob`, `Grep`	walk a directory tree	❌ object store only
`git status`	subprocess	❌ no spawn
Long agent loops	minutes of wall clock	❌ CPU cap

You can’t port OpenClaw to Workers by swapping a few imports. The tools are the agent’s capability surface; remove them and you don’t have OpenClaw anymore. So Cloudflare wrapped OpenClaw unchanged in a Sandbox Durable Object — a real container with a real filesystem backed by R2 squashfs — and added cron supervision on top. That’s MoltWorker.

The container is the cost of running OpenClaw unmodified. It’s not optional if you want OpenClaw’s tools.

Why Workers-Native Is Possible

Agents that don’t need shell or a local filesystem can be built cleanly on Workers. The Cloudflare Agents SDK provides:

Durable Object per agent instance — persistent identity + SQLite storage
setState / subscription — state sync across surfaces
Alarms + cron — scheduled wakes
Hibernation — DO sleeps between events, no idle cost
WebSocket — live push for interactive clients

Replace “edit a file locally” with “commit via GitHub API.” Replace “grep the codebase” with “fetch the wiki page and regex in memory.” Replace “git log” with “GitHub REST API.” For orchestration, proposals, and API routing — most of what Jane actually does — the Workers-native toolset is enough.

Our own S2 goal-gen coordinator is Workers-native. It fetches wiki files from GitHub, calls Haiku via API Mom, diffs goals, and commits results back via the Git Data API. 6K LOC, zero idle cost, scales to zero between alarms. It works because it never needed shell access.

The Orchestrator vs Executor Split

This is the practical frame for picking a class:

Orchestrators decide what should be done. They read state, propose goals, route work, gate decisions, hold context. They don’t edit code. Workers-native fits.
Executors do the actual work. They edit files, run tests, spawn subprocesses, operate in repos. Codebase-native fits.

RFC-ORG-023 (Jane Server) is already designed this way — implicitly:

Jane = orchestrator, persistent identity, Workers-native (DO + alarms + GitHub API). Lives on Cloudflare.
jane-workers on local machines = executors. They run Claude Code / Claude Agent SDK sessions with full shell access to real repos. Codebase-native.
Dispatches flow orchestrator → executor. Results flow back through GitHub (commits, issues, PRs) — the shared substrate.

The split isn’t “Jane vs the workers.” It’s one agent identity expressed through both classes: Workers-native for the thinking, codebase-native for the doing. Neither class is better; they’re for different jobs.

Cost Is Downstream

If you ask “which class saves money?” you’re asking the wrong question. Cost follows from the deployment model, which follows from the tool requirements.

Need shell? → container → ~$5-34/mo minimum → pick a codebase-native framework
Don’t need shell? → Workers → ~$0 idle → pick a Workers-native framework

Trying to force a codebase-native agent onto Workers to save money doesn’t work — you lose the tools and you lose the agent. Trying to run a Workers-native agent in a container to gain tools is fine but wastes the idle-cost advantage.

Match the class to the job, then the cost works out.

Rule of Thumb

When designing a new agent:

List its tools. Not the conceptual capabilities — the concrete operations it needs to perform.
Any tool needs shell, subprocess, or a real filesystem? Codebase-native. Container or laptop.
All tools are fetch/HTTP/storage? Workers-native. CF Agents SDK or similar.
Hybrid? Split the agent into an orchestrator (Workers-native) + executor workers (codebase-native). Keep the state/identity on the orchestrator, delegate the hands-on work to the executors.

Jane is this split. Prime (org-prime-agent-architecture) is this split. Future agents will be too.

Adoption principle: start hosted, build scaffolding only when forced

Picking a class is not the same as picking a framework. Once the class is settled, a separate decision remains: do we use what’s already hosted (Anthropic Routines, Claude Code, MoltBot, Agent Zero) or do we build scaffolding?

Start with the hosted minimum. Add scaffolding only when a concrete limit forces it.

This is feedback_no_speculative_infra applied to agent architecture. The failure mode is building your own framework before finding out whether the hosted one suffices. Symptoms: thousands of lines of DO/REST/MCP wrapper around a pipeline that Anthropic’s Routines + CLAUDE.md could run natively.

The staircase:

A — Hosted minimum. Claude Code Routine (for codebase-native orchestration + execution), CF Agents SDK DO (for Workers-native scheduled orchestration), MoltWorker (for codebase-native autonomous loops). Configure via CLAUDE.md, skills, settings. No custom runtime.
B — Thin scaffolding. Only when A exposes a specific limit (quota, context density, feedback-loop friction, multi-agent coordination). Add the smallest possible module to address exactly that limit. Not a framework rebuild.
C — Full custom. Only when B can’t be stacked further. Rare. Needs a documented failure of A + B.

Most agents should live at A forever. A few outgrow it into B. Very few justify C.

When evaluating a proposed custom agent framework, ask: “What specifically about the hosted option (Routines / Agents SDK / MoltBot) makes it insufficient?” If the answer is hypothetical, start with hosted. If the answer is a concrete incident or measurement, build only the scaffolding that addresses it.

Our S2 coordinator is an example of jumping to B before validating A. Useful code, but built on a premise we didn’t test first. Correct path forward is: try A (Claude Code Routine against our wiki) before extending S2.

References

goal-generation-is-agency — the frame that makes executors commodity
three-layer-ai-agent-architecture — Container / Brain / Wallet; uses CF Agents SDK as the Workers-native runtime
org-prime-agent-architecture — orchestrator/executor split applied to per-repo agents
autonomous-agents-context-continuity — per-framework survey: OpenClaw, MoltWorker, Claude Agent SDK, CF Agents SDK, Hermes, NanoBot, Agent Zero, LangGraph
RFC-ORG-023 — Jane as Workers-native orchestrator with local codebase-native workers
cloudflare-durable-objects-patterns — DO primitives Workers-native agents build on