What it is
OpenAI Presence is OpenAI’s managed platform for putting voice and chat agents into production, launched on 22 July 2026. It is not a model and not a self-serve builder. It is a deployed product: OpenAI Forward Deployed Engineers (FDEs), or select global systems integrators, scope one job with you — resolving a billing issue, supporting an insurance claim, closing an employee IT ticket — connect the systems that job needs, encode your policies and escalation rules, test the agent, and take it live. OpenAI’s launch post names customer support, outbound sales, and high-risk internal workflows as the supported shapes.
The platform is a bundle of parts you would otherwise assemble yourself: standard operating procedures and policies, guardrails, scoped “approved actions” against your APIs, simulations and graders that run before release, and a post-launch improvement loop in which Codex, using a Presence plugin, reads production sessions and escalations and proposes changes your team tests against the live version before a controlled rollout.
It is a separate product from the agents you build inside ChatGPT. OpenAI’s help center draws the line plainly: ChatGPT Workspace Agents are created and shared inside ChatGPT and Slack workspaces; Presence agents are scoped and deployed with OpenAI or a partner and are never built through that interface.
The evidence so far
OpenAI’s own English-language phone support line runs on Presence. OpenAI reports it resolves 75% of inbound issues without a human, and that the Codex improvement loop cut human handoffs by 15 percentage points in 10 days. Both numbers are self-reported, and OpenAI has not published how it defines “resolved.”
The named customers are early: BBVA is a design partner exploring voice support for everyday banking in Mexico, SoftBank is testing Japanese-language customer conversations, and IAG is exploring support during high-demand events such as severe weather. None was described at launch as a full production deployment.
Pricing reality
There is no public price, no published billing unit, and no stated minimum. OpenAI’s help center says pricing, models, channels, capacity, and data handling are defined per deployment, and access depends on “workflow fit, implementation readiness, and available delivery capacity.” Treat that last phrase literally: during limited GA you are applying for FDE time, not buying a license.
Our planning estimate, not a quoted figure: budget like Sierra, the closest outcome-led peer, whose contracts land in the $150K–$350K+ annual range, plus the internal cost of a security, privacy, and legal review and the systems-integration work your own team owns. If your volume cannot carry a six-figure annual commitment, Presence is not a fit today.
Best for
Enterprise support and CX leaders with high-volume, policy-heavy voice or chat journeys — billing, claims, account servicing — who already have an OpenAI enterprise relationship and want OpenAI’s own engineers to own the build. It also fits RevOps teams piloting an outbound or qualification voice agent where OpenAI-led delivery is the deciding factor.
Skip it if you need to start this quarter without a sales cycle, if you want a CCaaS replacement (Presence does not describe routing, workforce management, or quality management), or if your team wants to own the agent code — in that case build on the OpenAI API directly, which OpenAI says it continues to support for voice customers.
Versus the alternatives
The two established choices are Sierra, the outcome-priced pure play with live voice deployments at scale, and Salesforce Agentforce, the default when your service desk already lives in Salesforce. The fastest-growing entrant is Decagon. Pick Sierra or Decagon when you want a vendor with many named production deployments and a contract that defines what a resolution is; pick Agentforce when CRM consolidation beats model choice. For phone-first contact centers, Parloa and PolyAI ship telephony depth Presence has not documented. Pick Presence when you want OpenAI models with OpenAI’s FDEs accountable for the outcome, and you can wait for delivery capacity.
Watch-outs
- The proof point is OpenAI’s own phone line. A vendor automating its own support has no legacy systems to fight and full control of the model. Guard: in the pilot contract, set a containment and accuracy baseline from your current tooling, define “resolved” against your reopen and repeat-contact rates, and make expansion conditional on beating it over a full quarter.
- Every term is per deployment, so nothing is standard. Data retention, storage region, model configuration, and price can all differ from the customer next to you. Guard: get retention, masking, region, and model-change notice written into the deployment documentation before security review signs off, and require notice and a re-run of your evaluation suite before any model swap.
- Delivery capacity is the bottleneck, and lock-in follows it. Agents built by OpenAI FDEs inside Presence are not portable code you own. Guard: keep your SOPs, policy rules, test scenarios, and grader criteria in your own repository from day one, so a move to Sierra, Decagon, or a DIY API build reuses them rather than starting over.