OpenAI Presence: Enterprise Agents Guide

OpenAI introduced Presence on July 22, 2026 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

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:

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.

OpenAI directs interested organizations to their account team. Organizations without that relationship can use the official sales contact form, 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.

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.

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.

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 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:

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.

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 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.

For a broader lesson on containing high-capability evaluations and preserving authorization boundaries, see AgentPedia's OpenAI–Hugging Face security incident analysis. 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 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.

Teams choosing the API route can use the OpenAI Agents Python guide for orchestration concepts and the 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.

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.

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.

Official sources

Presence launch and availability

• Introducing OpenAI Presence — product components, deployment model, supported channels, customer examples, OpenAI's internal support results, and limited-GA availability
• OpenAI Presence product page — official product overview, governed improvement model, use cases, and FDE/partner deployment path
• OpenAI's Presence announcement on X — official launch summary and eligibility wording
• OpenAI sales contact form — public contact path for organizations without an established account-team route

Adjacent official OpenAI guidance

• OpenAI API voice agents guide — build-your-own voice architecture choices, tools, handoffs, guardrails, approvals, and observability
• Realtime and audio overview — current API path for low-latency voice applications; this is not Presence documentation
• Business data privacy, security, and compliance — published commitments for the products named on that page; buyers should confirm their exact application to Presence