OpenAI Presence makes the production question explicit: value comes from reliable resolution, not conversational fluency alone.
OpenAI’s July announcement of Presence reflects a broader transition in customer and internal operations: enterprises are moving from agents that can hold a conversation to systems expected to complete a job.
OpenAI frames the challenge directly. The question is no longer whether agents can work in a demonstration, but whether they can remain reliable as policies, products and user behaviour change. That requires deployment systems, simulations, graders, guardrails and escalation—not only a capable model.
Resolution is a system property
A fluent interaction can still fail operationally. The agent may answer correctly but leave the customer to repeat the same information to a human. It may issue a refund without checking policy, promise a delivery date the logistics system cannot meet, or resolve the immediate ticket while creating a downstream accounting problem.
Resolution therefore depends on the complete chain:
identity → intent → context → policy → tool use → verification → communication → record
The model participates in that chain. It does not own all of it.
A reliable service agent needs access to approved knowledge, live customer context and a bounded set of actions. It also needs a definition of “done” that corresponds to the business process. Closing a chat is not the same as resolving a case.
Simulate before exposure
Presence highlights simulations and graders that test common requests, edge cases and higher-risk scenarios before deployment. This is a useful operating pattern for any agent, regardless of vendor.
A simulation library should include more than happy paths. It should cover:
- incomplete or contradictory customer information;
- policy conflicts and outdated documents;
- attempts to manipulate the agent;
- vulnerable customers or emotionally charged language;
- tool timeouts and partial writes;
- requests that cross legal or financial thresholds;
- ambiguous consent;
- cases that should be refused or escalated.
The goal is not to prove perfection. It is to identify the operating envelope and make failure behaviour deliberate.
Escalation is part of the product
Many service programmes treat escalation as evidence the agent failed. That creates pressure to over-automate.
A mature system treats correct escalation as a positive outcome when the case exceeds the agent’s authority, evidence or confidence. The transfer should preserve context, actions already taken, sources consulted and the exact reason for escalation. The human should not have to reconstruct the case from a transcript.
Escalation policy should be based on consequence, not merely model confidence. A highly confident agent can still be prohibited from approving a large refund. A low-confidence classification may be harmless if it only changes the order of an internal queue.
Policies must be executable
Operational policies often live in PDFs and intranet pages written for humans. Agents need a machine-enforceable layer around those documents.
Some policy can remain natural language for interpretation. Consequential boundaries should be encoded deterministically: monetary thresholds, eligible products, required evidence, jurisdiction, cooling-off periods, approval roles and prohibited actions.
That combination allows the model to handle language and ambiguity while software enforces the non-negotiable limits.
Measure the outcome, not the spectacle
A production programme should monitor:
- first-contact resolution and repeat contact;
- correct and incorrect escalations;
- policy adherence;
- action reversal or correction rate;
- customer effort and satisfaction;
- time from request to verified outcome;
- human review load;
- cost per successfully resolved case;
- performance drift after model or policy changes.
A human-like voice or fast response time matters only insofar as it improves those outcomes.
The Lexdatum view
The strategic shift is from conversation design to resolution architecture.
The most valuable agents will be embedded in processes with clear authority, tools and completion criteria. They will know what they can resolve, what they can propose and what must be handed to a person.
Enterprises should begin with a workflow where resolution is measurable and the action boundary is explicit. Build the evaluations before widening autonomy. The result may appear less magical in the first demo, but it will be far more valuable in production.
Sources
- OpenAI — Introducing OpenAI Presence (2026-07-22)
Research note: This analysis is based on public information available on 31 August 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported metrics are identified as such. This is not legal, security or investment advice.