LangGraph, CrewAI, AgentCore, Cloudflare Agents, and managed agent offerings are usually discussed as if they compete to solve one problem. They do not. Almost all of them help you build and host an agent application. Very little of the stack yet qualifies as agent infrastructure, because the industry has not agreed on what should be separated from what. This article proposes that separation.
- Agent application
- A deployable unit that bundles the reasoning loop with prompts, tool code, and business logic. You write it, ship it, and scale it as one thing.
- Agent loop
- The cycle of calling a model, reading its decision, executing what it asked for, and feeding the result back into context until the task completes.
- Execution plane
- The layer that runs the work an agent decides to do: functions, sandboxes, containers, browsers, and API calls, each short-lived and retryable.
Infrastructure history is a history of separations.
Each era of cloud infrastructure is remembered for the concern it pulled out of the application. Containers separated the process from the host it ran on. Kubernetes separated the workload from the machine, so scheduling became the platform's job. Serverless separated code from servers entirely. Durable workflow engines such as Temporal and Durable Functions separated long-lived state from the compute that advances it.
Agents arrived and the pattern paused. We got frameworks for writing them and runtimes for hosting them, but nothing has yet been separated. The agent of 2026 is architecturally the monolith of 2010: everything it needs is compiled into one deployable unit.
Everyone is still deploying agent applications.
Look at what actually ships when a team deploys an agent today. The reasoning loop, the prompts, the tool implementations, the business logic, the database client, and often a browser automation stack all travel together in one image. The platform's job is to host that unit and keep it alive.
deployable_unit =
agent loop // reasoning
+ prompts // reasoning
+ tool code // execution
+ business logic // execution
+ database client // execution
+ browser automation // execution
This model is not wrong; it is early. It is how every workload starts before its infrastructure appears. Web applications bundled their own process supervision before orchestrators existed. Batch jobs carried their own retry loops before queues owned that concern. Agents are at the same stage now.
Reasoning and execution are different kinds of workload.
The reason bundling eventually breaks is that the two halves of an agent have almost no operational properties in common. Reasoning is a long-lived, stateful conversation with a model. Execution is a short, stateless burst of work. Everything an operator cares about — scaling, scheduling, failure handling, observability — differs between them.
A checkpoint is not a retry. When a reasoning loop dies mid-session, you cannot simply run it again; you must restore its accumulated context and resume. When a tool call dies, you throw the attempt away and retry it. Infrastructure that treats those two failure modes identically has to over-engineer one path or under-protect the other.
The loop is infrastructure. The tool is workload.
One iteration of an agent makes the boundary visible. The model is called, a decision comes back, something executes, and the result re-enters context. The loop itself — model calls, context management, checkpointing — behaves the same way for every agent ever written. The tool run is the only part that is specific to your business.
Generic, repeated machinery is the definition of infrastructure. Application-specific work is the definition of workload. Today both live in the same process, which means every team re-operates the generic part, and the platform cannot see the boundary it should be scheduling across.
AWS and Cloudflare show where the industry is.
The two most complete agent platforms today are AWS Bedrock AgentCore and Cloudflare Agents. Both are serious, capable systems, and both are built on the application model. AgentCore gives the deployed agent application a managed Runtime, plus Gateway, Memory, Identity, Browser, and Code Interpreter services around it. Cloudflare hosts the agent as a class inside a Durable Object, with Workers, Sandboxes, Browser Rendering, and MCP servers reachable from it.
Neither platform is criticized by this observation. They are the strongest versions of the current model, the way early PaaS products were the strongest versions of pre-Kubernetes hosting. The interesting question is what the model after this one looks like.
The runtime still owns business execution.
Stack today's platforms vertically and there are only two layers: your application, and everything the platform gives it. The runtime that manages the reasoning loop is the same runtime that runs your database writes, your API calls, and your browser sessions. Nothing in the middle says: reasoning stops here, execution starts there.
Why does the layer that holds a multi-day model conversation also carry responsibility for a 200-millisecond CPU-bound transaction? Not because anyone chose that — the abstraction separating them simply has not existed. That absence is the missing piece of agent infrastructure.
Control, runtime, execution: three planes, one protocol.
The separation that fits the properties in the table is a three-plane model. A control plane owns sessions, routing, authentication, and policy, and holds no conversation state. An agent runtime plane owns the loop: model calls, context, checkpoints. An execution plane runs everything the loop decides to do — functions, sandboxes, containers, browsers, MCP tools, external APIs, even other agents — as stateless, retryable work.
The seam between the runtime plane and the execution plane is a protocol, not a library call. The loop emits a bounded request — what to run, with what inputs, budget, and timeout — and receives a result with usage attached. Everything below the boundary can be scheduled, retried, metered, and swapped without the loop knowing.
// the runtime plane emits work, it does not perform it
execute({
kind: 'sandbox' | 'function' | 'browser' | 'mcp' | 'agent',
input: object,
timeout: duration,
budget: limits,
}) -> { result, usage }
What the separation buys.
Independent scaling
The three planes have different load shapes. Sessions are numerous and mostly idle. Active loops are few and gated by model latency. Tool calls arrive in bursts and are bounded by CPU. One autoscaler cannot serve all three well; three planes can each scale on their own axis.
Independent scheduling
With a protocol boundary, an agent scheduler can place loops by context size and model affinity, while an execution scheduler places work by CPU and isolation needs, and GPU capacity is scheduled separately again. Bundled agents force one scheduler to solve all three placements at once.
Observability at the decision boundary
When decisions and executions cross a boundary, that boundary becomes the audit log. Every tool call has a recorded decision that caused it, and every result has the execution record behind it. Inside a monolith, that trace has to be reconstructed from application logs.
Registry independence
Where a tool comes from — an MCP server, a tool registry, an internal HTTP service, a gateway — stops mattering to the loop. Tool source becomes a detail of the execution plane behind one interface, which is exactly where the Cloudflare three-dimension framing suggests it belongs.
Build the agent. Orca runs everything around it.
Orca turns the separation in this article into a practical division of responsibility. You build the behavior that makes your agent valuable: its instructions, reasoning, and decisions. Orca handles the infrastructure required to run it in production.
That means long-running sessions can stay durable while bursts of tool work scale independently. A failed tool call can be retried without replaying the agent's reasoning. Execution stays isolated, policy and spend limits are enforced, and every decision can be followed through to its result and cost.
Teams get one platform for the systems that otherwise become separate engineering projects: run lifecycle, persistent sessions, isolated workspaces, tool access, usage metering, spend controls, and observability.
Clear boundaries between the three planes create an open-ended customization surface. Reasoning can change without rebuilding execution. Tools and execution environments can change without disturbing active sessions. Business logic remains separate from both, so teams can modify and deploy it on its own cadence.
That independence shortens every feedback loop. Agents reach production sooner because teams do not have to build the surrounding platform first. Later changes require less engineering effort and less rework because each concern can be tested and improved in isolation. Steering also becomes easier over time: instructions, policies, tools, and business rules can be adjusted where they belong without destabilizing the rest of the system. More of each iteration goes toward better agent outcomes instead of infrastructure maintenance.
The value is not simply another place to host an agent. It is less infrastructure for your team to build and operate, fewer concerns bundled into every deployment, and more freedom to improve the agent without reworking everything around it. Your team ships the agent experience; Orca carries the operational burden behind it.
Kubernetes separated workloads from machines. Serverless separated code from servers. Workflow engines separated state from compute. If the pattern of the last fifteen years holds, agents will get their separation too, and it will fall on the line this article has drawn: reasoning on one side, execution on the other.