Thirty rows, two columns, one vendor per column: context window, price per million tokens, latency, uptime, support tier. It was a good spreadsheet and it was the wrong shape, and it took a leadership team I advise most of a morning to see why.
They were not choosing between two chatbots. They were choosing between two ways of running software they had never run before: autonomous workers that live inside their systems, act for minutes or hours at a stretch, and hold state between runs.
For two years the choice was which model API to call. As of August 2026 both labs also sell the place the agent runs: the runtime that keeps its memory, the sandbox it executes inside, the identity it acts under, the audit trail it leaves. Each has made that move differently, and the difference decides how you interact with these systems, what they cost, and where your data is allowed to sit.
One line from the companion piece on the Model Context Protocol sets this up. An agent stack has three layers: reach, run, isolate. MCP is the reach, the standard socket an agent uses to touch your tools and data. This piece is the other two. Run is the managed runtime that executes the agent loop; isolate is the sandbox that fences that execution so a mistake cannot escape. Both labs now sell run and isolate as products, and that is what the board was choosing between.
What you are actually commissioning
Start with the thing that is easy to miss. When you call a model API, your code is in charge. You send a request, you get an answer, you decide what happens next. The model is a function you call; the loop is yours.
A managed agent inverts that. You define it once, with its instructions, its tools and the sandboxed environment it works in, and it runs the loop itself: plan, call a tool, read the result, re-plan, and keep going until the task is done or it needs you. Anthropic’s hosted product is Claude Managed Agents, documented as the harness and infrastructure for running Claude as an autonomous agent, with your application sending events in and streaming results back. OpenAI’s code-first equivalent is the Agents SDK, which advertises “a built-in loop that continues until the task is complete”.
The word that matters in both is loop. You are no longer buying answers; you are commissioning a worker that runs its own loop inside your systems. Once something does that with access to real tools, three questions arrive that never came up with a chatbot: where does it run safely, how do you talk to it, and what does the meter read.
Claude Managed Agents and the OpenAI stack, side by side
Two runtimes, one shape. Anthropic leads with a hosted runtime as a product; OpenAI leads with a framework you host and a ready-made chat surface to put in front of it. Behind both front doors sits the same machinery: sandboxed execution, persistent sessions, MCP tool reach, a human-approval gate, and an audit trail. Sources: Anthropic’s Claude Managed Agents documentation and OpenAI’s Agents SDK documentation, both read on 31 August 2026.
Hold the comparison by each lab’s default answer to “how do I get an agent into production.” One caveat governs all of it. Anthropic’s runtime carries its maker’s beta label on every call, and OpenAI’s sandbox layer carries one of its own inside an otherwise generally available SDK. Everything below was read against the live documentation on 31 August 2026.
Anthropic’s default is a managed runtime you rent. Claude Managed Agents is a hosted service, in beta and requiring an explicit beta header on every call. You define an agent and a sandboxed environment, then run it in sessions that persist files, tool state and conversation across turns, on Anthropic’s infrastructure. The scaffold ships as platform features: per-user credential vaults so an agent acts under the right end user’s identity without you operating a secret store, MCP tool connections, memory stores that carry a customer’s preferences between sessions and version every write immutably, and a permission policy that can pause the agent for human approval.
If you want execution on your own infrastructure, Anthropic offers a self-hosted sandbox. Read that boundary precisely, because it is the sentence a compliance officer ends up relying on. The agent’s code, its filesystem and everything it sends out to the network stay in your environment. The orchestration does not: tool inputs and outputs still flow to Anthropic’s control plane, and the contents of any attached memory store remain stored by Anthropic. That is real control over execution. It is not a private deployment.
OpenAI’s default is code first, with a ready-made chat surface on top. The Agents SDK is a framework you host, carrying the same primitives (an agent loop, handoffs between specialist agents, guardrails, sessions, MCP tool calling, tracing) plus Sandbox agents, also in beta, which give the model “a persistent workspace where it can search large document sets, edit files, run commands, generate artifacts, and pick work back up from saved sandbox state.” You choose where that sandbox runs: on a developer’s own machine while they build, inside your own infrastructure, or with a hosted provider.
The front door is ChatKit, an embeddable chat interface that handles the chat surface itself: the message widgets, the file attachments, the tool calls as they run, and the visible chain of thought while the agent works. Nobody on your side rebuilds a chat UI. One piece of news matters more than any feature on either list. OpenAI deprecated Agent Builder, its visual drag-and-drop canvas for assembling workflows, on 3 June 2026, and it shuts down on 30 November 2026. ChatKit survives, and OpenAI’s guidance for new work is to point it at your own server-side agent instead. If anyone in your organisation has been prototyping on that canvas, the migration is a this-quarter item.
Neither approach is the better one, and the honest read is that they are converging. Both give you sandboxed execution, sessions that hold state, MCP reach, a human-in-the-loop gate and tracing for audit, and all of those appear on both labs’ own feature pages. The difference is the front door: Anthropic hands you a runtime and expects you to build the interface, OpenAI hands you a framework and an interface and expects you to bring the workflow.
| If your reality is… | The lower-friction fit tends to be… |
|---|---|
| A backend team, existing systems, agents triggered by events (alerts, tickets, emails) | Anthropic’s hosted runtime: event in, result out, no interface to design |
| A product team that wants an agent embedded in a customer-facing app, fast | OpenAI’s Agents SDK behind ChatKit: the chat surface is already built |
| Strict control over where code runs and what it can reach | A self-run sandbox on either side, with the residual data flows above read carefully |
| EU data residency as a hard requirement rather than a preference | OpenAI, which documents an EU region; Anthropic currently documents none |
A starting read, not a verdict. Both platforms move quickly and copy each other’s good ideas, and both were still moving on 31 August 2026: Anthropic’s runtime in beta, OpenAI’s sandbox layer in beta inside a generally available SDK. Treat this as where each is easiest to start today, and validate it against your own stack.
Two of those rows carry more weight than the rest. Residency is the only one that can be a hard stop rather than a preference: if your data protection officer has already fixed where the data must sit, read that row first and treat the others as tie-breakers. The evidence behind it comes later in this piece. The self-run sandbox row is the one most often misread. It moves where the code executes, not the whole data path, and that difference is what the person signing the deployment off is agreeing to.
Which leaves the question the comparison provokes and cannot answer: if this thing has no chat box, how does anyone talk to it.
The part that feels abstract: you stop calling, and start commissioning
The shift under the vendor question. The old model is a call-and-answer loop your code drives. The new model is a long-running, stateful worker you set going by schedule, by event, or by talking to it, and that pauses to ask a human before it does something consequential, then resumes. Sources: Anthropic’s Claude Managed Agents documentation and OpenAI’s Agents SDK documentation, read 31 August 2026.
Experienced engineers go quiet in the first meeting when this part arrives, and the discomfort is a signal rather than a failing. The mental model everyone brings to “using AI” is the chat box: you type, it answers, the exchange is over. A managed agent breaks every part of that picture. It is not synchronous, and runs for minutes or hours after you set it off. It is not stateless, and remembers the last session. And often there is no chat box at all.
A worker with no screen still has to be talked to, and a company usually ends up using every route open to it.
You can schedule it on a timer; recurring runs are a documented feature called scheduled deployments, not something you build. You can trigger it by an event: a pager alert opens an incident session, a support ticket a triage session, a pull request a review session. Or you can attach an interface: a chat-tool mention, an embedded widget, an API session your app streams from. The example that lands hardest is Cloudflare’s environment for Claude Managed Agents, where every agent session can be given its own email address. A colleague writes to the agent as they would to a co-worker, and it reads the mail, does the work, and replies.
Once you see those routes, the abstraction resolves into something ordinary. You are not calling a function and waiting for a return value. You are commissioning a worker: you brief it, set it going, let it work unattended, and it comes back when it hits a decision above its pay grade. That coming-back step is a real feature, not a figure of speech: Anthropic’s permission policy gives each group of tools two settings, run automatically or pause and ask. Check it rather than assume it. Tools reached over MCP default to asking; the agent’s own built-in toolset, which includes a shell, defaults to running without confirmation. The gate exists; someone has to switch it on where it matters, and deciding which actions deserve a human is most of the design work in a useful agent.
None of that is a new management idea. It is how anyone commissions work from an outside specialist: agree the scope, hand over the access, let them work unobserved, and set the standing rule about what they must not decide alone. The genuinely new part is that software has always answered and stopped. This kind goes away and works.
The fence: what a sandbox buys you
The isolation spectrum, lightest to heaviest. A container shares the host’s kernel and starts in milliseconds; a user-space kernel such as gVisor sits between the agent and the real kernel and handles its system calls; a microVM gives it a hardware-enforced boundary of its own. Heavier isolation costs more per session and buys a stronger wall. Sources: the gVisor, Firecracker and Cloudflare sandbox documentation, read 31 August 2026.
The sandbox is the least glamorous layer and the one a regulated firm should care about most. Its job is containment: the agent’s code runs inside a fenced space, so a mistake or a hijack cannot reach the host machine, other customers’ data, or the wider network.
A chatbot that only answers questions is fairly safe. An agent that can execute code is a different animal, because running arbitrary code is open-ended in a way a fixed set of tool calls is not. That is literal rather than rhetorical: the first entry in Anthropic’s built-in toolset is Bash, a shell. Give an agent a shell and, in principle, it can do anything a person at that terminal could do.
Three failure modes are worth naming, because the fence is the wall against all three. A prompt-injection escape, where a malicious instruction hidden in an email or a document tricks the agent into running attacker-controlled code. Resource abuse, where a runaway process exhausts the machine. And lateral movement, where the agent reaches a cloud secret or another tenant’s data because nothing stopped it.
Isolation comes in strengths, and the trade is the familiar one: a stronger wall costs more. A plain container shares the host’s operating-system kernel, the shared core every program on that machine runs through. It starts in milliseconds: light, cheap, and the weakest boundary, because a kernel exploit crosses it. gVisor is an application kernel running in user space, sitting between the agent and the real kernel and handling its system calls itself: heavier than a container, lighter than a virtual machine. A microVM such as AWS’s Firecracker gives each agent its own miniature virtual machine with a hardware-enforced boundary. It is not slow, and AWS is at pains to say so; it is simply heavier per session. Cloudflare runs agent sandboxes on either a microVM or a much lighter isolate: a stripped-down execution environment that starts in milliseconds and gives the agent far less of a machine than a container does. It publishes the gap, and the isolate costs a fraction of a container session.
A managed runtime does not ask you to pick a point on that line by hand, but its default is worth knowing. An Anthropic cloud session runs in a fresh Linux container of its own, at the light end, with outbound network access unrestricted until you configure an allowlist. Anthropic’s own documentation recommends that allowlist for production, which makes it a default someone has to change, and a line item for whoever signs the deployment off.
One containment idea belongs in every vendor conversation, because it is the cleanest defence against injection: credential injection at the boundary. The agent holds no keys at all, and the runtime attaches the real secret as the request leaves. Cloudflare documents exactly this, injecting credentials into outbound requests “without the agent ever seeing them”, so an attacker who talks the agent into printing all its credentials gets nothing. Anthropic’s vaults solve a neighbouring problem, keeping secrets out of the agent definition and binding a session to one end user. Both are worth having, so the useful vendor question is the concrete one: where do the credentials live, and can the agent read them.
Why this matters for the business: governance up, choices narrower
Set the benefits and the bill side by side, because a fair decision needs both. The benefits first.
On the benefit side, a managed runtime is good news for a firm answering to a regulator or a works council. Most of what governance needs arrives as a platform feature rather than a bespoke build: an identity the agent acts under, credential vaults, least-privilege tool scopes, an approval gate, and an audit trail. The memory stores are the sharpest instance: every write creates an immutable version, turning “the AI did something” into an inspectable record. Under the GDPR that record carries real weight, though how much in your case is a question for counsel, and so does the sandbox keeping one customer’s data from crossing a boundary.
Now the counterweight, which belongs here rather than in a footnote. Statefulness is what you are buying, and statefulness complicates every retention promise. Because Managed Agents stores conversation history, sandbox state and outputs server-side, Anthropic says plainly that it is not eligible for Zero Data Retention or a HIPAA business associate agreement, the US health-care privacy contract. Sessions and uploaded files can be deleted through the API, but the two strongest commitments are off the table. OpenAI offers zero data retention on approval, with the caveat in its own documentation that stateful endpoints may still store application state. The memory that makes an agent useful across sessions is the memory a retention policy has to account for, on both sides.
Data residency is where the two genuinely diverge, and for a European buyer it is the difference most likely to settle the question. OpenAI documents per-project data residency including an EU region, with a dedicated European endpoint and storage at rest in that region. It is sales-gated and needs a modified retention amendment outside the US, and its ten per cent uplift applies to models released on or after 5 March 2026 that are eligible for residency. Read that boundary as precisely as the other one: OpenAI’s own documentation carves out system data, which may sit outside the region, and reserves the right to process and temporarily store content outside it where a region does not support regional processing. Anthropic’s data-residency documentation, read on 31 August 2026, offers inference pinned to global or to the US, and the workspace setting governing data at rest has exactly one value: US. Nor is there a way round it through a cloud partner: Anthropic’s pricing page lists Managed Agents as not available on partner-operated clouds, so the familiar route of running Claude in a European region through Bedrock does not exist here.
The self-hosted sandbox above is the nearest Anthropic equivalent, and it is a real option rather than a consolation prize: execution and filesystem stay with you. It is not an EU region, though, and anyone who conflates the two will tell their data protection officer something untrue. Where residency is a hard requirement, that asymmetry is the first line on the slide.
One more European item, four weeks old. On 2 August 2026 the Commission began applying a further tranche of the EU AI Act, including transparency rules requiring interactive AI systems to tell users they are dealing with AI rather than a human. Whether that catches your deployment is a question for counsel. But the triage agent and the embedded chat widget above are the shapes those rules describe, so “does this have to announce itself” is now a design question.
That is the part I would put on the board slide first. Buying the runtime is largely buying a governance posture you would otherwise assemble yourself, and inheriting constraints you would otherwise get to choose.
The bill: a seat is flat, a meter is not
This is the trade-off the vendor deck leaves off. A subscription seat is flat, predictable and capped: Claude’s Team plan is published at $20 per seat per month billed annually, or $25 monthly, as at 31 August 2026. One person, one price, whatever they do with it, and nothing at all while they sleep. A managed runtime bills by consumption instead. Anthropic’s published pricing for Managed Agents has two dimensions, tokens and session runtime. Tokens are the billing unit these platforms meter text in; very roughly, a token is a short word or a piece of one, so a page of prose runs to several hundred. Session runtime is the second dimension, charged at $0.08 per session-hour and metered only while the session is actually running.
Anthropic works an example itself, which saves me inventing a workload. A one-hour session on Claude Opus 5 consuming 50,000 input tokens and 15,000 output tokens comes to $0.705. Set that against the $20 seat: one monthly licence buys about twenty-eight such sessions. Read it precisely: that is the vendor’s own illustration on a workload the vendor chose, not a benchmark of anybody’s real usage. Re-run it with your own figures and the shape survives. An agent working an hour a day costs roughly one person’s seat. Ten agents working continuously do not.
Metered billing is fine, often cheaper, for spiky or low-volume work where flat seats sit idle, and the opposite for continuous, autonomous or parallel work. A seat does not scale with how hard the person works. A meter does.
The labs know it, which is why cost control ships as a first-class feature. Anthropic exposes an effort setting with five levels from low to max, capping how hard an agent works a problem, and a coordinator pattern in which one agent delegates to a roster of others. The cost reasoning on the second is mine rather than the documentation’s, premise included: if each agent in a roster can be pointed at its own model, the token-heavy reading can go to cheaper models under a smarter supervisor. A third lever is not a platform feature at all: what you put in front of the agent each turn is the input side of the meter, and managing that context is a discipline of its own.
So: a subscription is the right instrument for a human at a keyboard, and metered billing for bounded, valuable, occasional autonomous work. If the plan is to point a fleet of agents at a continuous workload and leave them running, model the token bill before you commit rather than after the first invoice. That is a great deal cheaper on a spreadsheet than in production.
The one decision to make out loud
Strip the logos off and the choice in front of that board was never Anthropic versus OpenAI. It was whether to commission long-running autonomous work into their systems at all, and if so, with eyes open on three things a chatbot never forced them to think about. Where the agent runs, how strong the fence is, and where the data is allowed to sit. How people will talk to a worker that has no screen. And what the meter reads when the work runs continuously rather than in a two-second burst.
Answer those and the vendor question becomes what it should be: a fit test between each lab’s default shape and the stack you already have. Anthropic rents you the runtime and expects you to build the interface; OpenAI hands you a framework and a chat surface and expects you to bring the workflow. Both fence the execution, both still carry a beta label somewhere in the stack, both meter you by the token rather than by the seat, and only one of them currently documents a European region. Those are columns a spreadsheet can hold.
The layer underneath this one has a piece of its own: what a sandbox is for, why an enterprise reaches for one, and how to adopt one well, in the same plain terms. And if the token-versus-seat modelling is the question keeping you up, that is the kind of decision worth an outside read before you sign.
