OpenAI Presence is an enterprise product for deploying voice and chat agents in customer-facing and internal workflows. OpenAI describes it as a managed deployment that combines model reasoning with company policies, permitted actions, guardrails, evaluations, and rules for escalation to people. It is available through a limited general availability program for eligible enterprise customers.
That description matters because Presence is easy to misread as a new button or mode inside ordinary ChatGPT. It is not a normal consumer ChatGPT feature, and OpenAI says it is not yet self-serve. An organization explores access through its OpenAI account team. OpenAI Forward Deployed Engineers and selected systems integrators lead deployments.
This guide is based on OpenAI’s official Presence announcement, published July 22, 2026. It explains what the company has documented, where the announcement uses promotional language, and which commercial and technical details remain unspecified.
What OpenAI Presence is
Presence is meant to help an enterprise put an agent into a specific production workflow. OpenAI gives examples such as resolving billing issues, supporting insurance claims, and handling employee IT service requests. The agent can answer questions, use connected company systems, take actions that the organization has approved, and transfer work to a person when required.
The product supports real-time voice and chat experiences. OpenAI lists customer support, outbound sales, and higher-risk internal workflows as current contexts. A billing agent, for example, might interpret a request, verify a customer, retrieve account information, apply the company’s policy, and perform an allowed action. This example describes the intended product pattern. It does not mean every Presence agent receives every capability automatically.
Each deployment starts with one job. According to OpenAI, the agent receives only the knowledge and system access needed for that job. The customer defines what it may do, which steps need approval, and when a human should take over. This narrow scope is central to the product’s design, not an optional prompt-writing technique.
How a deployment is assembled
OpenAI says its team works with the customer to identify a useful workflow, connect relevant knowledge and systems, set permissions and policies, test the agent, and move it into production. Selected systems integrators may also support the deployment as it expands. This is a service-led implementation rather than a software download that a team configures alone.
Presence brings several components together: policies and standard operating procedures, guardrails, approved actions, simulations, evaluation tools, and a Codex-powered process for proposing improvements. Companies can keep policies, evaluation methods, and escalation rules consistent while adapting other parts for a particular workflow or channel.
The announcement does not publish a standard connector catalog or promise compatibility with named CRM, contact-center, ticketing, identity, or payment products. It says Presence can connect company systems and use account context, but the specific integration work appears to depend on the deployment. A buyer should therefore ask which systems are supported for its use case, how authentication works, what data each connection exposes, and which actions are read-only or write-enabled.
Readers comparing this managed enterprise approach with other OpenAI products may find our guide to Codex for knowledge work useful. The products can involve Codex, but they are not interchangeable: Presence is described as an agent deployment product, while the linked guide covers a different work context.
Voice, chat, and human hand-offs
Voice and chat are channels for the same basic operating model. The organization decides which behavior should remain common across channels and what should change. A spoken interaction may require different pacing or verification from a chat session, but policies and escalation conditions can be shared where appropriate.
OpenAI explicitly documents escalation to people. Guardrails can intervene when an interaction moves outside company boundaries, and tests can check whether an agent escalated at the right time. Production escalations also become a signal that teams can examine after launch. This means a hand-off is not merely a generic fallback message. It is part of the behavior that the deployment team defines and evaluates.
The source does not specify the exact transfer experience. It does not say whether every deployment supports a warm transfer, a live transcript, a generated summary, queue routing, or continuity across channels. Those details should be confirmed during solution design rather than assumed from the phrase “escalate to people.”
Testing, oversight, and changes after launch
Before release, teams can run simulations covering common requests, edge cases, and higher-risk situations. OpenAI says graders assess whether the agent reached the right outcome, followed policy, used tools correctly, and escalated when appropriate. That is a clearer standard than measuring whether an answer merely sounded fluent.
Oversight continues in production. Sessions, escalations, and quality signals can expose cases where the agent performs well or needs attention. OpenAI says Codex, using a Presence plugin, investigates those signals and suggests updates. Teams can test a proposed change against the production version before approving a staged release.
This process still requires accountable human decisions. The announcement says teams test and approve proposed changes. It does not establish that Codex autonomously edits a live agent, nor does it describe approval roles, audit-log retention, rollback mechanics, or review frequency. Enterprises should request those operational details and decide who can approve policies, permissions, tools, and production releases.
A practical evaluation should use examples from the chosen job. Tests should cover correct outcomes, prohibited actions, incomplete verification, ambiguous requests, system failures, and the point at which a person must intervene. The source supports this kind of scenario testing, but it does not provide a universal acceptance threshold. Each organization must define what adequate performance means for its own risk and service requirements.
What OpenAI reports from early deployments
OpenAI says Presence powers its English-language phone support line at 1-888-GPT-0090. The company reports that the agent handles open-ended requests, verifies callers, uses account context, and takes approved actions. It also says the system resolves 75 percent of inbound issues without human assistance and that its improvement process reduced human hand-offs by 15 percentage points in 10 days.
Those numbers are OpenAI’s own reported results for its support channel, not an independent benchmark or a guaranteed result for another company. The announcement does not publish the underlying sample, issue mix, full grading method, or confidence intervals. A prospective customer should not convert those figures into a business case without testing its own workflow and defining comparable measures.
OpenAI also identifies BBVA, SoftBank, and IAG as enterprises exploring or testing Presence-related experiences. The wording is important. BBVA is exploring voice support for everyday banking needs in Mexico, SoftBank is testing Japanese-language conversations, and IAG is exploring support during events such as severe weather. These examples show design-partner activity; the announcement does not establish broad production rollout or identical capabilities at all three companies.
Availability and purchasing context
Presence is available to eligible enterprise customers through limited general availability. OpenAI directs interested organizations to their account teams. It says deployments are led by Forward Deployed Engineers and selected global systems integrators, with further support possible as deployment expands.
No public self-serve signup, standard price, usage rate, minimum commitment, deployment schedule, or service-level agreement appears in the announcement. It also does not state which countries, industries, languages, call volumes, or enterprise account types qualify. These are sales and scoping questions for the account team.
OpenAI separately says it will continue supporting voice customers that access frontier models through the OpenAI API. That sentence helps distinguish Presence from building directly with APIs. Presence packages deployment systems and expert involvement around a defined enterprise agent. The API remains another route for teams that are building voice products. The announcement does not provide a feature-by-feature comparison or say that one route replaces the other.
What the announcement does not establish
The official post provides a product overview, not a full contract or technical specification. It does not publish pricing, service levels, uptime commitments, data residency options, retention periods, security certifications, regulatory coverage, model choices, capacity limits, latency targets, or a complete integration list. It also does not explain whether customers can export configurations or move a deployment between providers.
None of those omissions proves that a feature or assurance is unavailable. It means the cited source does not establish it. Security, privacy, legal, procurement, and architecture teams should review current contractual and technical material for the proposed deployment instead of filling gaps with assumptions.
Presence should also not be presented as a consumer ChatGPT agent builder. If you are researching self-contained ChatGPT creation tools, our ChatGPT Sites guide covers a separate product surface. Access to ChatGPT, Codex, the API, or another OpenAI business product does not, by itself, establish eligibility for Presence.
Questions to take to an OpenAI account team
Start with the exact job, channel, users, systems, and allowed actions. Ask how caller or user verification is performed, how the agent’s permissions are limited, and how a person receives an escalated case. Request the supported integration design for each required system rather than relying on a general claim that systems can be connected.
Then ask how simulations and graders are created, who can change policies, how releases are approved, and what evidence is retained. Commercial discussions should cover eligibility, implementation responsibilities, partner involvement, pricing, support, service commitments, data handling, and exit arrangements. These questions do not imply answers that OpenAI has not published. They turn the public overview into a concrete due-diligence process.
Frequently asked questions
Is OpenAI Presence a feature in regular ChatGPT?
No. OpenAI describes Presence as a deployed enterprise product in limited general availability. It is not self-serve, and interested organizations are told to contact their OpenAI account team.
Does Presence support both voice and chat agents?
Yes. OpenAI says the product currently supports real-time voice and chat experiences. The customer decides which policies, evaluations, and escalation rules stay consistent and what changes for each workflow or channel.
Can a Presence agent take actions in company systems?
OpenAI says an agent can use connected systems and take approved actions. Access is scoped to the job, while the company defines permissions, approval points, and hand-off rules. The announcement does not list every supported integration or action.
How can an organization get OpenAI Presence?
Eligible enterprise customers can access it through a limited general availability program. OpenAI says to contact the organization’s account team. The public announcement does not provide self-serve enrollment, standard pricing, or universal eligibility criteria.
Bottom line
Presence is best understood as a managed enterprise deployment for a narrowly defined voice or chat job. Its documented model combines limited knowledge and system access with company policies, testing, guardrails, approved actions, human escalation, and reviewed updates after launch. The official announcement establishes that operating model and the current access route. Detailed commercial, security, integration, and service commitments must come from the materials supplied for a specific deployment.