Every board deck now mentions AI agents. Most organisations still cannot put one into production on a billing queue, a claims line, or an IT help desk without embarrassing themselves. OpenAI’s answer is not another API tier. It is OpenAI Presence: a managed enterprise product where Forward Deployed Engineers (FDEs) and select systems integrators scope workflows, wire systems, test behaviour, and only then turn agents on for voice and chat. That is the opposite of self-serve. For executives who already read our piece on the absorption gap, Presence is what “process re-engineering with agents” looks like when a lab sells deployment capacity, not just tokens.
What Presence actually is
Not a model drop. A governed agent operating system with humans still in the loop.
OpenAI frames the enterprise problem as reliability under change, not proof of concept. Products, policies, and user behaviour shift; an agent that worked in a demo must keep working in production without the business surrendering control.
“We’re introducing OpenAI Presence, a battle-tested product that helps enterprises deploy trusted AI agents that can answer questions, resolve issues, use company systems, take approved actions, and escalate to people when needed. Proven through years of working with customers at enterprise-scale, Presence pairs model reasoning with policies, guardrails, and escalation rules that verify accuracy and performance.” – OpenAI, Introducing OpenAI Presence
Each deployment starts from a specific job (billing, claims, IT requests). The agent receives only the knowledge and system access required for that job. The company sets what it may do, when approval is required, and when a person must take over. After launch, production sessions and escalations expose gaps; Codex can propose updates that teams test and approve.
Merits of the argument: This matches how regulated enterprises actually buy software: bounded scope, explicit permissions, audit trail, escalation paths. It also admits that model capability alone is insufficient without SOPs, simulations, graders, and a change-management loop.
FDE-led delivery, not a SKU in your cart
Forward Deployed Engineers are the product boundary, not a premium support tier.
Presence is explicitly not self-serve. OpenAI works alongside the customer to identify high-value workflows, connect knowledge and systems, establish permissions, test, and bring agents into production. When a use case exceeds today’s product surface, FDEs and partners extend it.
“OpenAI Presence is available to eligible enterprise customers as a deployed product through a limited general availability program. Deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators. Presence is not yet available as a self-serve product.” – OpenAI, Introducing OpenAI Presence
Merits of the argument: High-stakes workflows fail when procurement treats “agent platform” like a chatbot licence. FDE-led delivery forces joint ownership of workflow design, integrations, and eval criteria before traffic hits customers or employees.
Voice and chat under one governance model
Channels differ; policies, evaluations, and escalation rules can stay consistent.
Presence supports real-time voice and chat today: customer support, outbound sales, and high-risk internal workflows. Companies choose what stays consistent across deployments and what varies by workflow or channel, so teams can expand without rebuilding governance from scratch.
“When a use case goes beyond what the product supports today, OpenAI Forward Deployed Engineers (FDEs) and partners can work with the customer to bring it into production.” – OpenAI, Introducing OpenAI Presence
OpenAI cites its own English phone support (1-888-GPT-0090) as a live Presence deployment: open-ended requests, caller verification, account context, approved actions. It reports resolving 75% of inbound issues without human assistance and a Codex-powered improvement loop that cut human handoffs by 15 percentage points in 10 days on that channel.
Merits of the argument: Voice adds latency, barge-in, and compliance constraints that chat-only pilots hide. A product that ships both channels under shared policy objects is closer to contact-centre reality than a Slack bot pilot.
Failure cases
Case 1: Buying Presence like an API key
Procurement signs an enterprise agreement expecting developers to spin up agents in a portal. Presence is limited GA with FDE-led deployment. Outcome: stalled programme, angry business sponsors, IT blamed for “OpenAI not working.”
Case 2: Skipping the pre-launch simulation layer
Teams rush to production voice without edge-case sims, policy graders, or escalation tests. One bad billing or claims interaction becomes a regulatory incident. Presence explicitly supports simulations and graders before launch; skipping them defeats the product.
Case 3: Confusing ChatGPT workspace agents with Presence
Employees build helpful Slack or ChatGPT workspace agents while executives assume those are production-grade customer agents. Workspace agents and Presence deployments differ in scoping, integration depth, and operational oversight. Mixing the two creates false confidence.
Case 4: No owner for the post-launch improvement loop
Launch day succeeds; nobody owns weekly review of escalations, Codex proposals, or controlled rollouts. Agent quality decays as products and policies change. Presence assumes continuous improvement; organisations that lack absorption capacity still stall (see absorption gap).
Migration: from pilot chatbot to Presence-ready
- Pick one high-volume, repeatable workflow with clear SOPs and measurable outcomes (not “general HR questions”).
- Inventory systems of record the agent must read or write; map identity, permissions, and PII boundaries.
- Define escalation rules before model selection: when must a human take over, and what gets logged?
- Run shadow mode with sims and graders on historical tickets or calls before customer-facing voice.
- Assign a product owner for the Codex improvement loop post-launch, not just a vendor project manager.
- Contact OpenAI account team for limited GA eligibility; budget FDE/partner delivery, not only token spend.
When self-serve or lighter tools are actually fine
- Employee copilots on documents and email where wrong answers are corrected in private, not on a customer call.
- Low-volume internal FAQ with no write access to systems of record.
- Prototype discovery before you know whether the workflow justifies FDE-led deployment.
- Markets or channels where voice is not required and chat latency is forgiving.
Presence is for organisations that already know the workflow is high value, high volume, and high stakes, and that need governance at scale.
What to check right now
- Do you have a named executive owner for agent operations, not just AI experimentation?
- Is your target workflow backed by written SOPs and testable success criteria?
- Can you articulate what the agent may write versus read in each system?
- Do you have contact-centre or ITSM data to simulate before voice go-live?
- Have you separated workspace-agent experiments from customer-facing production plans?
- Does your budget include implementation services, not only model inference?
Sources and references
Primary links for every quotation and load-bearing number in this dossier. Verify before you reuse a figure elsewhere.
- OpenAI – Introducing OpenAI Presence – product definition, FDE delivery, limited GA, voice/chat, OpenAI support metrics (75% resolution, 15pp handoff reduction)
- SudoAll – The Absorption Gap – executive framing for deployment capacity vs tool access
nJoy 😉