How to build an enterprise-ready agent on Cloudflare

Most agent projects don't fail on model capability. They fail in review. Reviewers asks where the credentials live, who approved that action, what version of the prompt was running last Tuesday, and the answers are "in an env var", "the model decided", and "whatever was in main". That's the gap between a demo and an enterprise agent.

Closing that gap on Cloudflare means accepting one idea up front: you are building on two planes, not one. Cloudflare owns the runtime plane. A capability plane - in our stack, Oi - owns everything the runtime shouldn't. We've created a case study below for one of our production agents for context.

Why do most agent projects fail enterprise review?

Because review asks questions no runtime can answer: who holds the credentials, who approved the action, what judgment was live when it ran. Everyone is using AI; almost nobody can show it moving the business. MIT's State of AI in Business 2025 found only 5% of enterprise GenAI pilots deliver measurable P&L impact. Agents are how usage becomes workflow change, but v ery few make it to production.

Three pressures make this sharper right now: cost pressure from rising frontier-lab token prices, risk pressure from rogue model behaviour and supply-chain incidents, and choice pressure from credible foreign and open-weight models appearing weekly. Under those pressures, an agent that passes review needs three things no runtime provides on its own: a shared standard the whole team starts from, governance attached to the work and versioned, and portability across clients so the choice stays open. The two planes below are those three requirements, applied to agents.

What does Cloudflare's runtime plane give an agent?

Execution, durability, model access, and isolation — and nothing on this plane knows what your agent is for, which is by design.

What the runtime buys you: runs that survive restarts and deploys, pauses for human approval without burning compute, and one log and one bill for every model call.

What is a capability plane, and what does it add?

A capability plane holds what the agent is allowed to be: its knowledge, tools, rules, and oversight. All of which must be versioned, governed, and portable, outside the agent's code. These should be runtime and model agnostic by design.

What the plane buys you: agent code with no credentials in it, behaviour versioned and revertible without a deploy, and an audit trail for every judgment and tool call.

How do the runtime and capability planes work together?

Across a deliberately small seam: the agent shell fetches knowledge from one plane and calls tools through the other, and everything else stays on its own side. When it needs judgment, it fetches a Context from Oi and calls the model with it. When it needs to act, it calls the tool through an Oi Connection, which checks policy, injects the credential, makes the call, and logs it. Fetch knowledge, call tools.

Approvals show how the planes cover each other. The runtime makes a human approval mechanical: a Workflow pauses and can hold that pause for days. The capability plane makes it meaningful: the rule that a named human must give explicit written approval lives where the model can't reason around it. One plane makes the pause survivable. The other makes it mandatory.

What does a two-plane agent look like in production?

Take the example of Penelope, an agent our fitness industry partners use to handle class coverage for gyms entirely over email. An instructor emails that they can't teach Tuesday. Penelope works out which class it is, broadcasts to qualified staff, collects volunteers, asks the general manager for approval, and only after an explicit written yes does she change the schedule in Mindbody, the gym's booking system.

On the runtime plane: a thin shell receives Gmail's push notifications, crons run a safety-net poll and drive timers, and one durable workflow per request carries the process. Postgres holds the system of record, including an append-only audit log and idempotency ledgers so a retried step never sends a duplicate email or double-books a substitute.

On the capability plane: four version-pinned Contexts define her judgment, one per stage. Her two primary capabilities, sending mail and touching Mindbody, are Oi Connections. The Mindbody connection is a small wrapper service that is the only thing anywhere holding Mindbody credentials, and it enforces the rules server-side: the one mutating operation requires an approval reference, refuses changes inside a seven-day notice window, and in test mode refuses to mutate at all.

The result is agent code with no credentials, no prompts, and no policy. What's left is control flow and record-keeping, which is what you want left. And behaviour changes stopped being deploys: tightening how Penelope reads an ambiguous request is a Context version bump in Oi, testable against fixtures and revertible by re-pinning.

Can you build an enterprise-ready agent on Cloudflare alone?

You can build an agent, but not one that passes review, because everything above the infrastructure lands in code. Prompts become string literals, so every behaviour change is a deploy and there's no answer to "what judgment was live on Tuesday?". The Mindbody key sits in a Worker secret, readable by the same code the model steers, so "could the agent leak a credential?" has only a hopeful answer. The approval rule is a convention the next refactor can quietly weaken. And the second agent you build gets none of Penelope's knowledge, because it's welded into her repo.

The reverse fails too. With Oi alone, you have knowledge, tools, and rules, and nowhere to stand. No durable execution for a request that spans days, no scheduler, no sandbox, no state. The capability plane governs an agent; it doesn't run one.

This is the same division of labour enterprises already trust: infrastructure providers run things, and the things worth protecting — identity, policy, knowledge — live above the infrastructure. Agents raise the stakes, because an agent is the first workload that can be talked into misusing whatever it holds. The answer is to make sure it holds nothing.

What does "enterprise-ready" actually require?

Strip the vendor names away and the checklist is short:

1. Credentials the agent cannot leak, because it never has them
2. Approvals that are enforced, named, and logged
3. Behaviour that is versioned, testable, and revertible separately from code
4. An audit trail that explains every action
5. Execution that survives restarts and waits for humans without burning compute
6. Isolation for anything the agent wrote itself
7. Two undo buttons: one for the code, one for the judgment

Cloudflare gives you the second half of that list. Oi gives you the first. Penelope is what it looks like with both, and neither half was optional. The runtime made her reliable. The capability plane made her allowed.

What are the steps from prototype to production?

Seven steps, and three always-on layers under every one of them.

Frequently asked questions

Does Oi replace the Cloudflare Agents SDK?

No. The Agents SDK runs the agent: its state, connections, and tool calls. Oi governs what the agent knows and is allowed to do. Penelope uses both at once.

What is the difference between Cloudflare Workflows and Oi Workflows?

Cloudflare Workflows is durable execution: checkpointed steps that survive restarts and can pause for days. Oi Workflows are plain-language process definitions that the process owner can change without a deploy. One runs the steps; the other decides what the steps are.

How does the agent call tools without holding credentials?

Every external tool is exposed through an Oi Connection, a proxy that holds the credential, checks policy, makes the call, and logs it. The agent code never sees a key, so it cannot leak one.

Can I start with Cloudflare alone and add the capability plane later?

Yes, and most teams do. The cost of waiting is that prompts, credentials, and policy accumulate in code, and each one becomes a migration later. Starting with even one Context and one Connection keeps the seam clean from day one.