The arc opened on a claim: that each of these platforms publishes where its harness ends, that the boundary is disclosed rather than hidden, and that it is not a straight line.
Three readings later, that holds. What the readings added is that the disclosures are not the same kind of artifact, and the difference between them is the thing an architect has to plan around.
AWS publishes a security and access controls page stating which properties of a request the harness validates and which it does not, and assigning caller authorization and input validation to the customer [2]. Anthropic publishes a feature-eligibility table stating that Managed Agents carries neither zero-retention nor healthcare-agreement eligibility, giving the reason and extending it to every sub-feature [9]. OpenAI publishes a per-endpoint retention and eligibility table for its platform [13], and publishes for Presence that data handling, retention, storage location, and access are defined and reviewed for each deployment [12].
A page, a table, and a document held between two parties. All three are disclosures. They differ in when a reader can act on them.
The Answers, Side by Side
Read the annotation column across the three and one row is identical. The orchestration loop is platform-held everywhere, which is definitional: a managed harness is the loop somebody else runs. That is what is being bought.
Every other row differs. The top two bands sit with the customer on both self-serve surfaces and are set per engagement on the managed one. The execution sandbox is jointly held on one, platform-held by default with an elective alternative on another, and determined per deployment on the third. The tools band is shared on both self-serve surfaces, because in each case the platform supplies a gate and the customer decides what the gate governs.
The useful reading is not which column looks best. It is that four of five rows are a choice, and that the choice is being made whether or not anyone is making it deliberately.
What the Three Have in Common
Two things, and the second is the more interesting.
Nobody draws a straight line. Each vendor describes an interleaved distribution rather than a clean cut. AWS holds microVM isolation while assigning the safety of commands executed inside it to the customer [2]. Anthropic runs the loop and the session record while the agent definition and its permission policies are customer-authored [5][6]. OpenAI operates the platform while scoping the job, the access, and the guardrails per engagement [12]. Any diagram showing a single horizontal boundary is describing a convenience.
Statefulness and retention eligibility move together, and two vendors say so independently. Anthropic states that Managed Agents is ineligible for zero retention because sessions are stateful resources whose transcripts persist until deleted, and extends that to every sub-feature including self-hosted sandboxes [9]. OpenAI’s platform table shows the same shape from the other side: stateful conversation surfaces retain application state until deleted and are marked ineligible for Zero Data Retention, while stateless completion endpoints retain none by default and are eligible [13].
Two companies, two products, one structural fact. That is worth more than either statement alone, because it suggests the constraint belongs to stateful agent execution rather than to a design choice either company could simply reverse. The corollary is documented too: electing a self-hosted sandbox relocates tool execution while orchestration stays on the platform side and tool inputs and outputs still reach its control plane [8], so moving the execution boundary does not move the record boundary. An architect who wants a durable session and a no-retention commitment is asking for two things that are, on current evidence, in tension.
Worth noting what does not follow. Neither statement is about where data sits. Anthropic enforces an inference-geography pin for coherence across a multiagent roster [10], and OpenAI offers per-project data residency with an explicit distinction between regions that store content and the narrower set that also process it [13]. Both are genuine residency controls. Residency is a read-path property: where content sits, and where inference runs against it. Processor arrangement is a write-path one: which party’s systems a session’s record actually passes through — transcript, tool inputs and outputs, trace — and therefore who holds it. The term tracks the sense used in Article 4(8) of Regulation (EU) 2016/679, without being a determination under it. They are routinely conflated and they answer different auditors.
Cap Denomination
Three answers in three units.
Iterations defaulting to seventy-five, an invocation timeout, a token budget, an idle timeout, and a maximum session lifetime, each optional and overridable on a single call, surfacing as a named stop reason when one binds [3].
A cap in whole United States cents, priced continuously at public list rates, evaluated between model requests so overshoot is bounded by at most one request per thread, with the session going idle rather than terminating and settling events still accepted [7]. In a multiagent session it is one shared ceiling across threads, each priced at the model that thread was served by [10].
For a managed engagement whose commercial terms are specific to each customer [12].
These are not three grades of the same control. A resource limit bounds a run; a currency limit bounds a spend; a contractual ceiling bounds an obligation. Only the second survives a change of model provider between invocations without recalculation, and only the third carries a counterparty. An architect specifying against one and receiving another has a gap, and the gap is not the vendor’s.
One more thing belongs here, because it is easy to mistake for a cap. AWS states plainly that observability explains activity and is not a billing report, directing cost questions to Cost Explorer or the Cost and Usage Report and describing cost attribution as a tagging discipline [3]. That is a competent reporting instrument, disclosed as what it is.
Where the Gate Is Declared
All three declare one. The artifacts differ in who may read them.
Policy evaluated at a gateway boundary, naming caller, tool, conditions, and arguments, paired with a server-side refusal of a directly named tool in a final message [2]. A per-toolset permission policy with per-tool override, where a conservative default applies to connected servers and an ask decision pauses the session and returns a denial reason into the agent’s context [6]. Guardrails, permissions, and approval steps set in the approved architecture for a deployment [12].
Change control also exists on both self-serve surfaces, in different shapes. Every update mints an immutable version, and named endpoints stay pinned until promoted, so rollback is repointing [1]. Agents are versioned, and a coordinator’s roster is snapshotted at create or update and stays pinned to the versions resolved then [10]. One is a deployment artifact; the other is a composition artifact. Both give a release process something to name.
The Sequence
Order matters more than the individual answers. Classify the workload first. Resolve the processor arrangement second, because it eliminates candidates rather than ranking them. Denomination and gate readability follow, and they refine a shortlist rather than producing one. Then the result goes to compliance review.
That last step is not a formality and it is not the architect’s to complete. AWS states AgentCore’s compliance program eligibility at the service level, with part of its list recorded as internal assessment pending third-party audit [4]. Anthropic publishes which products carry which commitments and which do not [9]. OpenAI maintains a product compliance page and publishes retention controls for qualifying organizations on its platform [11][13]. Those are inputs to a determination. They are not the determination, and nothing in this arc should be read as one.
What None of the Three Supplies
The prologue promised a residual gap. The dispatches narrowed it, and the honest version is narrower than the version I would have written before reading the documentation.
Scoping mechanisms exist on all three. A gateway policy can constrain which tools a caller may reach and with which arguments, and the allowed-tools filter is overridable per invocation [2]. MCP servers are agent-scoped, and Anthropic’s guidance for limiting an agent’s reach is to declare only the servers that agent needs [10]. Each Presence deployment begins with one job and the agent receives only the access that job requires [11].
What none of them enforces is that the grant is sized to a job rather than to an agent. Presence describes that discipline as delivery practice; neither self-serve surface prevents an architect from attaching a broad toolset to a long-lived agent. And scope boundaries do not always align: vault credentials are session-scoped while MCP servers are agent-scoped, so a credential supplied for one agent’s server is present in a session where other agents run [10].
That is the gap. It is not a missing feature. It is the part of least privilege that lives in architecture, and it stays there regardless of which platform is chosen.
Three platforms published where their harnesses end. One did it on a security page, one in an eligibility table, one in a document held between the parties to an engagement. Reading the capability sheet and stopping there is what produces the surprise; reading the responsibility page is what produces a specification.
The processor arrangement sets the ceiling. The denomination sets what the cap protects. The artifact sets who can read the gate and when. Everything after that is architecture — and the architect who knows who holds the state has already made the decision that the other two questions only refine.
That closes The Published Boundary. Write the path, keep the state, read the trace — and know who holds it.
