The Harness You Can Buy

Our corpus defines the harness as the layer that assembles context, authorizes the tool call, and commits state.

Anthropic now sells that layer, and uses the same word for it: Managed Agents pairs an agent harness tuned for performance with production infrastructure, providing the harness and infrastructure for running Claude as an autonomous agent, so that rather than building your own agent loop, tool execution, and runtime, a team gets a managed environment where Claude can read files, run commands, browse the web, and run code. It reached public beta on April 8, 2026 — four months before Compliance API coverage extended to Cowork and Claude Code sessions.

It was not included in that extension. Our observation is that this is worth reading closely, because the product is the harness itself.

Observability moves into the product

Anthropic’s own account of the progression is a ladder, and it is drawn in three diagrams that share one legend and vary one thing: how much is run by Anthropic rather than by the customer.

At the first rung, the Messages API, the model is provided and the agentic loop is the customer’s to build — session management, observability, credentials, hosting, and sandboxing all sit beneath as production infrastructure the customer builds and runs. At the second, the Claude Agent SDK, the harness arrives as a library the customer still operates on its own infrastructure, and session management and observability become Anthropic primitives to build on rather than build from scratch. At the third, Managed Agents, the loop, the sandbox, the credentials, the hosting, session management, and observability are all run by Anthropic.

The post is explicit that observability is one of six production problems the product exists to solve. It asks what a team does when an agent works autonomously for an hour and does something surprising — whether every step it took can be reconstructed. Managed Agents answers it: because the whole run is already a record of events, observability comes with it, and the Claude Developer Console offers a native visual timeline view of agent sessions and a debugging experience for examining any transcript in depth.

Our observation is about where that leaves the compliance function. The instrumentation an enterprise would previously have built, and would therefore have owned, is now supplied — and it is supplied inside a product the Compliance API does not return. The console view exists. The reviewer holding a Compliance Access Key is not the person looking at it.

Two things called a session

The word names two objects in the Claude platform, and they behave in opposite ways.

A Managed Agents session is a running agent instance within an environment, performing a task and generating outputs, created by a developer through the API. A Compliance API session is a Cowork or Claude Code conversation captured automatically and retrieved by a compliance function through a Compliance Access Key.

The differences that matter to a governance program are not shades of the same thing.

Managed Agents sessions can be deleted. The reference covers retrieving, listing, updating, archiving, and deleting them, and the API returns confirmation that a session has been permanently deleted. Compliance API sessions cannot: those endpoints are read-only, and local and remote sessions cannot be deleted through the Compliance API.

The deletion is bounded in one direction only. A running session cannot be deleted — an interrupt event is sent first — and memory stores, vaults, skills, environments, and agents are independent resources unaffected by session deletion. Anthropic states the preservation rule plainly: history is preserved between interactions unless the session is deleted.

A documented mechanism carries content across that line. Dreaming is a scheduled process that reviews agent sessions and memory stores, extracts patterns, and curates memories so agents improve over time, refining memory between sessions by reading from the persistent session logs. So a scheduled process reads the session record and derives durable memory from it, and that memory sits in a resource the session’s deletion does not reach.

Deleting a session therefore removes the account of a run, and does not necessarily remove what was derived from it. Whether any given run contributed to durable memory is not something the deleting party can read off the deletion. Stated precisely: session deletion is not by itself erasure of derived state, and the boundary the content may already have crossed is not the one the delete call reaches.

Privacy posture inverts too, and Anthropic states the reason. Because Managed Agents is stateful by design — sessions are long-running, resume cleanly after pauses, and store conversation history, sandbox state, and outputs server-side — it is not currently eligible for Zero Data Retention or HIPAA Business Associate Agreement coverage. In the companion dispatch, those postures were enrollment choices that removed capture. Here they are foreclosed by the product’s architecture. A regulated enterprise cannot enroll its way to either one.

What the client library shows

An earlier pass over Anthropic’s public repositories, run in August 2026 against anthropic-sdk-python at commit 071efb6, established a fact worth stating plainly because it is a presence rather than an absence.

The official SDKs are generated from one shared OpenAPI specification — the repository records 199 configured endpoints and a spec hash. Managed Agents is in that specification and generated into the client. The Python SDK exposes client.beta.sessions with methods spanning create, retrieve, update, list, archive, and delete, together with event, event-stream, thread, and resource endpoints; client.beta.agents and client.beta.environments sit alongside it. A BetaManagedAgentsDeletedSession type is generated for the delete response.

No Compliance API endpoint appears anywhere in that client. Not in the generated resources, not in the API surface documentation the repository ships.

Stated precisely: in one generated client, at one commit, from one specification, the API that executes agent work has a first-party library including a delete method, and the API that evidences agent work has none. The Compliance API documentation supplies curl and points to platforms that have built integrations on top of it.

We are not reading intent from this. Generation follows the specification, and what enters a specification is a product decision we cannot see. What can be said is what the artifact contains.

The boundary moves, and Anthropic says where

Managed Agents runs sessions in one of two environments: an Anthropic-managed cloud sandbox, or a self-hosted sandbox on infrastructure the customer controls.

The second is documented with unusual precision about where the split falls. Self-hosted sandboxes keep the orchestration on Anthropic’s side while moving tool execution into infrastructure the customer controls, so the agent’s code, filesystem, and network egress never leave that environment — and tool inputs and outputs still flow to Anthropic’s control plane, where Claude runs, so the model can see results and determine what to do next. It is offered for agents operating on data that cannot leave a network boundary, reaching internal services that are not publicly routable, or running under the organization’s own compliance and audit controls. Anthropic draws the distinction precisely: self-hosted sandboxes control where the agent’s code executes, and MCP tunnels control how Anthropic reaches MCP servers inside a private network.

Read against the anchor’s boundary model, this is the write boundary relocated and the context boundary left in place. The enterprise holds the filesystem, the processes, and the egress. Anthropic holds the loop that decides what to run next. The record of the run sits with the orchestrator; the effects sit with the customer.

Which means the self-hosted configuration an enterprise reaches for on compliance grounds does not, by itself, bring the record onto the enterprise’s side. It brings the execution.

Unattended by design

A scheduled deployment allows an agent to start sessions autonomously on a recurring cadence, configured with a standard POSIX cron expression and an IANA timezone; each firing starts a session and runs the task. Execution applies jitter of up to 15% of the interval between runs, with a minimum of five seconds and a maximum of nine minutes. Deployments carry their own agent and environment configuration and at least one initial event that starts each session’s work.

Three properties compound here rather than sitting side by side. The runs are autonomous, so no person is present when they occur. The session record of each run is deletable by whoever holds the API key. And the compliance plane does not return them at all. Those are three independent properties; the documentation reviewed here does not couple deletion to the schedule.

For a custodian question — what did this agent do, on whose behalf, and where is the record — the answer on this product is retrieved by the developer, under retention the developer controls, through a credential the compliance function does not hold. The record itself remains with the orchestrator; what moves is who can reach it.

What an architect does with this

Three things, none of which requires a vendor to change anything.

Treat Managed Agents as a distinct evidence domain. It is not covered by the instrument the rest of the estate is governed through, and an assurance map that lists “Claude” as one row will misstate it. The record exists; it is reached through a different API, held under different retention, and deleted under different authority.

Decide who holds the key. Deletion authority follows the API key. Where the compliance function has no key, it has no ability to preserve — and a legal hold that assumes preservation-by-default does not hold here.

Read the environment choice for what it moves. Self-hosting relocates execution, not the record. An enterprise choosing it for data residency should not also assume it has brought the audit trail inside the boundary, because the documentation says the orchestration stays on Anthropic’s side.

The hard claim

The compliance plane does not reach the agent product Anthropic ships as its harness. A Managed Agents run’s session record sits outside the compliance plane: the compliance function cannot retrieve it, and whoever holds the API key can permanently delete it — through a method that exists in the first-party client library, in a generated client where no compliance endpoint exists at all. The runs themselves can be scheduled, so no one need be present when they happen.

None of that is a defect. Managed Agents is a developer product on the Claude Platform, documented as such, and its session API is built for the developer who runs the agent. The Compliance API is an enterprise instrument that serves Claude Enterprise data. Both are working as described.

What the pairing produces is the set’s argument in its sharpest form. An enterprise can buy the harness — the loop, the sandbox, the scheduler, the credential store — and still owe an account of what the harness did. The vendor supplies the instrument that runs the agent. It does not thereby supply the instrument that evidences it, and nothing in the transaction transfers the obligation.

The closing dispatch takes up where that obligation then sits, across the deployment paths an enterprise chooses between and the vendors that operate them.