Every team that builds its first production agent ends up building the same four things before it ships a single feature: a container that can safely run untrusted code, a log that survives a crash, a place to keep OAuth tokens away from the model, and a retry policy for the network blip that always arrives at 2 a.m. None of that is the agent. It is the plumbing the agent sits on top of, and for two years the only way to get that plumbing was to build it yourself.
That changed in 2026. Anthropic and Google both shipped hosted runtimes that own the plumbing and hand a developer back a session ID instead of a stack trace. This article covers what that trade actually buys, what it still leaves on the table, and the one risk it introduces that does not show up on either vendor’s pricing page.
Figure 1 - The Managed Agent Anatomy: A managed runtime splits an agent into three independently replaceable parts: a stateless brain (the model and its decision loop), an ephemeral sandbox of hands (the tools and code-execution environment), and a durable session log that lives outside both and outside the model’s context window.
The Weeks You Don’t Get Back
Building a DIY agent harness means standing up container provisioning per session (file system, package manager, network policy, clean teardown), an append-only event log that survives a container restart, OAuth token storage and refresh that keeps credentials out of the sandbox a prompt injection could read, and failure recovery logic for network blips, out-of-memory errors, and rate-limit hits. None of that is the interesting part of building an agent. It is the part every team rebuilds anyway, because for two years there was no alternative.
Anthropic’s own Applied AI team describes the shift in three stages. The Messages API launched in 2023, and a developer building on it had to write the entire agent loop by hand. An intermediate Agent SDK then handed over loop and tool-call primitives. In 2026, Claude Managed Agents arrived: “the first harness to be able to handle scaling and production ready components for you by Anthropic, providing things like a purpose-built harness, sandboxing, observability, tool runtime, all within a managed infrastructure system” [1]. Isabella He, of Anthropic’s Applied AI team, told the Code with Claude 2026 London audience that teams using the managed runtime build “10 to 15 times faster to production” than teams building the harness themselves [1]. That is a company claim from the team that ships the product daily, not an independently audited benchmark, and it should be read that way. It is still a useful directional signal: the plumbing a DIY team spends weeks on is exactly what the managed runtime absorbs on day one.
Brain, Hands, Session: The Anatomy of a Managed Runtime
Anthropic’s engineering blog names the architecture directly: a brain (the model and its decision loop, stateless, rebootable without losing anything), hands (the sandbox and its tools, ephemeral and disposable), and a session (a durable, append-only event log that lives outside the model’s context window and survives container restarts) [2]. The critical design property is where the session log sits. It is not inside the harness, and it is not inside the model’s context window. It is a separate, durable artifact that both the brain and the hands can be swapped out from underneath.
Anthropic’s blog post describes the internal recovery interface Anthropic itself built to make that swap work: “When one [harness] fails, a new one can be rebooted with wake(sessionId), use getSession(id) to get back the event log, and resume from the last event. During the agent loop, the harness writes to the session with emitEvent(id, event) in order to keep a durable record of events” [2]. Those three names, wake(), getSession(), and emitEvent(), describe Anthropic’s own internal implementation of the recovery interface, not a documented public API surface a developer calls directly. The public REST surface a developer actually integrates against is four endpoints: POST /v1/agents, POST /v1/environments, POST /v1/sessions, and POST /v1/sessions/{id}/events [3].
POST /v1/agentsPOST /v1/environmentsPOST /v1/sessionsPOST /v1/sessions/{id}/events
Headers: Authorization: Bearer <api_key> anthropic-beta: managed-agents-2026-04-01 Content-Type: application/jsonAnthropic frames the migration that produced this design using the classic pets-versus-cattle infrastructure analogy [2]. The first implementation kept the session, harness, and sandbox in a single container, a pet: a named individual the team could not afford to lose. If that container failed, the session died with it. Decoupling turned every piece into cattle, interchangeable and disposable. The harness now calls the container the way it calls any other tool, and if the container dies mid-task, Claude requests a fresh one and resumes from the last recorded event rather than starting over.
Figure 2 - From Pet to Cattle: The coupled design puts the session, harness, and sandbox in one container: lose the container, lose the session. The decoupled design moves the session log outside both the harness and the sandbox, so either can crash and restart independently without losing state.
The same decoupling shows up outside Anthropic. Cursor’s cloud agent infrastructure, disclosed in “What we’ve learned building cloud agents,” independently arrived at the same three-layer split: an agent loop running in Temporal workflows, machine state living in an independently managed container, and an append-only conversation-state layer that survives container restarts and streams to clients [15]. Two teams converging on the identical architecture from different starting points is a stronger signal than either team’s marketing copy that this decoupling is the natural shape for durable agentic work, not an Anthropic-specific design choice.
KEY INSIGHT: If a harness holds its plan in the model’s context window or inside the container it runs in, one crash erases the plan. The fix is not a better retry loop. It is moving the plan outside both the brain and the hands, into a log neither of them owns.
The Public Surface: Four Resources, One Caveat
Anthropic’s Managed Agents platform is built around four core resources: an Agent (the model, system prompt, tools, MCP servers, and skills, versioned and reusable), an Environment (an Anthropic-managed cloud sandbox or a self-hosted sandbox on the customer’s own infrastructure), a Session (a running agent instance within an environment, performing a task and generating outputs), and Events (the typed messages exchanged between an application and the agent: user turns, tool results, status updates) [4].
The caveat that matters most for anyone thinking about regulated data: Claude Managed Agents is documented as being in beta, with all endpoints requiring the managed-agents-2026-04-01 beta header, and Anthropic states plainly that “behaviors may be refined between releases to improve outputs” [4]. Managed Agents sessions are stateful by design (conversation history, sandbox state, and outputs stored server-side), so the product is explicitly not currently eligible for Zero Data Retention or HIPAA BAA coverage [4]. Two further primitives, MCP tunnels and Dreaming, are gated even deeper into a limited research preview that requires requesting access separately [4].
Figure 3 - Agent, Environment, Session, Events: The public Managed Agents surface is four typed resources, each with its own endpoint. Agent defines the model, tools, and skills. Environment is the sandbox. Session is the running instance. Events is the typed message stream between the application and the agent.
KEY INSIGHT: A managed runtime buys speed to production, not compliance for regulated data. Beta status and the ZDR/HIPAA BAA exclusion are not fine print. If a workload touches PHI or requires zero data retention, that decision has to be made before the architecture is chosen, not discovered after the pilot ships.
Anthropic’s Bet: Depth and Control
Anthropic’s philosophy treats the agent runtime as an operating system: virtualize every component, expose a stable interface for each, and absorb the entire operations layer. Beyond the four core resources, Anthropic ships four additional primitives.
Memory stores are workspace-scoped collections of text documents, mounted as a directory inside the session sandbox and read or written with ordinary file tools. Every write creates an immutable, auditable version, retained 30 days with redaction support. Limits: 100 kB per memory, 2,000 memories per store, 8 stores attachable per session, defaulting to read_write [5]. Anthropic’s own documentation flags the obvious risk directly: a prompt-injected agent processing untrusted input can write malicious content into a read-write store that a later session then trusts as memory, so shared reference material should mount read_only [5].
Outcomes let a session define what the end result should look like and how to measure its quality. Defining an outcome auto-provisions a grader that runs in a separate context window, so it is not influenced by the same reasoning that produced the answer, and the grader returns an explanation of which rubric criteria passed or failed [6]. This is a structural version of the same self-preferential-bias problem that shows up when a single context window both writes and reviews its own work.
Dreaming is a research-preview primitive, requiring a second beta header on top of the base one, that reads a memory store plus between 1 and 100 past session transcripts and produces a new, separate memory store with duplicates merged and stale entries replaced. The input store is never modified [7]. Vaults are authentication primitives that let a team register third-party credentials once and reference them by ID at session creation, so the credential never has to be transmitted on every call or stored inside application code [8].
Anthropic’s pricing bills two dimensions: tokens at standard model rates, and session runtime at $0.08 per session-hour, metered to the millisecond and accruing only while the session status is running [9]. Idle time waiting on the next message, rescheduling, or a terminated session does not count. Anthropic’s own worked example: a one-hour Opus 4.8 session with 50,000 input and 15,000 output tokens totals $0.705 (tokens $0.625 plus runtime $0.08). With 40,000 of those input tokens served from cache, the same session totals $0.525 [9].
One practical distinction worth keeping straight before signing off on an architecture: a Claude Code Routine is a different product from the API-billed Managed Agents platform this section describes. The two are scoped and billed differently, so confirm which one a workload actually runs on against current product documentation before modeling its cost. Confusing one for the other is a common source of surprise invoices.
Figure 4 - Anthropic’s Four Extra Primitives: Memory stores persist versioned, auditable documents inside the sandbox. Outcomes hand grading to a separate context window. Vaults keep OAuth credentials outside the sandbox entirely. Dreaming, gated to research preview, consolidates past sessions into cleaner memory offline.
Google’s Bet: Simplicity
Google’s Interactions API, confirmed generally available as of mid-2026, takes the opposite position: “The Interactions API is now generally available. We recommend using this API for access to all the latest features and models” [10]. Where Anthropic exposes four resources and a growing set of primitives, Google exposes one call.
interactions.create accepts a documented set of 20 parameters, including api_version, model, agent, input, system_instruction, tools, response_format, stream, store, background, generation_config, agent_config, environment, labels, previous_interaction_id, response_modalities, safety_settings, service_tier, webhook_config, and user_metadata [11]. A caller passing background: true and a previous interaction’s ID gets a stateful agent turn without ever managing a container, a session log, or a sandbox lifecycle directly.
POST /v1beta/interactions
{ "api_version": "v1beta", "model": "gemini-3-flash", "input": [{ "role": "user", "content": "Summarize the open PRs" }], "agent": "sales-triage-agent", "environment": "prod-sandbox-01", "tools": [{ "type": "code_execution" }, { "type": "web_search" }], "background": true, "previous_interaction_id": "int_8271a"}A Google for Developers walkthrough demonstrates the state-chaining behavior directly: branching from the same prior interaction twice, asking for two different edits from the same base state, produces visibly different output from both branches even though both reused the same cached prior context [12]. That is a useful reminder that reusing cached tokens on a fresh branch buys cost and latency, not determinism. The same walkthrough confirms background-executed agents, deep research run as a background task, bundled media generation (image, music, and speech generation reachable through the same interface rather than as separate product surfaces), and an agent-first skill installation flow that lets a coding agent pull in the Interactions API skill directly [12].
Figure 5 - One Call, State-Chained: Google’s Interactions API collapses agent creation, environment, tools, and execution mode into one interactions.create call. Passing previous_interaction_id chains a new turn onto a prior one without a caller managing session storage directly.
Depth vs Simplicity: Two Bets on Where the Complexity Lives
Neither philosophy is wrong. They are optimizing for different buyers. Anthropic’s four resources plus Memory, Outcomes, Vaults, and Dreaming give a team fine-grained control: separate grading contexts, auditable memory versions, credential vaults with explicit scoping. That control has a learning curve and a beta-status caveat attached to it. Google’s single call trades that granularity for a lower integration cost: one endpoint, one parameter object, state chaining through an ID string.
The practical decision rule follows from what a team already owns. A team that needs auditable memory, a separate rubric-grading context, or credential vaulting outside the sandbox is buying into complexity it would otherwise have to build itself, and Anthropic’s surface is designed to absorb exactly that. A team whose agent workload amounts to calling a model, getting tool-augmented output back, and chaining a few turns together gets there faster on a single Google call than on four Anthropic resources it does not need yet.
Figure 6 - Two Philosophies, Same Category: Anthropic exposes four typed resources plus four extra primitives for teams that want granular control over memory, grading, and credentials. Google collapses the same category into one call for teams that want to skip the resource model entirely.
The Competitive Landscape: One Real, One Retreating
A common line in the discourse around managed agents treats AWS and OpenAI as equally caught up, right there with their own versions of the category. Half of that is accurate and worth taking seriously. The other half is stale.
Amazon Bedrock AgentCore reached general availability on October 13, 2025, and AWS describes it as “an agentic platform to build, deploy and operate highly capable agents securely at scale using any framework, model, or protocol” [13]. AgentCore’s own release notes show continued active feature shipping through mid-2026 across a twelve-component surface spanning runtime, harness, memory, gateway, identity, code interpreter, browser, observability, payments, evaluations, policy, and registry. AWS is a genuine third competitor in this category, not a roadmap slide.
OpenAI is a different story. Its nearest analog to a managed hosted runtime, Agent Builder, a visual no-code workflow canvas bundled into AgentKit, is being wound down. OpenAI’s own deprecations page confirms the shutdown was announced June 3, 2026, with the Evals platform going read-only October 31, 2026 first and the full shutdown landing November 30, 2026 [14]. OpenAI’s migration guidance for existing Agent Builder users points them back toward the code-first Agents SDK, telling developers to “re-express the workflow as code,” or toward Workspace Agents in ChatGPT [14]. That is a company retreating from its closest analog to a managed runtime, not extending toward parity with Anthropic and Google. It is itself an interesting data point about where OpenAI currently believes the value sits: closer to the code-first SDK a team owns than to a visual, hosted workflow layer.
Figure 7 - Four Vendors, Three Directions: Anthropic Managed Agents is public beta. Google’s Interactions API is generally available. AWS Bedrock AgentCore is generally available and a real competitor. OpenAI’s nearest analog, Agent Builder, is being deprecated, with OpenAI pointing developers back to its code-first Agents SDK.
KEY INSIGHT: The claim that AWS and OpenAI are right there too is only half true as of mid-2026. AWS genuinely is. OpenAI is walking back its closest analog and pointing developers to the DIY path this article opens by describing. Verify vendor status against the vendor’s own docs before it goes into a proposal. This category is moving month to month.
The Lock-In Nobody Documents: Model Drift
There is a risk that neither vendor’s pricing page mentions, and it has nothing to do with API compatibility. Frontier providers routinely update system prompts baked into a served model or harness, quantize a model for inference speed and cost, and retune behavior on safety or alignment cycles. None of these changes ships with a changelog entry granular enough for a downstream team to act on. The pattern that shows up in production has a recognizable shape. A provider ships a quantized or retuned model behind the same identifier a team already calls. Tool calls degrade and reasoning chains get shorter. The team finds out only when its own evals start drifting or users complain, and there is no clear remediation path, because the change happened inside a system the team does not control.
Anthropic’s own Applied AI team lived through a concrete instance of this from the inside. Isabella He described a behavior her team named “context anxiety” that appeared in Sonnet 4.5: “we noticed that Sonnet 4.5 emitted a particular behavior called context anxiety. This meant that with Sonnet 4.5, Claude started wrapping up tasks early even when it still had room to spare in its context window” [1]. Anthropic’s harness team had to build compensating orchestration logic to detect and correct the premature wrap-up. When Opus 4.5 shipped, the behavior disappeared on its own: “we actually saw this behavior go away, making all that work we had done inside of the harness essentially obsolete because Claude had evolved beyond that behavior” [1].
That is model drift running in the favorable direction, a model upgrade quietly invalidating a workaround rather than breaking one. The instructive part is who this happened to. Anthropic’s own team, with direct internal visibility into model changes, still had to discover “context anxiety” empirically and discover its resolution empirically. A team building on a managed runtime with no equivalent internal visibility has strictly less warning than the team that named the behavior in the first place.
Figure 8 - The Drift Nobody Announces: The same API endpoint and model identifier can serve a retuned, requantized model without a changelog entry. Tool calls degrade, reasoning chains shorten, and the first signal a team gets is its own eval scores moving, not a vendor notice.
The Countermeasure: An Eval Harness You Own
A managed runtime does not remove this risk; it changes the visibility distance to it. A DIY harness at least owns the full request path and can log every raw model response for later comparison. A fully managed runtime hides the brain, the hands, and much of the session-level behavior as platform internals, so a team sees the agent’s final outputs and tool calls, not the underlying model version or its exact configuration at request time. None of the ops burden a managed runtime removes (container provisioning, session durability, credential vaulting, failure recovery) includes drift detection, because drift detection is not infrastructure a vendor is incentivized to expose in an inspectable way.
The mitigation is independent of which hosting model a team chooses: invest in an evaluation harness that tracks the team’s own agent output quality over time, against the team’s own task distribution, and treat eval-score drift as the primary signal that something changed upstream. Do not bake assumptions about current model behavior into the critical paths of a production system. Treat the team’s own eval suite as the ground truth for whether anything actually changed, not the provider’s changelog.
Conclusion
The plumbing every agent team used to build by hand, container provisioning, a durable session log, credential isolation, failure recovery, is now a product category two vendors sell and a third genuinely competes in. Teams that spent the last two years hand-rolling that plumbing spent weeks on infrastructure that was never the product they were trying to ship. Anthropic’s four-resource depth and Google’s single-call simplicity are two honest bets on where that complexity should live, and the right choice depends on how much granular control over memory, grading, and credentials a team actually needs versus how fast it needs to get a first agent into production.
None of that changes the one thing a managed runtime cannot sell: certainty that the model underneath the session ID is the same model it was last week. Adopting a managed runtime does not remove the need for an eval harness a team controls. It makes that eval harness the only instrument left that can tell a team what changed, and when, in a system it no longer owns end to end.
The Series
This is Part 1 of the 2-part Managed Runtimes & Dynamic Workflows sub-series:
- Managed Agents: Stop Building the Agent Loop Yourself (this article). The hosted runtime category: brain/hands/session architecture, Anthropic vs Google, the competitive landscape, and the model-drift risk a managed runtime does not remove.
- Dynamic Workflows: Six Patterns for Writing Your Own Harness at Runtime. The other half of the trade: Claude Code writing a task-specific harness at runtime instead of routing everything through one fixed harness, the six named orchestration patterns, and the cost-discipline decision tree for when to use them.
References
[1] Isabella He (Anthropic Applied AI Team), “Ship your first Managed Agent,” Code with Claude 2026, London, Jun 2026. https://www.youtube.com/watch?v=19HDQ9HppOA
[2] Anthropic Engineering, “Scaling Managed Agents: Decoupling the brain from the hands,” Anthropic Engineering Blog, Jun 2026. https://www.anthropic.com/engineering/managed-agents
[3] Anthropic, “Get started with Claude Managed Agents,” Claude Platform Docs. https://platform.claude.com/docs/en/managed-agents/quickstart
[4] Anthropic, “Claude Managed Agents overview,” Claude Platform Docs. https://platform.claude.com/docs/en/managed-agents/overview
[5] Anthropic, “Using agent memory,” Claude Platform Docs. https://platform.claude.com/docs/en/managed-agents/memory
[6] Anthropic, “Define outcomes,” Claude Platform Docs. https://platform.claude.com/docs/en/managed-agents/define-outcomes
[7] Anthropic, “Dreams,” Claude Platform Docs. https://platform.claude.com/docs/en/managed-agents/dreams
[8] Anthropic, “Authenticate with vaults,” Claude Platform Docs. https://platform.claude.com/docs/en/managed-agents/vaults
[9] Anthropic, “Pricing,” Claude Platform Docs. https://platform.claude.com/docs/en/about-claude/pricing
[10] Google, “Interactions API overview,” Gemini API Docs, Google AI for Developers. https://ai.google.dev/gemini-api/docs/interactions-overview
[11] Google, “Gemini Interactions API reference,” Google AI for Developers. https://ai.google.dev/api/interactions-api
[12] Google for Developers, “Get started with the Interactions API,” YouTube, Jul 2026. https://www.youtube.com/watch?v=iOK1-b_9Dlg
[13] Amazon Web Services, “Amazon Bedrock AgentCore is now generally available,” AWS What’s New, Oct 2025. https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available
[14] OpenAI, “Deprecations,” OpenAI API Documentation. https://developers.openai.com/api/docs/deprecations
[15] Cursor, “What we’ve learned building cloud agents,” Cursor Blog, Jun 2026. https://cursor.com/blog/cloud-agent-lessons
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.