Defined for Each Deployment

OpenAI publishes one of the most granular data-handling determinations in this arc.

Its platform data-controls page carries a per-endpoint table stating, for every endpoint, whether content is used for training, how long abuse-monitoring logs are retained, how long application state persists, and whether the endpoint is eligible for Zero Data Retention [3]. An architect can read that table before writing a line of code and know what the platform will hold.

Presence is not on that table.

Its features, models, channels, capacity, data handling, pricing, and service commitments are defined for each deployment, and the deployment documentation is named as the definitive source [2]. Presence reached limited general availability on July 22, 2026 as a managed platform delivered by OpenAI forward-deployed engineers and selected integrators rather than by self-serve signup [1][2].

Both of those are deliberate. They are also two different kinds of artifact answering the same question, and the difference decides what an architect can specify and when.

Five Bands, One Determined

One band resolves from published material. OpenAI operates the managed platform, so the orchestration loop is platform-held and is not a customer concern by design — that is what buying a managed deployment means.

The other four are set in the approved architecture for a given engagement. Channels are scoped to the job, the agent’s configuration is selected during technical scoping and validated per workflow, execution is not described publicly, and tool access is confirmed as part of the same scoping [2]. The chips read “per deployment” because that is what OpenAI publishes, not because the determination is missing. It exists; it lives in a document held by the customer and OpenAI jointly.

This is the only frame in the arc where the annotation column is mostly one value, and that uniformity is the finding rather than a gap in the reading.

Where Does the Session Record Reside?

Per deployment — and the platform-side comparison is worth making precisely, because OpenAI draws the same structural distinction elsewhere that the other platforms in this arc draw.

On the API platform, stateful conversation surfaces are documented as retaining application state until deleted and as ineligible for Zero Data Retention, while stateless completion endpoints retain no application state by default and are eligible [3]. Statefulness and retention eligibility move together. That is the same architectural fact the Claude dispatch records, stated independently by a different vendor about a different product, which is worth noting because it suggests the constraint is a property of stateful agent execution rather than of any one company’s design choice.

OpenAI also publishes customer-side controls that bear directly on the question. Data residency is configured per project, with regions where content is stored at rest and a narrower set where inference is also performed, and OpenAI is explicit that system data — account data, metadata, and usage data without customer content — may be processed outside the selected region [3]. Enterprise Key Management applies customer-managed encryption keys to application state created during platform use, with keys held in the customer’s own key management system [3]. Retention controls including zero data retention are available to qualifying organizations on the API platform [5], and OpenAI states that the infrastructure supporting its API and business products has been examined by an independent auditor, with a product compliance page maintained to show status by product [4] — a page on which Presence does not currently appear.

For Presence, the processor arrangement is not published. What the agent can access, what is logged, how sensitive data is masked, retention periods, storage location, and who has access are defined and reviewed for each deployment [2]. The right conclusion is not that the controls are weaker. It is that they are unreadable until the engagement exists.

What Is the Hard Limit Denominated In?

Not published for Presence.

The other two platforms in this arc name a unit and a field. Presence names neither in public material, because commercial terms are specific to each customer and deployment [2]. A managed engagement can carry a spend ceiling — it simply carries it in a contract rather than in configuration, where a reviewer outside the engagement cannot see it.

Worth stating plainly: this is a legitimate arrangement. An accountable counterparty with commercial exposure is a real control, and for many buyers a stronger one than a field in a configuration file. It is not, however, a control an architect can specify against during design, and it is not one that can be diffed in a release process.

Where Is the Tool Gate Declared?

In the approved architecture, and OpenAI says so in those terms.

Guardrails, permissions, and approval steps define what the agent can do, qualified as depending on the deployment [2]. Tool access is confirmed during technical scoping and limited to approved knowledge and business systems with scoped permissions [2].

The distinction the visual draws is between two kinds of readable artifact. A configuration object can be read at specification time, versioned in a repository, and diffed by a release process. A deployment document can be read by the parties to it, reviewed on a defined cadence, and enforced contractually. Both are real answers. They differ in who can read them and when — which is the whole of the architect’s problem, and none of the vendor’s failing.

What Presence Contributes

Two properties in this model are stronger than anything the self-serve surfaces in this arc provide, and both belong in an architect’s toolkit regardless of platform.

Both are practices, established during a managed engagement. Neither requires a managed engagement to adopt.

Next in the arc: the closeout tabulates all three platforms against the three questions and states what none of them supplies.