OpenAI launched Presence on July 22, 2026 as a managed enterprise product for deploying voice and chat agents that can answer questions, use company systems, take approved actions, and hand work to people when needed.
The important question is not whether an AI agent can hold a convincing conversation. It is whether your support workflow is narrow enough, measurable enough, and controlled enough to let software act on a customer’s account.
For most companies, the sensible first step is not “automate customer support.” It is one tightly bounded job with clear permissions, pass-or-fail evidence, and an obvious human escape route.
Product check: Presence details and availability were checked on July 28, 2026. OpenAI says the product is available to eligible enterprise customers through a limited general-availability programme, led by OpenAI Forward Deployed Engineers and selected systems integrators. It is not currently a self-serve product.
What OpenAI Presence Actually Changes
Presence is not presented as a better FAQ chatbot. OpenAI describes a production system that combines model reasoning with:
- company policies and standard operating procedures;
- access to approved knowledge and business systems;
- guardrails and permission boundaries;
- simulations and evaluations before launch;
- rules for approval and human escalation;
- monitoring and an improvement process after launch.
That packaging matters because the difficult part of an agent is rarely producing a fluent answer. The difficult part is deciding what the agent may do, proving that it did the right thing, and recovering safely when it did not.
OpenAI says Presence currently supports real-time voice and chat workflows such as customer support, outbound sales, and higher-risk internal service requests. Because it is a managed enterprise deployment rather than a self-serve tool, smaller teams should treat the launch as a useful design signal—not as a product they can casually switch on tomorrow.
Gate 1: Give the Agent One Job With a Clear Finish Line
A weak starting point is:
Handle customer support.
A stronger starting point is:
Help an authenticated customer understand the status of one existing order, using read-only account access, and escalate when delivery data is incomplete or disputed.
The second version defines:
- who the user is;
- which system the agent may consult;
- what outcome counts as complete;
- what the agent must not change;
- when a person takes over.
Before building anything, write the workflow as a short sequence of observable steps. When the team cannot agree on where the task starts and ends, the agent will inherit that ambiguity.
Pass this gate when: two people can independently read the workflow and agree on what a successful resolution looks like.
Fail this gate when: the proposed job contains broad goals such as “keep customers happy,” “solve anything,” or “use good judgment” without operational rules.
Gate 2: Start With the Minimum Permission—and Prefer Reversible Actions
A support agent does not need access to every customer field merely because the data exists.
Begin with the smallest useful permission set:
- read the minimum account information required for the task;
- draft an action before executing it;
- require approval for sensitive or expensive changes;
- place hard limits on values such as refunds, credits, cancellations, or account modifications;
- log the information used and the action taken.
Read-only workflows are usually easier first pilots than workflows that can change money, access, bookings, subscriptions, or legal status. When write access is necessary, favour actions that can be reversed and make the reversal procedure part of the design.
OpenAI’s agent-building guidance recommends assessing tools by risk, including whether access is read-only or write-enabled, whether an action is reversible, and whether it carries financial or permission consequences.
Pass this gate when: every available tool has a clear purpose, permission boundary, and approval rule.
Fail this gate when: the agent receives broad administrator access because restricting it would take extra engineering work.
Gate 3: Write the Escalation Policy Before the Happy Path
A human handoff is not evidence that the agent failed. It is part of a reliable service design.
Define escalation triggers before launch, including:
- the customer cannot be authenticated;
- required account data conflicts across systems;
- the request falls outside the agent’s named job;
- the user disputes a charge, cancellation, or policy decision;
- the agent reaches a retry or tool-failure limit;
- the interaction involves threats, vulnerability, legal claims, safety, or another high-risk category;
- the customer asks for a person.
The handoff also needs context. A human should receive a short summary of what the customer requested, which systems were checked, which actions were attempted, and why the agent stopped. Making the customer repeat the entire story defeats much of the value.
Pass this gate when: the team can show exactly what the human receives and who owns the escalated case.
Fail this gate when: “send it to support” is the entire escalation design.
Gate 4: Test Outcomes, Not How Human the Conversation Sounds
A natural voice can make a weak agent feel more capable than it is. Evaluate the work instead.
Build a test set that includes:
- common, straightforward requests;
- incomplete or contradictory information;
- uncommon but legitimate edge cases;
- attempts to make the agent ignore policy;
- tool outages and slow responses;
- requests requiring approval;
- cases where escalation is the correct answer.
Define the expected result before running the test. Useful measures include:
- correct outcome;
- correct policy application;
- correct tool and data usage;
- no action beyond permission;
- appropriate escalation;
- complete and accurate audit record.
A response that sounds polished but applies the wrong refund rule is a failure. A brief response that safely escalates an ambiguous case may be a success.
OpenAI says Presence uses simulations and graders to check outcomes, policy compliance, tool use, and escalation before deployment. Its broader agent guidance similarly recommends establishing evaluations before optimizing cost or latency.
Pass this gate when: the team has a repeatable test set and an agreed release threshold.
Fail this gate when: approval is based mainly on a few impressive demonstrations.
Gate 5: Name the Person Who Owns the Agent After Launch
Policies change. Products change. Customers invent requests that were not in the test set. An agent that was correct at launch can become wrong later.
Assign a named owner who is responsible for:
- reviewing escalations and failed sessions;
- tracking policy and knowledge changes;
- approving prompt, tool, and permission updates;
- rerunning evaluations before rollout;
- monitoring regressions after changes;
- pausing or rolling back the agent when necessary;
- coordinating with the human support team.
Presence includes a Codex-powered process that can investigate production signals and propose updates for teams to test and approve. The key word is approve: an improvement loop still needs accountable people, controlled releases, and evidence that the change is better than the version already in production.
Pass this gate when: ownership, review cadence, rollback authority, and success metrics are explicit.
Fail this gate when: the agent becomes an “AI project” owned by nobody once the launch team moves on.
A Practical 30-Day Pilot
A small team evaluating any support agent—not only Presence—can structure a pilot like this:
Week 1: Map One Workflow
Choose one bounded request category. Document the current process, policy rules, data sources, human exceptions, and the expected final state.
Week 2: Run in Shadow Mode
Let the agent analyse real or carefully anonymised historical cases without contacting customers or changing records. Compare its proposed outcomes with the decisions made by experienced staff.
Week 3: Allow Limited, Low-Risk Actions
Expose the agent to a narrow group of users or cases. Keep approval gates for sensitive actions, monitor every escalation, and preserve a fast human fallback.
Week 4: Decide With Evidence
Review outcome accuracy, policy failures, unnecessary escalations, missed escalations, customer effort, staff time, and operational cost. Expand only the parts that passed the agreed tests.
The goal of the pilot is not to prove that an agent can work. It is to discover the boundaries within which it works reliably.
When You Should Wait
Do not give an AI agent account-level authority yet when:
- your policies are mostly unwritten or frequently contradictory;
- important customer data is incomplete or unreliable;
- nobody can produce representative test cases;
- the workflow contains high-stakes judgments without a clear approval step;
- human escalation is slow, understaffed, or undefined;
- the business cannot audit which data and tools produced an action;
- there is no long-term owner.
In those situations, use AI for lower-risk assistance first: summarising cases, retrieving policy passages, drafting responses, categorising requests, or preparing a handoff for a person.
The Real Meaning of the Launch
Presence signals that enterprise AI is moving beyond chat interfaces toward managed operational systems. The competitive question will not simply be which model sounds smartest. It will be which deployment can stay inside policy, take the correct action, escalate appropriately, and improve without losing control.
That is also why most companies should resist starting with a broad autonomous agent. Begin with one job, minimal access, measurable outcomes, a human escape route, and a named owner. The more authority the agent receives, the stronger each gate must become.