OpenAI has introduced Presence, a limited-availability enterprise product that packages agent deployment, permissions, simulation, evaluation and controlled updates into a managed production service.
The new service targets voice and chat workflows where an AI agent must use company systems, follow operating policies and hand work to a person when necessary. For platform teams, the notable shift is from model access to an opinionated operating model for agents in production.
NEW DELHI, July 23, 2026, 10:15 p.m. IST — OpenAI is moving deeper into the operational layer of enterprise AI with Presence, a product designed to help companies deploy narrowly scoped voice and chat agents and improve them after launch without giving up approval control.
The company said Presence combines policies, guardrails, approved actions, simulations, evaluation tools and a Codex-powered improvement process. It is available now to eligible enterprise customers through a limited general availability program, but it is not a self-service product. OpenAI Forward Deployed Engineers and selected systems integrators lead deployments.
That boundary matters. Presence is not simply a new general-purpose model or an API feature that developers can switch on. It is a managed deployment approach for high-value workflows such as billing support, insurance claims and employee IT service requests. The announcement reflects a broader industry move from agent demos toward the less glamorous work of permissions, testing, escalation and change management.
What OpenAI confirmed
Each Presence deployment begins with a specific job. According to OpenAI’s announcement, the agent receives only the knowledge and system access required for that task. The customer defines what the agent may do, which actions need approval and when a human must take over.
Before launch, teams can run simulations covering routine requests, edge cases and higher-risk scenarios. Graders evaluate whether the agent reached the intended outcome, followed policy, selected the correct tools and escalated appropriately. Guardrails can intervene when an interaction crosses a company-defined boundary.
After launch, Presence uses production sessions, escalations and quality signals to identify gaps. OpenAI says Codex can investigate those signals and propose changes. Teams can test a proposed update against the deployed version and approve a controlled rollout. The company’s description places human approval between a generated recommendation and a production change; it does not describe an agent that rewrites and deploys itself without review.
SiliconANGLE’s coverage independently confirms the product’s narrow-task design, simulation tooling, guardrails and limited rollout. It also notes that telemetry from support interactions could help engineering teams identify recurring product problems, although using that data well will still depend on retention, privacy and access policies set by the customer.
OpenAI cites its own support operation
OpenAI said Presence powers its English-language phone-support channel and currently resolves 75% of inbound issues without human assistance. The company also said a Codex-powered improvement loop reduced human handoffs by 15 percentage points in 10 days.
Those are vendor-reported operational results, not an independent benchmark, and the announcement does not publish the underlying workload mix, severity distribution or evaluation methodology. Teams should therefore treat the figures as a deployment example rather than a forecast for their own service desks.
BBVA is exploring voice support for banking customers in Mexico, SoftBank is testing Japanese-language customer conversations, and IAG is exploring support during high-demand events such as severe weather, according to OpenAI. The wording is important: the companies are described as exploring or testing the product, not as evidence of a broad completed rollout.
Why platform and DevOps teams should pay attention
Presence turns agent reliability into an ongoing operations problem. That will be familiar to teams already responsible for service ownership, but agent systems introduce additional failure modes: a tool may return valid data that the agent uses incorrectly, a policy may change faster than a prompt, or a seemingly successful conversation may conceal an unsafe action.
For developers and platform engineers, the useful design signal is the separation of production evidence, candidate changes, test environments and approved rollouts. The pattern resembles mature software delivery: observe real behavior, propose a change, validate it against representative cases, require approval and release gradually. GravityDevOps readers building their own systems can apply the same discipline even without Presence by treating prompts and policies as versioned artifacts, keeping tool permissions narrow and adding rollback criteria to agent releases.
Observability will also need to go beyond latency, token use and HTTP errors. Teams should track task outcome, policy compliance, tool selection, escalation quality and the rate at which humans reverse an agent’s actions. A high automation rate is not a success metric if it is achieved by suppressing necessary escalations.
Organizations already working on retrieval-grounded applications should connect the announcement to their existing data controls. A retrieval-augmented generation architecture can improve access to current internal knowledge, but it does not by itself decide what an agent may change. That requires authorization at the tool and action layer. Similarly, the deployment and monitoring practices covered in GravityDevOps’ LLMOps guide remain relevant, but action-taking agents add approval, audit and compensation workflows to the operational checklist.
What remains uncertain
OpenAI has not announced public pricing, a self-service release date or detailed service-level commitments for Presence. It also has not published a complete technical architecture, supported connector catalog or customer-controlled deployment model. API customers can continue building voice applications with OpenAI’s frontier models, but Presence itself is being sold as a deployed enterprise product.
That leaves an important build-versus-buy question. A managed service may shorten the path to production for companies with suitable workflows and access to OpenAI’s deployment team. It may be less attractive for organizations that require full infrastructure control, portability across model providers or highly customized approval systems.
The balanced takeaway is that Presence does not eliminate agent operations; it productizes a particular version of them. Technical leaders evaluating it should ask for evidence on their own task distribution, define unacceptable failure classes before a pilot, verify how production traces are handled, and insist on exportable audit records and rollback procedures. For teams comparing development approaches, GravityDevOps’ overview of prompt engineering for developers provides useful background, but production approval and access control must sit outside the prompt itself.
Sources
This report is based on OpenAI’s product announcement, the company’s newsroom listing, and SiliconANGLE’s independent report.
