OpenAI Presence is a vendor-led enterprise agent deployment

OpenAI Presence, introduced on July 22, 2026, is an enterprise deployment product for real-time voice and chat agents. Eligible customers do not simply switch it on: OpenAI Forward Deployed Engineers and selected global systems integrators lead the work of connecting company systems, setting controls, testing behavior, and moving the agent into production.

That delivery model changes the buying decision. A company considering Presence is choosing whether a valuable, risky workflow warrants an embedded vendor deployment, along with the access and dependency that creates. The useful comparison is therefore wider than Presence versus an existing model or API: it includes the buyer’s current integrations, policies, evaluations, escalation process, and ability to maintain the workflow after launch.

Presence packages the work around a voice or chat agent

OpenAI’s announcement names customer support, outbound sales, and high-risk internal workflows as current examples. Each deployment starts with a specific job. The customer defines the knowledge and system access required for that job, what the agent may do, which actions need approval, and when a person should take over.

Presence then packages much of the deployment work needed to make those decisions executable. OpenAI and its partners connect knowledge and business systems, implement the customer’s permissions, policies, and approved actions, and test the agent before production. Simulations and evaluation tools check whether the agent reached the intended outcome, followed policy, used tools correctly, and escalated when required. Guardrails can intervene when an interaction leaves the company’s defined boundaries.

The product also includes a controlled way to change the agent after launch. Production sessions, escalations, and other quality signals expose gaps; Codex proposes updates; teams test those proposals against the production version and approve a controlled rollout. This is a reviewed software-change process, not autonomous retraining.

Those pieces are the substance of the offer. The model supplies reasoning and conversation, while the deployed product includes integration labor, access rules, standard operating procedures, simulations, evaluations, approved actions, escalation, and ongoing change control. For a buyer, the value should be assessed against the cost and difficulty of building and operating that whole system with the current voice or chat stack.

Limited general availability creates a continuing vendor dependency

Presence is available to eligible enterprise customers through a limited general availability program. It is not self-serve, and OpenAI says its Forward Deployed Engineers and selected global systems integrators lead deployments. Existing voice customers can still use OpenAI’s frontier models through the API, but API access does not include the same embedded deployment product.

That distinction affects both access and responsibility. OpenAI or an integrator may lead implementation, yet the customer still has to define the job, grant access, supply policies, approve actions, review proposed changes, and receive escalations. The outside team can accelerate the build and contribute specialized experience. It cannot decide which exception is acceptable for the business or make the internal support, sales, risk, security, and compliance teams agree on how the workflow should run.

The arrangement also makes vendor dependence part of the purchase. The announcement does not say how eligibility is decided, how long deployment takes, or which responsibilities belong to OpenAI, the integrator, and the customer when an error or incident occurs. Buyers evaluating the embedded-team model may find the related analysis of AWS forward-deployed engineering useful, especially where internal teams must maintain tests, permissions, and recovery procedures after the initial build.

Several other procurement facts remain undisclosed in the announcement: pricing, minimum commitment, model choice or pinning, integration requirements, evaluation methods, portability, and the full responsibility split. OpenAI says generalized insights from every deployment inform its research and product development, but it does not explain what those insights contain or the contractual controls on their use. Buyers need those details to approve access, estimate total cost, compare alternatives, respond to failures, and understand what leaving would require.

OpenAI’s support results show promise within one vendor-run channel

OpenAI reports that its own English-language phone support channel using Presence resolves 75% of inbound issues without human assistance. The company also says human handoffs fell by 15 percentage points in ten days while its launch team used the Codex-powered improvement process. Both figures are vendor-reported and apply only to OpenAI’s own English-language phone-support channel.

These figures establish that Presence is handling live work in at least one bounded setting and that OpenAI observed a rapid change in handoff rate during a stated ten-day interval. They do not establish that another company will resolve the same share of issues, reduce cost, improve satisfaction, or avoid severe errors. OpenAI has not published the sample size, issue mix, baseline rates, customer satisfaction, error severity, or an independent audit. The announcement also omits the starting and ending handoff rates, so the 15-point change cannot show the absolute level of human involvement.

Human assistance is also an incomplete quality measure. A low handoff rate can mean that the agent resolved more work correctly, or that it retained work a person should have received. Teams need to examine the quality of what reaches people, including whether the escalation preserves enough context for the next person to act. BaristaLabs’ earlier analysis of support AI escalation quality explains why deflection and handoff counts need evidence from the human side of the queue.

The named customer activity does not add measured outcome evidence yet. BBVA is exploring Presence, SoftBank is testing it, and IAG is exploring it. Those statements show interest and early work; the announcement does not describe completed rollouts or quantified results from any of the three companies.

Presence makes sense when the workflow merits an embedded deployment

Presence is easier to justify when one voice or chat workflow has high enough value or risk to support sustained work by the vendor, an integrator, and the customer. The job should already be specific, its inputs and actions understood, and its performance measurable in business and customer terms. The customer also needs people who can make policy decisions, approve access, review exceptions, test changes, and operate the human path when the agent stops.

In that situation, the vendor-led model can compress work that would otherwise span conversation design, system integration, evaluation, security review, escalation design, and production maintenance. The purchase is rational when that acceleration and specialist help are worth more than the resulting coordination cost and dependence. A fluent demo alone does not meet that threshold.

Improve the existing stack first when the work itself is unclear

An existing voice or chat stack is the better starting point when the team cannot yet name the job precisely, identify reliable data, assign a decision owner, or define a useful measure of success. Those gaps will follow the workflow into Presence. An embedded team may help expose them, but limited availability and vendor-led coordination are a costly way to discover that the organization has not agreed on what the agent should do.

Many apparent model problems are local process problems: stale knowledge, weak routing, broad permissions, missing approval rules, poor escalation context, or a metric that rewards closed conversations without checking outcomes. Improving those parts of the current stack can reveal whether a new deployed product is needed. It also gives the buyer a clearer baseline for judging any later Presence proposal.

Wait when the commercial and data terms block a responsible decision

A buyer should wait when unanswered terms prevent a meaningful comparison or approval. Data retention and use, model selection and pinning, audit access, integration obligations, incident responsibility, deployment lead time, minimum commitment, and exit portability can change the risk and economics of the product. The announcement does not provide them, so the OpenAI account team and proposed integrator would need to answer them for a particular customer.

Waiting in this case is a procurement decision, not a verdict on the technology. The product may fit the workflow technically while remaining impossible to approve or compare commercially. Until required terms are concrete, projected automation rates cannot resolve the purchase.

OpenAI is selling a deployed voice-and-chat system plus the people and process needed to put it into production. Presence is worth buying when a defined, measurable workflow has enough value or risk to justify embedded delivery and the customer can still make the local decisions the vendor cannot make. Improve the current stack when the job, data, owner, or measurement remains unclear; wait when essential commercial, data, and portability terms are unresolved.

Sources

• OpenAI, “Introducing OpenAI Presence,” July 22, 2026