What OpenAI actually shipped
On July 22, OpenAI introduced Presence, a platform for enterprises to launch and run real-time voice and chat agents with governance built into the product rather than bolted on afterward. It is deliberately positioned above the model layer, giving operations teams a structured environment to define how an agent behaves and to prove that it behaved that way. The bundle includes policy codification and standard operating procedures, runtime-enforced guardrails that constrain what an agent can do, and pre-approved action sets covering common tasks like identity verification, account retrieval, billing resolution, and refunds.
The other half of the platform is the operating loop. Presence ships pre-deployment simulation to surface failure modes before an agent touches a customer, evaluation tooling that tracks accuracy and policy adherence, and a Codex-powered improvement process that reviews real production conversations and proposes tested changes. Read together, these are the controls a risk function asks for before it will sign off on an autonomous system talking to customers. OpenAI is selling the scaffolding that turns a capable model into an auditable one, which is a different product from the API most enterprises associate with the company.
The problem it is built to solve
The context for Presence is a year of stalled agent pilots. Across the industry the same statistic keeps surfacing, that the overwhelming majority of enterprise agent pilots never reach production, and the reason is rarely model quality. It is the absence of guardrails, audit, and a way to demonstrate control to a compliance team. Presence is engineered directly at that blocker, packaging the governance apparatus that individual enterprises have been struggling to assemble on their own from a patchwork of frameworks, monitoring tools, and internal policy.
This is where the product is genuinely interesting to a CIO who has watched demos convert into indefinite pilots. The value is in the pre-deployment simulation and the policy adherence tracking, because those are the artifacts that let a risk owner say yes. An agent that can be simulated against its failure modes, constrained to an approved set of actions, and reviewed after the fact is an agent that can clear an internal control gate. OpenAI has correctly identified that the constraint on agent deployment is organizational trust, and it has built for the buyer who needs evidence rather than the developer who needs an endpoint.
The delivery model is the tell
Presence is not a product you swipe a card to access. Deployments are led by OpenAI Forward Deployed Engineers or a short list of approved systems integrators, embedded with the customer to stand the system up. OpenAI built this capacity deliberately, acquiring Tomoro to bring roughly 150 forward deployed engineers into the organization, and routing the work through a newly formed OpenAI Deployment Company reported to be backed by 4 billion dollars at a 10 billion dollar valuation. That is a services-heavy motion that resembles Palantir's forward-deployed playbook far more than the frictionless self-service that built OpenAI's developer base.
The delivery model tells you who the customer is. High-touch engineering, embedded teams, and undisclosed enterprise pricing are the signatures of a company chasing large, complex accounts with meaningful voice and chat volume rather than the long tail of developers. It also tells you about margins and scale, since a business that requires engineers on site to deploy grows differently from one that grows through an API key. OpenAI is accepting the friction of a consulting-shaped motion because the accounts it wants, regulated, high-volume, and governance-sensitive, will not buy an agent platform any other way.
Who is already on it
The launch named early adopters that signal the target profile precisely. BBVA Mexico is using Presence for customer interactions wired into its account systems. SoftBank Corp. is deploying Japanese-language voice agents, a workload where real-time speech quality and policy control both matter. The Australian insurer IAG, through its Retail Insurance Australia arm, is applying it to customer-facing financial services support. These are exactly the regulated, high-volume, high-consequence environments where a governance layer is the difference between a pilot and a rollout.
The pattern across those three is instructive for anyone evaluating the platform. Each operates in a sector where a mishandled customer interaction carries regulatory or financial exposure, and each has the volume to justify a services-heavy deployment. Presence is not being positioned for a startup automating an internal helpdesk. It is aimed at the enterprise that already knows it needs voice and chat agents, already understands the compliance stakes, and has been unable to get past its own risk committee. That is a narrow but lucrative segment, and it is one that pays for outcomes rather than access.
The move on the application layer
The strategic reading is the one CIOs should sit with. By owning the governance layer, the connective tissue between the model and the enterprise's systems, OpenAI positions itself to define the terms of how agents interact with everything downstream. That layer has historically belonged to the application vendors: Salesforce, ServiceNow, and Zendesk built their moats on being the system agents and humans act through. Presence routes around those integration points by making OpenAI itself the place where policy, action, and audit are defined, which is a bid to become the control plane rather than one more model behind someone else's platform.
This is the same contest playing out across the enterprise stack from a different direction. ServiceNow is extending its AI Control Tower to govern agents across other vendors' systems, and Salesforce is pushing Agentforce as the acting layer over its own data. OpenAI entering with a governance-first control plane turns a two-sided fight into a three-way one, and the enterprise is the prize. For the buyer, the risk is obvious, since standardizing agent governance on the model provider is a lock-in decision of its own, made at the layer that is hardest to unwind later.
What we would watch before committing
The caution is the mirror image of the appeal. A governance layer owned by the model provider is convenient precisely because it is integrated, and that integration is where dependency accumulates. An enterprise that codifies its policies, action sets, and audit trails inside Presence is building operational memory into a single vendor's platform, and unwinding that later is the expensive kind of migration. The right diligence question is not whether Presence works, because the early adopters suggest it does, but what it costs to leave and who owns the operating knowledge once your agents have been running on it for a year.
We would treat Presence as a serious answer to a real problem while negotiating hard on portability. Insist on exportable policy definitions, clear ownership of the evaluation and conversation data your agents generate, and a governance model that can, in principle, sit above more than one model provider. The demand for agent governance is genuine and the pilots-to-production gap is costing enterprises real money. The discipline is to buy the control plane without letting the control plane quietly become the thing you can no longer control.
