OpenAI Presence for enterprise agents: limited GA, managed deployment, and the questions buyers still own

What happened

OpenAI announced Presence on July 22, 2026. The announcement describes it as a managed enterprise product for deploying and continuously improving governed AI agents in customer-facing and internal workflows. The event is 14 calendar days old as of August 5, 2026, so it remains inside this publication’s 90-day News window.

The commercial boundary matters more than a generic agent-platform label. OpenAI says Presence is available to eligible enterprise customers through a limited general availability program as a deployed product. Deployments are led by OpenAI Forward Deployed Engineers and selected global systems integrators. The same announcement says Presence is not self-serve. An organization cannot responsibly translate a public product page into a claim that any employee can create, configure, or purchase a Presence agent from a console.

The current Help Center material adds the operating frame: Presence combines OpenAI models with policy and permission definition, connections to business systems, behavior testing, production monitoring, and involvement of people when human judgment is required. It presents customer support and voice as early use cases while allowing both customer-facing and internal workflows. The exact capabilities, integrations, models, data-handling terms, capacity, price, and service commitments remain deployment-specific.

Confirmed facts

OpenAI documents voice and chat as the supported conversational channels during limited GA. It describes an agent that can follow approved instructions and organizational policies, use approved knowledge and business-system tools with scoped permissions, retrieve information, update systems, complete approved actions, and hand work to a person or another support path where policy, risk, or workflow requires judgment. These are configurable product capabilities, not proof that every deployment should receive every permission.

The announced operating model includes pre-launch simulations, evaluations, acceptance testing, guardrails, defined permissions, controlled rollout, production monitoring, and tested improvements. Those ingredients are meaningful because they place change management around a production workflow rather than treating a new model prompt as a complete operating process. They still leave the customer and deployment team to specify source data, approval boundaries, record retention, escalation ownership, failure recovery, and the tests that determine whether a change is accepted.

OpenAI also publishes an example of its own English-language AI phone support using Presence. In the launch announcement, OpenAI reports that this service resolved 75% of inbound issues without human assistance and that a Codex-powered improvement loop reduced human handoffs by 15 percentage points in ten days. Those are official OpenAI examples and metrics for that named service; they are not an independent benchmark, a promised outcome, or a forecast for another enterprise. The separate phone-support article documents its own limitation: the phone agent cannot submit reports or requests, initiate an escalation or account review, connect the caller to a live agent, or guarantee a follow-up.

The documented availability boundary is equally specific. Limited GA is not full general availability, a free trial, a public API entitlement, or self-service workspace access. Contacting an OpenAI account representative begins an eligibility and fit discussion; it does not by itself confirm capacity, region, integration feasibility, commercial terms, or launch approval. OpenAI’s current support documentation states that exact data handling, retention, storage location, access, pricing, and service commitments are set for each deployment. No public list reviewed for this article establishes a standard Presence price, a universal region catalog, or a universal service-level agreement.

What is not confirmed

The public material does not define a common integration catalog, a maximum transaction volume, an uptime objective, a named data-residency matrix, a standard retention period, a fixed implementation duration, or a shared price card. It also does not establish that a particular organization can connect its contact center, identity provider, knowledge systems, or action tools in the intended way. Those conditions require technical scoping and commercial confirmation for the proposed deployment.

Presence’s policy, evaluation, and guardrail language should not be treated as evidence that a customer has enabled those controls correctly. A policy exists only as a local control when its owner, scope, evidence, exception path, and test record are known. Likewise, a documented ability to make an approved update is not authority to issue refunds, alter customer records, grant access, or make another high-impact change without the customer’s designated controls.

The customer names and quotations in the announcement are OpenAI-published partner evidence. BBVA, SoftBank, and IAG are described as exploring or testing particular voice-support directions. Their statements are useful context about intended use cases, but they do not establish independent production reliability, security posture, regulatory approval, financial return, or readiness in another sector. The public record also does not establish a comparative advantage over a self-built agent, a contact-center vendor, or an alternative managed agent service.

Editorial interpretation

Presence changes the question for a qualified buyer from “can we assemble an agent?” to “can a managed deployment prove this one workflow inside our operating boundary?” That is a useful shift for a high-volume, repeatable, high-stakes conversation flow. OpenAI is explicitly packaging deployment support and an improvement process around the model layer, not merely exposing a generic model endpoint.

It is nevertheless a deployment decision, not a shortcut around governance. The safest initial job is a bounded voice or chat workflow with a known source of truth, narrow permissions, reversible outcomes, a visible human handoff, and a reviewable definition of success. The enterprise AI assistant buyer’s guide can help teams express those gates before an implementation conversation; it is particularly useful for separating documented vendor capability from customer-operated control.

The limited-GA label adds a procurement implication. A buyer should retain an explicit alternative path if eligibility, delivery capacity, price, region, implementation timing, or integration scope does not fit. Treat an account-team conversation as discovery, not a commitment from either side. An internal sponsor should avoid promising a launch date before the deployment has defined its exact channel, authentication, data handling, service terms, support model, and acceptance criteria.

Decision implications

For customer operations, the key decision is whether the proposed workflow can be decomposed into safe actions and explicit escalation conditions. A resolution agent may need to identify a caller, inspect account context, apply a narrow policy, and then hand off uncertain or high-risk cases. Those steps should retain the organization’s own decision authority. The agent-ready application assessment guide offers a way to assess the systems an agent would need to reach before allowing the workflow to make changes.

For security and privacy teams, examine identity and data paths before discussing response quality. Identify what the agent can read, what data is logged, what is masked or removed, where it is stored, who can access it, which tools can write, and how every permission is withdrawn. Require a dedicated test identity and a non-production environment for early testing. A product’s ability to use scoped permissions does not establish that connected systems themselves enforce least privilege.

For platform and engineering teams, frame each integration as a contract. Define the request and response schema, authorization subject, idempotency behavior, timeout, retry rule, audit event, human handoff payload, and recovery procedure. The agent workflow guide helps turn these into an observable flow rather than an implicit sequence inside a conversational demo. For tools that use Model Context Protocol, the MCP security checklist is a separate control review; a managed agent deployment does not make an MCP server or tool response trustworthy by default.

For procurement, request a deployment-specific written record of feature scope, commercial model, support responsibilities, delivery capacity, data treatment, retention, relevant region, and exit or transition terms. The public source record supports asking those questions; it does not answer them for a particular buyer. Include implementation and operator work in the economic case, rather than comparing an assumed subscription price with the cost of an existing support team.

What teams should verify next

1. Select one repeatable voice or chat job and write the allowed data, source systems, permitted actions, human-handoff triggers, and unacceptable outcomes.
2. Ask OpenAI to confirm limited-GA eligibility, workflow fit, delivery capacity, supported channel, integration approach, region, pricing, data handling, and service commitments for that job.
3. Test identity, authorization, knowledge retrieval, tool responses, policy refusal, human handoff, auditing, and recovery with test data before connecting production systems.
4. Build evaluation cases for normal requests, ambiguous cases, stale account data, an unavailable dependency, an unauthorized action, a policy conflict, and a case requiring escalation.
5. Record human review time, verified completion, unsupported conclusions, policy exceptions, failed handoffs, tool errors, and cost per accepted outcome; do not reuse OpenAI’s published internal-support metrics as local targets.
6. Define an operator-owned fallback queue and a way to suspend permissions or traffic without losing the evidence needed to investigate the run.

The appropriate directory next step is the ToolVerse AI automation category, which is a discovery surface for adjacent automation options rather than a statement that any listed tool is equivalent to Presence. The decision to make now is narrower: whether a managed, limited-GA deployment can demonstrate a controlled outcome for one workflow under the buyer’s own authority, evidence, and recovery requirements.

Sources and verification note

All four first-party source URLs in the frontmatter were publicly accessible and rechecked on August 5, 2026. The July 22 announcement establishes the event date, limited-GA deployed-product status, non-self-service boundary, documented operating elements, and OpenAI-published examples. The current Help Center and business material establish the managed-deployment, supported-channel, deployment-specific feature, pricing, data, and service-commitment boundaries. The AI phone-support article identifies its use of Presence and the stated limits of that particular support channel.

This brief makes no hands-on, deployment, benchmark, security-assessment, or independent customer-outcome claim. Editorial interpretation is deliberately separated above from OpenAI’s documented product description and examples. Recheck availability, delivery capacity, exact feature scope, pricing, terms, data handling, and service commitments immediately before entering procurement or production planning.