OpenAI Presence turns agent reliability into an operating loop

Presence is a control-plane release disguised as a product launch

OpenAI introduced Presence on July 22, 2026 as a managed enterprise platform for governed voice and chat agents. The launch page says agents can answer questions, resolve issues, use company systems, take approved actions, and escalate to people. Those verbs describe familiar agent capabilities. The more consequential claim is that one system can keep those agents reliable as products, policies, connected systems, and user behavior change.

That is the production problem most agent demos omit. A demo has a frozen prompt, a small set of examples, and an operator ready to rescue it. A deployed agent encounters stale knowledge, ambiguous requests, partial outages, changing permissions, adversarial text, unusual customer states, and policy exceptions. Model quality helps, but the failure boundary sits in the whole workflow: retrieval, identity, tool contracts, state transitions, approvals, telemetry, and escalation.

OpenAI reports that its own customer-support deployment uses Presence to resolve roughly three quarters of inbound issues and that a Codex-powered improvement loop reduced human handoffs by 15 percentage points in ten days. These are vendor-reported operating results, not independent benchmarks. They are still useful because they reveal the product's optimization target: production traces become reviewed changes to the agent rather than a dashboard that somebody checks once a month.

The caution is equally important. Fewer handoffs can mean the agent resolved more cases correctly. It can also mean escalation became harder, repeat contacts increased, or people received only the most difficult cases. CIO coverage of the launch raises exactly this workload issue. A responsible adoption plan must pair automation metrics with outcome quality and the changing complexity of the residual human queue.

Presence also arrived during intense scrutiny of agent containment after OpenAI's cyber evaluations crossed real external boundaries. That incident is not evidence about the Presence product. It is a useful pressure test for the broader promise of governed agents: permissions must be enforced below the model, actions must be attributable, unexpected behavior must trigger containment, and optimization goals must not outrank system boundaries.

The six-part operating loop

OpenAI's launch and Help Center material describe six functions that should exist in any serious enterprise-agent platform. A buyer should turn each function into observable acceptance criteria rather than accepting a feature label.

The order matters. Teams often start by connecting tools, then bolt on policy after the agent has authority. A safer sequence starts with a task and its prohibited outcomes, defines the authority envelope, creates an evaluation set, and only then enables the smallest set of actions required to complete the task. Production evidence may expand or shrink that envelope later.

OpenAI's Help Center explicitly says an agent does not become production-ready merely because it ingests documents. Retrieval gives the model more context; it does not establish authorization, validate a policy, prove a resolution, or make an action reversible. That distinction is the easiest way to separate a knowledge bot from an operational agent.

A reference architecture for governed enterprise agents

User or event
      |
      v
Channel and identity gateway
  - authenticate actor
  - classify channel and jurisdiction
  - attach consent and tenant context
      |
      v
Policy decision point
  - allowed intent and data
  - disclosure and escalation rules
  - maximum action authority
      |
      v
Agent runtime
  - model and instructions
  - retrieval with source metadata
  - state machine and bounded retries
      |
      v
Tool broker and approval service
  - action-level authorization
  - idempotency and rate limits
  - human approval for sensitive writes
      |
      v
Business systems
  - CRM, ticketing, identity, billing, HRIS
      |
      v
Evidence and outcome plane
  - trace, sources, actions, cost, result
  - user correction, repeat contact, escalation
      |
      v
Reviewed improvement pipeline
  - cluster failures
  - propose policy/prompt/tool change
  - regression test, canary, approve, rollback

The policy decision point should be independent from the model's generated plan. It receives verified context such as tenant, role, jurisdiction, risk class, consent state, and requested action. It returns a decision that the tool broker enforces. The model may explain why it thinks an action is appropriate; it should not decide whether its own credential can perform that action.

The runtime should express workflows as explicit state transitions. A support agent might move from identify_issue to collect_evidence, propose_resolution, request_approval, execute, and verify. Free-form tool calling is still possible inside a state, but the state machine limits what can happen next and makes missing verification visible.

The evidence plane joins technical traces to business outcomes. A trace that ends with a successful API response is not necessarily a successful customer resolution. Capture whether the user reopened the case, contacted another channel, received a refund, complained, or accepted the answer. That link lets the improvement loop optimize real outcomes instead of proxy behavior.

Keep a promotion boundary between analysis and production changes. A coding agent can cluster failure traces, propose new evaluation cases, or draft policy edits. It should not silently publish its own fix. The release pipeline runs the candidate change against a locked regression suite, compares it with the current version, applies reviewer gates, deploys to a canary, and retains an immediate rollback path.

Encode policy as testable decisions

A PDF policy is necessary for governance but insufficient for runtime enforcement. Convert the parts that constrain agent behavior into a versioned policy object with owners and tests. Keep legal or policy interpretation with qualified reviewers; the machine-readable layer represents their approved decision.

# Illustrative policy, not OpenAI Presence syntax
policy_version: support-refunds-2026-07-29
scope:
  channel: [chat, voice]
  market: [US]
  user_authentication: required

actions:
  read_order:
    allow: true
  issue_refund:
    allow_if:
      - order_age_days <= 30
      - amount_usd <= 100
      - fraud_flag == false
    approval_if:
      - amount_usd > 50
    deny_if:
      - regulated_product == true

escalate_if:
  - identity_confidence < 0.95
  - policy_conflict == true
  - user_requests_human == true
  - tool_result == "ambiguous"

logging:
  record_sources: true
  record_policy_decision: true
  redact_payment_data: true

Each rule needs positive, negative, and boundary tests. Test a 30-day order and a 31-day order; a $50 refund and a $50.01 refund; a user who requests a person after the agent has already started a flow; and a downstream system that returns incomplete data. Boundary cases find more policy defects than another set of ordinary conversations.

Permission design should follow the same discipline. Use separate identities for reading an order, writing a case note, and issuing a refund. Bind credentials to the agent deployment, tenant, environment, action, and short lifetime. If every tool call uses one broad service account, the policy layer becomes a recommendation rather than a control.

Evaluation must represent the workflow, not just the model

OpenAI's practical guide to building agents recommends layered guardrails and human intervention for high-risk or repeated-failure cases. The operational extension is to test the entire path: identity, retrieval, policy, tool selection, tool arguments, side effect, verification, and escalation. A model-only score misses most production failure modes.

Create an evaluation matrix across intent, risk, system state, user state, and expected transition. Use historical cases only after privacy review and de-identification; they contain real messiness but can reproduce historical mistakes. Add synthetic cases for rare, severe failures and adversarial prompts. Keep a stable regression core while rotating fresh production-derived cases into a challenge set.

Evaluate changes as paired comparisons against the current deployment. Require a candidate to improve its target metric without crossing safety, policy, privacy, latency, and cost thresholds. A prompt edit that reduces handoffs but increases unsupported commitments should fail promotion.

Measure what the business and the user experience

Presence foregrounds continuous improvement. That only works if telemetry describes outcomes instead of celebrating activity. Track a balanced set of measures and segment them by workflow, policy version, channel, language, customer group, system state, and escalation reason where lawful and appropriate.

Use leading and lagging indicators. Tool errors and missed citations appear immediately. Complaints, chargebacks, repeat contacts, and audit findings may arrive days later. Join delayed outcomes back to the original trace and policy version before labeling a change successful.

Buy the loop, build the controls, or compose both

Presence is managed and deployment-specific; public material does not expose every implementation detail, pricing term, hosting choice, portability boundary, or integration limit. Buyers should evaluate the delivered architecture and contract rather than assuming the launch page answers these questions.

Ask for exports of traces, evaluation cases, policy versions, and outcome records in usable formats. Confirm how business-system connectors are authorized, how secrets are isolated, what the provider can access, what changes require notice, and what happens when the service is unavailable. Portability is not only model portability. It is the ability to preserve operating knowledge and evidence.

Failure modes that a polished demo will not show

The strongest implementation is not the one with zero escalation. It is the one that resolves routine work, recognizes its boundary early, gives the human complete context, and leaves enough evidence to improve the system without hiding the original failure.

A practical pilot checklist

Start in shadow mode or with reversible, low-impact actions. Run the system against production-like inputs while people remain the decision and action owners. Promote one capability at a time. If the workflow cannot define success, escalation, and rollback, it is not ready for autonomous execution.

FAQ

What is OpenAI Presence?

OpenAI describes it as a managed enterprise platform for building, deploying, operating, and continuously improving governed voice and chat agents. Exact architecture and controls can vary by deployment, so customer documentation and contracts remain authoritative.

How is it different from a chatbot builder?

The important difference is the operating loop: policies, permissions, evaluations, production monitoring, escalation, and reviewed improvement are part of the product claim. A chatbot builder may provide some of these, but retrieval and conversation design alone are not enough.

Does a lower human-handoff rate prove success?

No. Pair it with verified resolution, repeat contacts, complaints, unsafe actions, user requests for people, and the complexity of cases that reach human teams. Optimization without those measures can hide worse service.

Should policy live in the prompt?

Prompts may summarize policy, but action authorization should be enforced by an independent policy and tool layer using verified identity and context. Retrieved text and user input must not be able to rewrite authority.

What should a first pilot cover?

Choose a high-volume, bounded workflow with clear source systems, reversible actions, measurable outcomes, explicit escalation, and a human baseline. Avoid broad "employee agent" or "customer agent" scopes.