Every Harness Publishes Its Boundary

Three platforms shipped managed agent harnesses inside eight weeks.

Amazon Bedrock AgentCore harness reached general availability on June 18, 2026, reducing an agent deployment to two API calls [1]. Claude Managed Agents runs in beta behind a dated beta header, built for tasks that run minutes to hours across many tool calls [5]. OpenAI Presence was announced July 22, 2026 as a managed enterprise platform delivered through forward-deployed engineers rather than self-serve signup [10]. The capability sheets converge. Read them side by side and the differences look like release cadence.

The responsibility documentation does not converge, and that is the more useful reading. Each of the three publishes, in its own words and on its own pages, where its harness ends and the customer’s architecture begins. AWS states that the harness validates the structure of a request but does not inspect its meaning, and that caller authorization and input validation are customer responsibility [2]. Anthropic states that Managed Agents is ineligible for Zero Data Retention and for HIPAA coverage, because sessions are stateful resources whose transcripts persist until deleted [9]. OpenAI states that data handling, retention, storage location, and access are defined and reviewed for each deployment, with the deployment documentation as the definitive source [11].

None of that is buried. All of it is published. The exposure this arc is concerned with is not vendor omission — it is an architect specifying against the capability page when the responsibility page is sitting one click away.

What the Matrix Left Open

The Ownership Map established two parties and a seam between them: the provider owns the substrate side, the enterprise owns the deployment side, and the Responsibility Seam is the contractual surface where one hands off to the other. That work was done against published frameworks — architectural statements about how responsibility ought to distribute.

What has changed is that the seam is now documented at the product level for these three harnesses, in operational rather than architectural language. AWS publishes a shared-responsibility statement specific to the harness [2]. Anthropic publishes a feature-eligibility table that names which data-handling commitments a given product can and cannot carry [9]. OpenAI publishes that the equivalent determinations are made per engagement [11]. Three different kinds of artifact, all answering the same question, none of which existed in this form when the matrix was built.

That makes this arc empirical where the prior dispatch was structural. The matrix supplied the columns. The dispatches populate two of its rows — Harness and Environment — from primary product documentation, one platform at a time.

One Frame, Five Bands

Before the differences are legible, the shared object has to be. Every one of these three platforms assembles the same five bands, whatever each vendor calls them.

Read top to bottom, that is a write path. A caller is authenticated. An agent definition names a model, a prompt, a toolset, and a body of skills or instructions. An orchestration loop turns a goal into a sequence of steps. An execution sandbox gives those steps a filesystem and a shell. Tools and model providers are where the side effects land — the row where something outside the harness changes.

This frame recurs in all four remaining posts with only the annotated layer changing. It deliberately draws no responsibility line. A single horizontal cut would misrepresent all three platforms, and most severely the one whose customer holds the most: on the AWS side the platform holds microVM isolation and the managed orchestration loop while the customer holds caller authorization, input validation, and the provenance of skill sources [2]. Responsibility interleaves. Any diagram that shows it as a clean line is describing a convenience, not a boundary.

The dispatches draw the line per platform, where the vendor put it.

The Row That Decides the Rest

Feature parity is real and increasing. What separates these three is narrower: for a given session, who processes its record?

Processor arrangement is which party’s systems a session’s record actually passes through — the transcript, the tool inputs and outputs, and the trace — and therefore who holds it. It is a property of the write path, not of where data is stored and not of where inference runs. The term tracks the sense used in Article 4(8) of Regulation (EU) 2016/679, without being a determination under it.

On the AWS side all three sit with the customer. Sessions run in an isolated environment in the customer’s own account, managed memory is provisioned as an addressable customer-owned resource, and traces and logs flow to CloudWatch through the harness execution role, with harness operations logged as management and data events [1][3].

For Managed Agents the top surface is a choice and the other two are not. Event history is persisted server-side, with a managed cloud sandbox or a self-hosted sandbox on the customer’s own infrastructure [5]. Self-hosting relocates tool execution; orchestration stays on Anthropic’s side, and tool inputs and outputs still reach Anthropic’s control plane so the model can act on results [8]. The execution boundary and the record boundary move independently — a distinction worth internalizing before it appears in a compliance review, and one Anthropic makes explicit rather than leaving to inference: the eligibility statement covers all Managed Agents sub-features, self-hosted sandboxes included [9].

For Presence, all three are set per deployment [11].

That row is not a scorecard. Customer-side processing buys retention control and costs integration work; platform-side processing buys managed operation and constrains which data-handling commitments are available; per-deployment definition buys an accountable counterparty and defers the answer past specification time. Three legitimate architectures. One question that has to be answered before a workload is assigned to any of them.

Note also the third surface. Trace destination is where retention schedule, legal hold, and discoverability actually live, and it is the surface with the least marketing attention. Cross-zone trace continuity is the property under examination there, and the closeout returns to it.

Three Questions, Asked in the Same Order

Each dispatch answers the same three, in sequence. Fixing the interrogation is what makes the closeout a tabulation rather than a summary.

What This Arc Excludes

These are first-party harnesses read on their own terms. Layers composed over other vendors’ harnesses are a different object with a different boundary and a different party accountable for the seam, and they are out of scope here.

Also out of scope: vendor-reported performance figures. Where a platform publishes its own operational metrics from its own workloads, those are worth reading and are not comparison rows.

What the Closeout Will Say

Stating the conclusions here rather than staging them:

The processor arrangement, not the harness feature set, sets the ceiling on which workloads a platform can carry. The three platforms document three different arrangements. Where regulated data is involved, the arrangement is the first question and the feature list is the second. Each platform publishes something on this — AWS states AgentCore’s compliance program eligibility at the service level, with part of that list internally assessed pending third-party audit [4] — and the artifacts are not interchangeable. That reading requires compliance review before it becomes a routing decision.

Cap denomination is a specification-time choice, not an implementation detail. A limit in currency and a limit in iterations protect different things, and only one of them survives a mid-session change of model provider.

All three supply scoping mechanisms; none enforces that a grant is sized to a job rather than to an agent. Presence describes that discipline as delivery practice — each deployment starts with a specific job, and the agent receives only the access that job requires [10]. The self-serve surfaces make scope authorable rather than enforced: neither prevents an architect from attaching a broad toolset to a long-lived agent, and scope boundaries do not always align across credentials and tools. That remainder is the customer’s to close, and it is closed in architecture rather than in configuration.

Next in the arc: the AWS AI Architect dispatch reads AgentCore harness on the three questions, and opens with the shared-responsibility statement that did not exist when the matrix was drawn.