OpenAI Presence Is a Managed Agent Deployment, Not a Self-Serve Tool
OpenAI Presence bundles policies, simulations, approved actions, human escalation, and a Codex improvement loop. Who should buy it, and who should build?
OpenAI says Presence now resolves 75% of inbound issues on its English-language phone-support line without human assistance, and its improvement loop cut handoffs by 15 percentage points in 10 days. The product behind those numbers is not an agent builder you can sign up for. It is a managed enterprise deployment that bundles the agent, policies, evaluations, systems integration, and ongoing operational work.
The verdict: Presence sells the deployment, not the model
OpenAI Presence is worth considering when a customer-facing voice or chat workflow must take real actions under strict policy, and the buyer wants OpenAI to share the deployment burden. It is the wrong starting point for a small team looking for a self-serve agent builder, a developer looking for an SDK, or an enterprise that has not yet chosen one narrow workflow to own.
The launch terms are unusually revealing: Presence is available only to eligible enterprise customers through limited general availability. OpenAI Forward Deployed Engineers and selected global systems integrators lead deployments, and OpenAI explicitly says the product is not self-serve. No public list price appears on the launch page or the current Frontier page.
That makes the delivery model the product. A frontier model can already interpret a support request. The difficult part is giving it the correct account context, limiting its permissions, enforcing a refund policy, validating its action, deciding when approval is mandatory, routing a risky case to a person, and updating the system without breaking yesterday's behavior. Presence packages those jobs into one managed engagement.
What Presence actually contains
Presence is a production wrapper around one defined job, not a general digital employee. Each deployment starts with a specific workflow. The agent receives only the knowledge and system access needed for that job, while the customer defines its policies, approval points, and human handoff rules.
The word guardrail can sound like a filter placed after a model response. Here it means a wider control system: rules that constrain inputs, tools, actions, permissions, and escalation. Presence combines policies and standard operating procedures, guardrails, approved actions, simulations, evaluation tools, and a Codex-powered improvement process.
Scope one job
Pick a complete outcome such as resolving a billing issue, supporting an insurance claim, or handling an employee IT request. A broad instruction like "help every customer" cannot produce a useful evaluation set or a defensible permission boundary.
Limit context and access
Connect only the records and systems that job requires. A billing agent may need identity, account, invoice, and payment context. It does not need unrestricted access to the entire customer data estate.
Encode policy and approvals
Define what the agent may answer, which actions it may take, when it must ask for approval, and when a person takes over. A correct sentence paired with an unauthorized action is still a production failure.
Simulate before launch
Run common requests, edge cases, and higher-risk scenarios through graders. OpenAI says the checks cover outcome quality, policy compliance, tool use, and escalation behavior.
Improve under change control
Production sessions, escalations, and quality signals expose gaps. Codex investigates those signals and proposes updates that a team can test against the production version before approving a controlled rollout.
The loop matters more than the demo. A voice agent may sound natural on launch day and still fail when a product changes, a new refund exception appears, or callers learn how to phrase requests the original test set missed. Presence treats production behavior as a source of proposed changes, then puts testing and approval between the proposal and the live system.
For a customer-support leader, that is the practical distinction between a chatbot and an operating system for a workflow. The chatbot answers. The production agent verifies, decides, acts within authority, records what happened, and hands off when the risk exceeds that authority.
The proof is promising, but narrow
The launch evidence proves that Presence can run a real support channel, but it does not yet prove a general enterprise return. OpenAI reports the results from its own English-language phone-support line at 1-888-GPT-0090, so the numbers are useful product evidence and vendor-reported evidence at the same time.
The design-partner list is earlier-stage. BBVA is exploring voice support for everyday banking needs in Mexico. SoftBank is testing natural Japanese-language customer conversations. IAG is exploring help during high-demand events such as severe weather. Those programs show breadth across language and regulated workflows, but OpenAI does not present them as equivalent production outcomes.
The launch also omits the numbers a procurement team needs: public pricing, implementation timeline, minimum volume, support model, error rates by action, and cost per correctly resolved contact. Limited general availability makes that understandable, but it means no credible public cost comparison exists yet. A buyer should treat any precise ROI claim without a contract and workflow baseline as fiction.
Presence fits one layer of OpenAI's agent stack
Presence is the managed-workflow route inside a product family that also includes ChatGPT Workspace Agents, the OpenAI Agents SDK, and Frontier. Treating those names as interchangeable creates a bad buying process because each puts ownership in a different place.
ChatGPT Workspace Agents: internal repeatable work
ChatGPT Workspace Agents are the lighter route for repeatable work that already lives inside a Business or Enterprise workspace. A builder can choose a model and reasoning effort, connect apps and tools, publish the agent to colleagues, use it in Slack, schedule it, or trigger it through an API.
The controls are meaningful but the execution boundary is narrower. Write actions for apps and connectors default to Always ask. Connector Action Constraints can restrict what an integration may do, although OpenAI notes that those constraints do not filter the data a connector returns. Files are limited to 512 MB each and 10 GB total per agent.
The decisive API limitation is operational: a trigger queues a run and returns 202 Accepted with no response body. It does not return a run ID, and the response cannot currently be retrieved through that API. That can work for fire-and-forget internal tasks. It is a poor contract for a customer-facing product that needs synchronous status, retry logic, and a traceable result.
OpenAI Agents SDK: custom product ownership
The OpenAI Agents SDK route fits a company that wants the agent inside its own product or infrastructure. OpenAI's agent-building guide reduces the architecture to three core components: a model that reasons, tools that read or act, and instructions that define behavior.
Those components are only the center of the system. The builder still owns identity, authorization, tool contracts, evaluation data, monitoring, fallback behavior, incident response, and cost. OpenAI recommends starting with the strongest model to establish an evaluation baseline, then replacing it with smaller models where accuracy remains acceptable. It also recommends maximizing one agent before adding a multi-agent architecture.
The custom route is the right call when the workflow differentiates the product, when deployment constraints are unusual, or when the business needs to tune model and tool costs at a granular level. If vendor portability matters, the abstraction has to be designed above any one provider's SDK. Merely choosing an SDK does not create portability.
OpenAI Frontier: the organization-wide platform
OpenAI Frontier is the broad platform route for companies operating many agents across departments and systems. Its published layers are Business Context, Agent Execution, evaluation and optimization, and enterprise security and governance.
Frontier is designed to govern customer-built agents, OpenAI agents, and third-party agents on one platform. OpenAI describes agent identity and access management, explicit permissions, auditable actions, monitoring, and detailed logs. Its Enterprise Frontier Program also pairs forward-deployed engineers with the customer to design architecture, operationalize governance, and run agents in production.
The practical product map is simple: Workspace Agents package an internal agent experience, the SDK packages building blocks, Presence packages a deployed workflow, and Frontier packages the enterprise control plane. OpenAI has not published a public contract map that explains which Frontier components come with a Presence engagement, so buyers should ask rather than infer.
For a broader market view beyond OpenAI, compare the enterprise platforms and operating tradeoffs in the best AI agents for 2026.
Who should buy Presence, and who should build
Buy Presence when the workflow is narrow, valuable, action-oriented, and expensive to get wrong. Build when the agent is strategic intellectual property, the operating constraints are unusual, or long-term control matters more than a managed path to production.
Presence is especially credible for a policy-heavy service flow. Consider an insurer handling claim-status calls during severe weather. The agent has to identify the caller, retrieve the correct policy and claim, separate a status question from a request to change something, act only within authority, and hand the case to a person when risk rises. Natural language is only one piece. Access and escalation decide whether the workflow is safe.
A custom build wins when the agent itself creates competitive advantage. A vertical software company may need proprietary tools, a domain-specific evaluation set, a distinct user experience, support for several model providers, or deployment in an environment a managed service cannot match. In that case, outsourcing the operating loop can also outsource learning that should remain inside the product team.
The operator lens changes the answer. A mid-market CTO with a policy-heavy support queue and no appetite to assemble a permanent agent-operations function has a credible reason to pilot Presence. A funded founder whose product is the agent should usually own the architecture and evaluation data. A senior operator automating internal approvals should start with Workspace Agents or a deterministic workflow. A solo technical builder is better served by the SDK route because Presence is neither self-serve nor designed as a lightweight experiment.
Do not build an agent simply because an LLM can interpret the input. If a rules engine can make the decision reliably and the language layer only collects structured fields, keep the decision deterministic. Put probabilistic reasoning only where ambiguity genuinely requires it.
Demand a workflow scorecard before signing
The pilot should be judged on correct outcomes and controlled failure, not on how human the conversation sounds. The 75% resolution figure is a useful headline, but your contract needs definitions that survive contact with finance, risk, and operations.
Track at least these measures:
- Correct resolution rate: the share of eligible contacts completed accurately, not merely closed without a person.
- False resolution rate: contacts marked complete despite a wrong answer, wrong action, or unresolved need.
- Policy compliance: whether the agent followed the rule and approval path that applied at the time.
- Tool execution quality: whether reads and writes targeted the correct record, used the correct parameters, and produced the intended state change.
- Escalation quality: whether risky or uncertain cases reached the right person with the context needed to continue.
- Cost per correctly resolved contact: contract, model, integration, review, and support cost divided by verified successful outcomes.
- Latency and abandonment: how response time behaves under normal and peak demand, and whether callers leave before resolution.
- Change safety: whether a proposed policy or prompt update improves the target cases without regressing established ones.
The denominator matters. A system can improve containment by taking on easy requests while escalating anything costly. It can also inflate resolution by closing conversations that later reopen. Segment results by intent, action type, risk class, language, and channel so the aggregate cannot hide the expensive failures.
Choose one complete outcome
Define the job in business terms, including where it starts, what a correct finish looks like, which actions it may take, and what must always go to a person.
Build the evaluation set
Use real policy documents and sanitized historical patterns to cover normal requests, ambiguity, missing information, adversarial wording, changed policies, and high-risk edge cases.
Set the authority matrix
List every tool action and classify it by reversibility, permission, financial impact, and customer harm. Keep high-risk or irreversible actions behind human oversight until the evidence supports a wider boundary.
Run beside the current process
Compare proposed answers, actions, and escalations with the current operation before allowing the agent to change live records. Investigate disagreement rather than averaging it away.
Expand by verified intent
Move proven request types into production in controlled groups. Keep an immediate rollback path and require regression tests before policy, tool, or instruction changes ship.
The buyer should also settle ownership before launch. Someone must approve policy changes, review incidents, maintain integrations, own the evaluation set, and decide when the agent's authority expands. Presence can supply technology and deployment expertise. It cannot remove the company's accountability for the workflow.
The strategic take
OpenAI Presence matters because it moves the enterprise-agent sale from model access to operational accountability. The promise is no longer "use our intelligence." It is "let us help run a governed workflow and improve it after launch."
That is a stronger product shape than another general agent builder. It also creates deeper dependency on OpenAI's deployment team, models, improvement process, and contract. The trade is rational when managed speed and shared operating expertise beat the value of owning the system. It is expensive dependence when the workflow should become proprietary capability.
The sharp buying question is therefore not whether Presence sounds intelligent. Ask who owns the outcome, who controls each action, who proves an update is safe, and who carries the workflow when the agent fails. If the contract answers those questions and the pilot proves the economics, Presence can shorten the hardest part of enterprise agent adoption. If it does not, build a narrower system you can measure and own.
Is OpenAI Presence available as a self-service product?
No. OpenAI says Presence is available to eligible enterprise customers through limited general availability. Forward Deployed Engineers and selected global systems integrators lead deployments, and the launch page directs buyers to their OpenAI account team.
How is OpenAI Presence different from ChatGPT Workspace Agents?
Workspace Agents are shared agents built inside ChatGPT for repeatable tasks, with apps, tools, Slack, schedules, and API triggers. Presence is a managed production deployment for real-time voice and chat workflows that use company systems, take governed actions, and escalate to people.
Does OpenAI publish Presence pricing?
No public list price appears on the July 22, 2026 launch page or the current Frontier product page. A useful quote must be tied to one defined workflow, its volume, integration scope, support model, and measurable success criteria.
Should an enterprise buy Presence or build its own agent?
Buy when one policy-heavy voice or chat workflow needs managed deployment and the company accepts OpenAI as a deep operating partner. Build when the agent differentiates the product, architecture control is strategic, deployment constraints are unusual, or model portability and unit economics outweigh managed speed.
If you are deciding whether to buy a managed agent or own the system, map the workflow and risk boundary before you build.
Jul 22, 2026
