# OpenAI Presence: Enterprise Agents Guide

> OpenAI Presence guide to availability, architecture, governance, pricing unknowns, evaluation, security questions, and a practical enterprise pilot.

- **Published**: 2026-07-22
- **Category**: AI Infrastructure
- **URL**: https://agentpedia.codes/blog/openai-presence-enterprise-agents-guide

---

> **Important callout**

**Bottom line:** OpenAI Presence is an enterprise product deployed with OpenAI Forward Deployed Engineers and select global systems integrators for voice and chat agents, not a self-serve API or packaged chatbot. It is available to eligible enterprise customers through limited general availability. Pricing, service levels, regions, technical tenancy, and contract details are not public, so the buying decision should begin with a narrow workflow and a written evaluation plan.

OpenAI [introduced Presence on July 22, 2026](https://openai.com/index/introducing-openai-presence/) for customer-facing and internal workflows that need more than model access. The product combines scoped company knowledge and system access with policies, guardrails, approved actions, simulations, evaluations, human escalation, production feedback, and controlled improvements proposed with Codex.

This guide uses official OpenAI sources with a July 22, 2026 cutoff. It separates what OpenAI has published from what a buyer still needs to establish in technical diligence and contract review. AgentPedia did not test a Presence deployment or reproduce OpenAI's internal support results.

**Official launch quote:** "New for enterprises: OpenAI Presence helps companies deploy trusted voice and chat agents across customer and internal workflows." [OpenAI, July 22, 2026](https://x.com/OpenAI/status/2079916436232036614)

## What OpenAI Presence is

Presence is a deployed enterprise product for putting an agent into a defined job. OpenAI's examples include billing support, insurance claims, employee IT service, outbound sales, and other voice or chat workflows. The customer sets the workflow policies: what the agent may do, what needs approval, and when a person takes over. OpenAI and its implementation partners help connect the necessary systems, test the workflow, and move it into production.

That makes Presence different from buying model tokens or adding a general assistant to a contact center. The product boundary described at launch includes the operating system around the model:

| Component | Published role in Presence | What buyers should pin down |
| --- | --- | --- |
| Job-scoped knowledge | Give the agent only the knowledge needed for a specific job | Source systems, freshness, permission filtering, conflict handling, and deletion behavior |
| Job-scoped system access | Connect only the systems required for that job | Authentication, service identities, network paths, read/write scope, and credential ownership |
| Policies and SOPs | Define how the agent should handle requests | Source of truth, versioning, exceptions, policy precedence, and owner approval |
| Guardrails | Intervene when an interaction leaves company boundaries | Enforcement point, failure behavior, coverage, false-positive handling, and test evidence |
| Approved actions | Let the agent perform permitted operations | Parameter limits, idempotency, transaction boundaries, reversibility, and step-up approval |
| Simulations and evaluations | Test common, edge, and higher-risk scenarios before release | Dataset ownership, graders, thresholds, coverage drift, and independent review |
| Escalation | Hand work to a person when policy or confidence requires it | Trigger logic, context transfer, queue routing, customer disclosure, and time to pickup |
| Production feedback | Surface sessions, escalations, and quality signals after launch | Sampling, retention, access controls, incident linkage, and feedback quality |
| Codex-powered improvement | Investigate signals and propose changes for testing | Repository access, proposed-change format, approval authority, provenance, and rollback |

OpenAI describes Presence as supporting real-time voice and chat. The launch does not publish a Presence API reference, SDK, endpoint, model ID, architecture diagram, deployment region list, or self-service setup path. Those omissions are not defects by themselves in a managed product, but they belong on the diligence list rather than being filled with assumptions from the separate OpenAI API.

## Availability and pricing

As of July 22, 2026, Presence has a narrow commercial route: an eligible enterprise customer works with OpenAI's account team, and OpenAI Forward Deployed Engineers (FDEs) plus select global systems integrators lead the deployment. OpenAI calls the program **limited general availability** and says it is **not yet self-serve**.

| Question | Published answer | Buying implication |
| --- | --- | --- |
| Is Presence available? | Yes, to eligible enterprise customers through limited GA | Availability still depends on eligibility and a managed engagement |
| Is it self-serve? | No | There is no documented click-to-buy or independent setup path |
| Who implements it? | OpenAI FDEs and select global systems integrators lead deployments | Delivery capacity, partner assignment, and responsibilities need agreement |
| Which channels are supported? | Real-time voice and chat | Confirm the exact telephony, messaging, locale, and channel scope for the proposed workflow |
| Is there a public Presence API? | None is documented in the launch material | Do not treat generic OpenAI API access as Presence access |
| What does Presence cost? | Not published | Request a scoped proposal and a workload-based cost model |
| Are SLAs or support tiers public? | Not in the announcement | Negotiate uptime, support hours, severity definitions, and remedies |
| Are regions and data residency published for Presence? | Not in the announcement | Ask which commitments apply to this product and each connected system |
| Is a procurement timeline published? | No | Treat any schedule as customer-specific until contracted |

OpenAI directs interested organizations to their account team. Organizations without that relationship can use the official [sales contact form](https://openai.com/contact-sales/), but the form does not guarantee Presence eligibility or a response time.

The phrase "limited general availability" deserves precise treatment. Presence is beyond a private concept or a self-described preview, yet its eligibility and deployment model remain constrained. It does not mean universal access, a public SKU, or a standard implementation timeline.

## Who Presence fits

Presence is easiest to justify when a workflow has enough volume and value to support a managed implementation, but is bounded enough to evaluate and govern. The table below is a buyer-fit framework, not an OpenAI eligibility policy.

| Organization or workflow | Fit | Why |
| --- | --- | --- |
| High-volume support with repeatable policies and system actions | Strong candidate | Resolutions, escalations, and action accuracy can be measured against an existing operating baseline |
| Voice workflow where latency, turn-taking, verification, and handoff all matter | Strong candidate | Presence explicitly supports real-time voice and includes escalation and evaluation in the product description |
| High-risk internal service desk with clear authorization boundaries | Conditional candidate | The scope can be narrow, but identity, permissions, auditability, and fail-closed behavior need strong evidence |
| Workflow with frequently changing policies but controlled release processes | Conditional candidate | The Codex-powered proposal and test loop may help, provided humans retain approval and rollback control |
| Early-stage team seeking a self-serve chatbot | Poor fit | Presence is not self-serve and requires a managed enterprise deployment |
| Process with unclear ownership or contradictory policies | Poor fit today | Automation will expose the ambiguity; resolve policy authority before adding an acting agent |
| Irreversible, safety-critical, or legally determinative action without human review | Poor fit unless tightly constrained | The launch does not establish that Presence removes the need for accountable human authorization |
| Team that needs full infrastructure ownership and portable components | Compare carefully | A custom API stack or another platform may offer more implementation control, with more engineering burden |

A good first workflow has one accountable business owner, a stable source of policy truth, a measurable human baseline, accessible test cases, and actions that can be limited or reversed. "Handle customer service" is too broad. "Resolve duplicate subscription charges up to a defined amount after identity verification, otherwise escalate" is testable.

## Architecture and governance boundaries

OpenAI publishes a product-level operating model rather than a detailed technical architecture. For review purposes, separate the **data plane** that handles a live interaction from the **control plane** that defines and changes allowed behavior.

```text
Control plane
Company policy owner ──> SOPs, permissions, approvals, escalation rules
                              │
                              v
                       Simulations + evaluations
                              │ pass threshold
                              v
                         Approved release

Data plane
Voice/chat request ──> scoped knowledge + company systems ──> response/action
                              │                         │
                              └──── guardrails ─────────┤
                                                        └──> human escalation

Improvement loop
Production signals ──> Codex investigates/proposes ──> test ──> human approval
                                                               │
                                                               └──> controlled rollout
```

This diagram is an interpretation of the launch description, not a claim about Presence's internal network topology or software services. It highlights four governance boundaries that a deployment should preserve:

1. **Policy authority stays with the enterprise.** OpenAI says the company sets what the agent may do, when approval is required, and when a person takes over. Every policy needs an owner who can resolve conflicts and sign off on changes.
2. **Runtime authority is narrower than model capability.** The agent should receive only the knowledge and system access required for its job. Tool and identity controls should enforce this boundary; instructions alone are not an authorization system.
3. **Evaluation gates separate a proposal from a release.** Simulations and graders test outcomes, policy adherence, tool use, and escalation. A proposed update should not reach production merely because it improved an aggregate score.
4. **Codex proposes; an accountable team approves.** OpenAI says teams can test proposed changes against the production version and approve a controlled rollout. Buyers should confirm that this separation is technically enforced and auditable.

The launch does not say who hosts every component, how customer systems connect, whether environments are single-tenant, how secrets are stored, what event detail is logged, or which party operates each control. Ask for the actual deployment data-flow diagram and responsibility matrix before security approval.

## From workflow selection to production feedback

The published Presence lifecycle can be turned into six reviewable stages.

| Stage | Work described by OpenAI | Enterprise acceptance artifact |
| --- | --- | --- |
| 1. Select the job | Identify a high-value workflow | Signed scope, excluded intents, owner, baseline volume, and success metric |
| 2. Connect context | Add necessary knowledge and systems | Data-flow diagram, access inventory, credential model, and freshness test |
| 3. Encode control | Establish permissions, policies, guardrails, and escalation | Versioned policy pack, action allowlist, approval matrix, and fail-state design |
| 4. Simulate and evaluate | Test normal, edge, and higher-risk scenarios with graders | Frozen test set, grading rubric, threshold, red-team cases, and failure report |
| 5. Release narrowly | Bring the agent into production | Traffic cap, user disclosure, monitoring, human coverage, stop switch, and rollback plan |
| 6. Improve under control | Inspect sessions and escalations; test Codex-proposed changes | Change diff, provenance, regression results, approver identity, rollout record, and post-release check |

![Official OpenAI Presence interface showing simulation results for an annual-refund policy](/content-assets/openai-presence-enterprise-agents-guide/presence-simulation.png)

*OpenAI's launch material shows a simulation view used to evaluate a policy change before rollout. The screenshot illustrates the product workflow; AgentPedia did not reproduce the run. [Source](https://openai.com/index/introducing-openai-presence/).*

The improvement loop addresses a real maintenance problem: agent quality drifts when policy, products, customer language, and upstream systems change. It also creates change-management risk. A change may improve common cases while weakening a rare but consequential policy. Keep high-risk suites, safe counterexamples, and non-regression tests mandatory for every release.

## What OpenAI's reported results show

[OpenAI uses Presence](https://openai.com/index/introducing-openai-presence/#proven-in-leading-enterprises) for its English-language phone-support channel at `1-888-GPT-0090`. The company says the agent handles open-ended requests, verifies callers, uses account context, and takes approved actions. Two launch figures describe that one deployment:

| Deployment | Vendor-reported result | Reported timeframe | Scope and caveat |
| --- | ---: | --- | --- |
| OpenAI English-language phone support | **75% of inbound issues resolved without human assistance** | Reached within weeks | OpenAI's own deployment and quality benchmarks; no sample size, issue mix, denominator rules, cost, or independent reproduction published |
| Same deployment, working with the launch team | **15-percentage-point reduction in human handoffs** | 10 days | OpenAI attributes the change to the Codex-powered improvement loop; starting rate, ending rate, traffic mix, and confidence interval are not published |

![Official OpenAI Presence dashboard showing production-health and customer-intent analytics](/content-assets/openai-presence-enterprise-agents-guide/presence-health.png)

*OpenAI's launch screenshot presents production-health and intent analytics. It is vendor product media, not independent validation of the reported support results. [Source](https://openai.com/index/introducing-openai-presence/).*

These are vendor-reported operational outcomes, not a general benchmark for Presence, voice agents, or customer support. A 15-percentage-point change is also different from a 15% relative reduction. For example, moving from 40% to 25% handoffs is a 15-point reduction and a 37.5% relative reduction; OpenAI publishes the point change, not the underlying rates.

OpenAI also names three enterprise relationships with carefully limited verbs: BBVA is **exploring** voice support for everyday banking in Mexico, SoftBank is **testing** natural Japanese-language customer conversations, and IAG is **exploring** support during high-demand events such as severe weather. Those statements show design-partner activity, not proof that each company has completed a broad production rollout or reproduced OpenAI's support metrics.

Before adopting a vendor number as a target, reconstruct its denominator:

- Which contacts enter "inbound issues," and which are excluded?
- Does "resolved" require no repeat contact within a fixed window?
- Are transfers, abandoned calls, callbacks, and agent-created follow-ups counted?
- What share of requests were eligible for autonomous action?
- How do customer satisfaction, policy violations, refunds, complaints, and total cost change at the same time?

## What to ask in the evaluation

A Presence evaluation should test the complete operating system, not only response quality. Ask OpenAI and the delivery partner to map every answer to a demo, configuration, contract term, or exported artifact.

| Area | Questions to answer before production | Evidence to request |
| --- | --- | --- |
| Scope | Which intents are in scope, excluded, or always escalated? | Intent taxonomy and signed workflow boundary |
| Knowledge | How are permissions inherited, conflicts resolved, and stale content detected? | Retrieval test set, freshness SLA, and permission-negative tests |
| Identity | How is a caller or user verified before protected data or actions are available? | Authentication flow and step-up test cases |
| Tools | Which actions are read-only, reversible, capped, or approval-gated? | Tool schema, allowlist, parameter limits, and denied-call logs |
| Policies | Which document wins when two SOPs disagree, and who approves a change? | Version history, precedence rule, and approval record |
| Guardrails | Where are controls enforced, and what happens when a guardrail or dependency fails? | Fail-open/fail-closed matrix and adversarial results |
| Evaluation | What are the pass thresholds by risk class, not only in aggregate? | Frozen cases, grader definitions, human adjudication, and confidence bounds |
| Voice | How does the system handle accents, noise, interruptions, silence, exact entities, and consent? | Audio-condition matrix, transcript review, and latency distributions |
| Chat | How does it handle long sessions, copied instructions, malformed attachments, and channel handoff? | Multi-turn and prompt-injection test suite |
| Escalation | Does the person receive the right context, reason, and action history without unsafe leakage? | Handoff transcript, queue routing, and pickup-time measurements |
| Operations | Can operators stop a workflow, revoke access, roll back a release, and preserve evidence? | Runbook and live incident exercise |
| Change control | What exactly does Codex inspect and propose, and can it publish without separate approval? | Example change diff, access boundary, approver log, and rollback proof |

Measure distributions rather than averages. Voice latency at the 95th and 99th percentiles, handoff pickup time during a surge, and policy accuracy on rare cases will expose risks that a single mean score hides.

## Procurement checklist

The public launch leaves commercial and operational terms open. Resolve them in a written order form, statement of work, architecture pack, and security review.

- [ ] Confirm that the named legal entity and proposed workflow are eligible for the limited-GA program.
- [ ] Define the workflow, channels, languages, user populations, excluded intents, and launch geography.
- [ ] Identify whether OpenAI, a systems integrator, or the enterprise owns each integration and operating task.
- [ ] Request complete pricing: implementation, platform, usage, telephony, partner, support, change, and overage charges.
- [ ] Model cost per attempted contact, successful resolution, escalation, and retained customer outcome.
- [ ] Negotiate availability, latency, support hours, severity levels, response targets, maintenance windows, and remedies.
- [ ] Document data categories, subprocessors, processing locations, retention, deletion, backup, export, and legal holds.
- [ ] Confirm which OpenAI security, privacy, residency, and compliance commitments explicitly cover Presence.
- [ ] Inventory every identity, credential, network connection, knowledge source, and write-capable action.
- [ ] Define ownership of prompts, policies, evaluation sets, transcripts, proposed changes, and deployment artifacts.
- [ ] Require audit-log access, export formats, retention periods, and evidence for administrative and agent actions.
- [ ] Agree on incident notification, joint investigation, credential rotation, customer communication, and evidence preservation.
- [ ] Set acceptance thresholds, pilot exit criteria, production traffic caps, rollback triggers, and termination assistance.
- [ ] Plan data and configuration export so the organization can switch vendors or return to a human workflow.

Do not import terms from ChatGPT Enterprise or the OpenAI API into a Presence review without confirmation. OpenAI publishes broad [business data commitments](https://openai.com/business-data/) for named products and its API platform, but the Presence announcement does not spell out which product-specific controls, certifications, retention options, or residency choices apply to a given Presence deployment.

## Security and risk review

The core security question is not whether the model can answer a support question. It is whether the deployed system can keep data and action authority inside the job boundary when users, documents, integrations, and upstream systems behave unexpectedly.

| Risk | Failure example | Minimum control to evaluate |
| --- | --- | --- |
| Excessive authority | A billing agent issues a refund outside policy or changes an unrelated account | Least-privilege identity, server-side parameter limits, idempotency, transaction caps, and approval gates |
| Prompt injection | Retrieved content or a user attempts to override policy and call a tool | Trust separation, content handling, tool authorization independent of model text, and adversarial tests |
| Identity failure | The agent exposes account context to an unverified caller | Step-up verification tied to action sensitivity and safe retry limits |
| Data overexposure | A job-scoped agent retrieves records outside the caller's or employee's entitlement | Permission-aware retrieval, negative tests, minimization, and field-level masking |
| Unsafe policy change | A proposed update raises the aggregate score but weakens a rare exception | Risk-tiered regression gates, protected cases, named approval, staged rollout, and rollback |
| Silent dependency failure | CRM, identity, or policy source is unavailable but the agent continues as if current | Explicit degraded modes, fail-closed actions, user disclosure, monitoring, and escalation |
| Bad handoff | A human receives no context, stale context, or sensitive data they should not see | Structured transfer packet, reason code, access filtering, and queue acknowledgment |
| Weak auditability | Operators cannot reconstruct which policy, tool result, or release drove an action | Correlated event trail with policy and release versions, tool inputs/results, approvals, and timestamps |
| Voice-specific error | Noise or accent changes an amount, name, consent signal, or account identifier | Confirmation prompts for consequential entities, transcript checks, DTMF or alternate channel, and human fallback |
| Vendor concentration | The organization cannot operate or migrate when the deployed product is unavailable | Export, continuity process, manual fallback, termination assistance, and tested recovery |

For a broader lesson on containing high-capability evaluations and preserving authorization boundaries, see AgentPedia's [OpenAI-Hugging Face security incident analysis](/blog/openai-hugging-face-evaluation-security-incident). That separate event does not prove a flaw in Presence; it does show why infrastructure-enforced permissions and tested stop controls matter more than a model instruction to stay within scope.

## Build, buy, or use Presence

Presence is one route to an enterprise agent. OpenAI explicitly says voice customers will continue to have access to frontier models through the OpenAI API. The official [voice agents guide](https://developers.openai.com/api/docs/guides/voice-agents) describes separate build-your-own speech-to-speech and chained voice architectures. That API path is an alternative implementation model, not a self-serve version of Presence.

| Path | Best when | Main advantage | Main burden |
| --- | --- | --- | --- |
| OpenAI Presence | The workflow warrants hands-on enterprise deployment and the buyer wants one deployed product with hands-on implementation support around policy, evaluation, escalation, and improvement | Integrated deployment model with OpenAI FDE and partner support | Limited eligibility, unpublished pricing, and less public implementation detail |
| Build on OpenAI APIs and Agents SDK | Engineering wants to own architecture, integrations, releases, and operational controls | More component and deployment control; public developer documentation | The enterprise must assemble evaluation, governance, observability, support, and continuous improvement |
| Contact-center or workflow platform with agent features | Existing routing, workforce, recording, and compliance operations should remain the center | Faster fit with current channels and operator processes | Model and agent behavior may be constrained by the platform; integration boundaries still need review |
| Specialist integrator or custom build | The process is unusual, multi-vendor, regulated, or deeply tied to legacy systems | Tailored architecture and clearer ownership choices | Higher delivery risk, more vendors, and a larger long-term maintenance surface |
| Improve human workflow first | Policies, data, or ownership are not ready for autonomous action | Fixes the operating foundation without premature automation | Delays agent deployment but often removes the largest sources of failure |

Teams choosing the API route can use the [OpenAI Agents Python guide](/blog/openai-agents-python-guide) for orchestration concepts and the [secure MCP tunnels guide](/blog/openai-secure-mcp-tunnels-guide) for a closer look at exposing internal tools. Teams considering agents that can move money should also review the [agentic payments risk boundaries](/blog/agentic-payments-explained).

Do not compare vendor demos alone. Give every candidate the same intent distribution, policy corpus, tool sandbox, escalation queues, cost accounting, and acceptance rubric. The most useful comparison is successful, policy-compliant outcomes per total operating dollar with failures and human work included.

## A practical pilot plan

An enterprise pilot should prove a bounded operating case, not maximize automation on day one. A six-stage plan keeps the test reversible.

### 1. Freeze the baseline

Choose one workflow and measure at least four weeks of representative human performance where possible: contact volume, resolution definition, repeat contacts, handling time, handoffs, customer outcome, policy exceptions, operational cost, and incident rate. Preserve the traffic distribution instead of testing only easy contacts.

### 2. Write the authority map

For every intent, list the knowledge sources, allowed systems, read and write operations, transaction limits, approval requirements, escalation triggers, prohibited outcomes, and accountable owner. Start read-only or with reversible low-value actions. Make actions outside the map technically unavailable.

### 3. Build the evaluation set

Create common cases, hard-but-valid cases, policy conflicts, identity failures, malicious instructions, stale data, dependency outages, ambiguous language, voice noise, interruptions, and safe counterexamples. Separate launch blockers from quality improvements.

| Risk tier | Example | Suggested release rule |
| --- | --- | --- |
| Critical | Unauthorized disclosure, wrong-account action, prohibited transaction, missed mandatory escalation | Zero accepted failures in the approved test set; any production occurrence stops affected actions |
| High | Incorrect policy outcome, failed identity step-up, misleading commitment | Explicit high threshold plus human adjudication of every failure |
| Medium | Unnecessary handoff, incomplete explanation, recoverable tool failure | Threshold tied to the human baseline and queue capacity |
| Experience | Awkward phrasing, minor latency, repeated clarification | Track by distribution; improve without weakening higher-risk gates |

These are planning categories, not published OpenAI thresholds. The enterprise should set numbers that match its legal, customer, and operational obligations.

### 4. Run shadow and sandbox modes

First compare the agent's proposed response and action with the human outcome without letting it act. Then allow only sandbox actions. Review disagreement by risk tier, not only aggregate accuracy. Confirm that audit evidence lets an operator reconstruct the decision.

### 5. Release a small traffic slice

Use a defined population, staffed escalation queue, action caps, live monitoring, and an operator stop control. Tell users when they are interacting with an automated agent where required or appropriate. Keep a control group if the operating environment supports a fair comparison.

### 6. Decide with pre-agreed exit criteria

Expand only if critical controls pass, customer outcomes meet the baseline, handoff quality is acceptable, unit economics include human and partner work, and rollback has been exercised. Pause or narrow the workflow when a high-risk boundary fails. Do not offset a security or policy failure with gains in average resolution rate.

For each Codex-proposed improvement, retain the before-and-after change, source signal, test results, approver, rollout cohort, monitoring window, and rollback decision. That record turns "improves over time" into a governed release process.

## The practical verdict

**Evaluate Presence** if the organization has a high-value, high-volume voice or chat workflow; clear policy ownership; systems that can expose narrow permissions; enough evaluation data; and a reason to prefer an FDE-led deployment over assembling the stack internally.

**Wait and fix the operating model first** if policies conflict, identity and authorization are weak, escalation queues cannot absorb failures, or nobody owns the outcome. Presence cannot turn an undefined process into an accountable one.

**Compare a custom API build** if self-service access, infrastructure control, component portability, or a multi-vendor architecture matters more than an FDE-led OpenAI deployment. Price both routes on total operations, not model tokens alone.

The launch documents the product shape and one positive OpenAI-run support result. It does not establish price, contractual coverage, deployment architecture, or performance for another enterprise. A narrow, reversible pilot with risk-tiered gates is the right next step.

## FAQ

### What is OpenAI Presence?

OpenAI Presence is a deployed enterprise product for voice and chat agents. It combines job-scoped company knowledge and system access with policies, guardrails, approved actions, simulations, evaluations, escalation rules, production feedback, and a controlled Codex-powered improvement process.

### Is OpenAI Presence generally available?

It is available to eligible enterprise customers through a limited general availability program as of July 22, 2026. OpenAI says deployments are led by Forward Deployed Engineers and select global systems integrators; Presence is not a self-serve product.

### How much does OpenAI Presence cost?

OpenAI had not published Presence pricing as of July 22, 2026. The announcement also does not publish a billing unit, minimum commitment, implementation fee, support tier, or contract term. Buyers need a scoped commercial proposal from their OpenAI account team.

### Does OpenAI Presence have a public API?

OpenAI does not document a self-serve Presence API, endpoint, SDK, or model ID in the launch material. OpenAI separately says it will continue supporting voice customers through the OpenAI API, which is a build-your-own path rather than proof of a public Presence API.

### What results has OpenAI reported for Presence?

OpenAI reports that Presence resolves 75% of inbound issues without human assistance in its English-language phone-support channel and that its launch team reduced human handoffs by 15 percentage points in 10 days. These are vendor-reported results from OpenAI's own deployment, not general benchmarks or independently reproduced outcomes.

### What should an enterprise test before deploying Presence?

Test policy adherence, identity verification, tool authorization, action correctness, escalation quality, voice and chat behavior, recovery from system failures, audit evidence, rollback, privacy boundaries, and performance on real traffic distributions. Set pass thresholds and stop conditions before exposing the agent to production users.


---

[Join the Agentpedia newsletter](https://agentpedia.codes/blog)

[Browse related Agentpedia articles](https://agentpedia.codes/blog)

## Official sources

### Presence launch and availability

- [Introducing OpenAI Presence](https://openai.com/index/introducing-openai-presence/) -- product components, deployment model, supported channels, customer examples, OpenAI's internal support results, and limited-GA availability
- [OpenAI Presence product page](https://openai.com/business/openai-presence/) -- official product overview, governed improvement model, use cases, and FDE/partner deployment path
- [OpenAI's Presence announcement on X](https://x.com/OpenAI/status/2079916436232036614) -- official launch summary and eligibility wording
- [OpenAI sales contact form](https://openai.com/contact-sales/) -- public contact path for organizations without an established account-team route

### Adjacent official OpenAI guidance

- [OpenAI API voice agents guide](https://developers.openai.com/api/docs/guides/voice-agents) -- build-your-own voice architecture choices, tools, handoffs, guardrails, approvals, and observability
- [Realtime and audio overview](https://developers.openai.com/api/docs/guides/realtime) -- current API path for low-latency voice applications; this is not Presence documentation
- [Business data privacy, security, and compliance](https://openai.com/business-data/) -- published commitments for the products named on that page; buyers should confirm their exact application to Presence


---

- [All articles](https://agentpedia.codes/blog)