Answer first: OpenAI Presence is a managed enterprise platform for governed voice and chat agents in high-volume, high-stakes workflows. It is in limited general availability and is not self-serve. Evaluate it as a scoped deployment with integrations, policies, testing, human escalation, monitoring, rollback, and a customer-specific contract—not as another ChatGPT toggle.
Who should evaluate Presence?
Presence is a candidate when all of these are true:
- The workflow is repeatable and valuable at high volume.
- The agent must read from or act in approved business systems.
- Policies and permissions can be expressed and tested.
- Mistakes have a defined escalation and recovery path.
- The organization can supply product, operations, security, legal, and engineering owners.
- Success can be measured in business and safety outcomes.
Customer support and voice are early use cases in OpenAI’s documentation, but the same readiness questions apply to internal workflows.
Do not start with Presence when the task is exploratory, low-volume, poorly owned, or cannot define acceptable and unacceptable actions.
Presence is a managed deployment
OpenAI describes a process involving Forward Deployed Engineers, selected partners, or both:
- Define outcomes, success criteria, and initial workflows.
- Connect systems and encode policies, permissions, and escalation.
- Complete security, privacy, and legal review.
- Run simulations, evaluations, and acceptance tests.
- Stage a controlled production rollout.
- Review evidence and make tested improvements.
This sequence is the product boundary. Uploading a knowledge base does not make an agent production-ready.
Define the action surface before the conversation
Inventory every proposed operation:
| Operation | Questions to settle |
|---|---|
| Retrieve information | Which system, tenant, fields, and freshness requirement? |
| Update a record | Which fields, validation rules, approvals, and rollback path? |
| Communicate by voice or chat | Which identity, consent, disclosure, recording, and routing rules? |
| Make a decision | Is the agent allowed to decide, recommend, or only collect information? |
| Escalate | Which triggers, queue, context package, and response-time commitment? |
Start with read-only retrieval and a narrow workflow. Add actions only when authorization, duplicate prevention, audit, and recovery are testable.
Build governance into each release
OpenAI’s current Presence material describes simulations and graders before launch, plus guardrails, permissions, session records, action histories, quality signals, human escalation, controlled rollout, monitoring, and rollback.
Turn those capabilities into release criteria:
- A representative test set includes routine, ambiguous, adversarial, and high-risk requests.
- Each policy has a measurable pass or escalation condition.
- Tool calls are checked for authorization and correct arguments.
- Human handoff includes the information needed to continue safely.
- New versions are compared with the production version before approval.
- Rollback is tested before the rollout expands.
Measure containment and recovery, not only average answer quality.
Make deployment-specific truth explicit
OpenAI says exact features, models, channels, capacity, data handling, pricing, and service commitments depend on the deployment.
The procurement record should therefore name:
- Supported channels and contact-center integrations.
- Model configuration and change process.
- Data access, masking, logging, retention, storage location, and administrators.
- Security architecture, incident handling, and audit evidence.
- Capacity, support, rollout, and rollback commitments.
- Implementation, usage, and ongoing operations costs.
Treat the approved architecture and signed agreement as the source of truth. A public launch article cannot answer a deployment-specific privacy or price question.
Use an evidence-based pilot
Choose one bounded queue and define:
- Resolution and escalation rate.
- Policy-following rate.
- Unauthorized-action rate.
- Human review minutes.
- Customer or employee outcome.
- Latency and abandonment.
- Incident and rollback thresholds.
Run shadow or assisted operation before autonomous action where the risk requires it. Expand only when the measured result and operational controls meet the agreed gate.
For workspace-agent questions, use the current OpenAI product documentation rather than mapping Presence assumptions onto ChatGPT. For other enterprise platforms, review the enterprise AI alternatives guide. For agent permission and repository controls, use the OpenAI Codex FAQ. For a broader automation shortlist, see general-purpose AI agents.
FAQ
Is OpenAI Presence a self-serve product?
No. OpenAI says Presence is available to eligible enterprise customers through limited general availability as a managed deployment.
Is Presence the same as a ChatGPT workspace agent?
No. Presence is a separate managed enterprise product scoped and deployed with OpenAI or a selected partner for production workflows, integrations, testing, guardrails, monitoring, and deployment support.
What makes a Presence deployment production-ready?
Not document ingestion alone. OpenAI describes scoping, system integration, policy and permission design, security and legal review, simulations, acceptance testing, controlled rollout, monitoring, and evidence-based improvement.
Does Presence have one universal privacy or pricing policy?
No. OpenAI says exact data handling, models, channels, capacity, pricing, service commitments, and implementation scope are defined for each deployment. The approved architecture and contract are the authority.
Official sources
Sources last checked July 29, 2026: