OpenAI Presence is interesting because it treats agent deployment as an operating model: policies, approved actions, simulations, evaluations, escalation, and controlled updates. I tried to reduce that idea to the smallest artifact I would want to review before an agent touched a business system.
OpenAI announced Presence on July 22 as an enterprise product for voice and chat agents. The headline capability is familiar: answer questions, use company systems, take approved actions, and hand work to a person when needed.
The useful part is the word approved.
A model can write a very convincing sentence saying that it refunded a customer. That sentence does not tell an operator which policy it read, whether the action was allowed, whether someone approved it, whether it ran, or where it ran. It is a conclusion without an audit trail.
Presence is not a public self-service API that I can test from a terminal. OpenAI describes a limited general availability program for eligible enterprise customers, and independent reporting says deployments involve OpenAI Forward Deployed Engineers and selected systems integrators. I cannot validate its product claims or its reported support metrics from outside that program.
I can test the narrower operational question: what must an agent return so that a human can review a proposed action without trusting the prose around it?
A refund is a useful small boundary
I used a synthetic refund request for $240. The synthetic policy says that refunds over $100 require human approval.
The first result is the sort of response that looks successful in a chat transcript:
{
"request_id": "req-1042",
"final_answer": "The $240 refund was approved and submitted."
}
It is short. It is confident. It is not reviewable.
There is no policy reference, no proposed system operation, no approval state, no execution record, and no input reference. A reviewer cannot distinguish a real completed refund from a model's summary of what it intended to do.
The second result carries an evidence bundle instead:
{
"request_id": "req-1042",
"input_refs": [
"synthetic-ticket:req-1042",
"synthetic-policy:refund-v3"
],
"policy_decision": {
"rule": "refunds_over_100_require_human_approval",
"result": "approval_required"
},
"proposed_action": {
"system": "billing",
"operation": "create_refund",
"amount_usd": 240
},
"approval": {
"status": "pending"
},
"execution": {
"status": "not_executed"
},
"final_answer": "Refund is awaiting human approval."
}
This does not make the action safe by itself. The policy might be wrong. The referenced input might be stale. The approval service might have its own failure modes. But it gives a reviewer something concrete to challenge before money moves.
What I tested
I wrote a small validator that checks whether a record contains the fields needed to review a policy-bound action:
request ID
input references
policy decision
proposed action
approval state
execution state
final answer
It ran in a disposable Docker container against only two synthetic JSON records. The container had no network, no mounted host directory, a read-only filesystem, a 16 MiB temporary filesystem, all Linux capabilities dropped, no-new-privileges, one CPU, 128 MiB memory, and a PID limit of 64. It ran as UID 65532.
The response-only record failed exactly where it should:
{
"record": "response_only",
"review": {
"missing": [
"approval",
"execution",
"input_refs",
"policy_decision",
"proposed_action"
],
"reviewable": false
}
}
The evidence bundle passed the structural check:
{
"record": "evidence_bundle",
"review": {
"missing": [],
"reviewable": true,
"violations": []
}
}
The SHA-256 of the complete experiment output was:
84baf0d31026d1c838e9adb6c92a89bb796ffaf5482b088f486943b8e37205f7
Smoke test only: this validates a small record contract. It does not test OpenAI Presence, a payment provider, a real approval system, or an enterprise security boundary.
Presence is packaging the work around the model
The available evidence points to a product shaped around the problem operators actually have. OpenAI's public announcement says agents can use company systems, take approved actions, escalate to people, and improve over time. Its official X announcement names voice and chat across internal and customer workflows.
VentureBeat reports that Presence brings together company knowledge, standard operating procedures, approved actions, simulations, evaluations, guardrails, escalation rules, and monitored production sessions. It also reports a proposed-update loop in which Codex investigates operational signals, proposes a change, and teams test that change against the production version before a controlled rollout.
That is closer to a deployment system than a chat interface.
The model call still matters. It is not the part that tells a company whether the agent should be allowed to change a refund, reset an account, close a ticket, or trigger a deployment. Those decisions live in policy, identity, system boundaries, evidence, and the route back to a person.
A useful agent response has two audiences
Every agent result has an immediate audience: the person who asked for help. It should be clear and concise.
It also has an operational audience: the reviewer who needs to answer questions later.
What did the agent see?
Which policy applied?
What did it propose?
Who approved it?
Did the external action run?
What output proves the result?
The first audience reads the final answer. The second needs references and state transitions. A system that only produces the first will eventually ask someone to trust an unreviewable claim.
This is why I would keep the evidence bundle separate from the conversational answer. A customer does not need a JSON object full of internal references. An operator does. The system should retain both without turning either one into an afterthought.
The part still missing from the public story
Presence is a real announcement, but much of the operational detail is not public yet. Pricing, regional availability, contractual terms, SLA commitments, evaluation methodology, and interoperability limits have not been disclosed in the sources I could verify. The reported support results are OpenAI's own numbers, not independent benchmarks.
That is normal for a limited-GA enterprise product. It also means buyers should ask boring questions before they admire the demo:
- Can an action be replayed or reversed?
- Is an approval attached to an immutable request, policy version, and action payload?
- What happens when a policy lookup or tool call times out?
- Can the full evidence bundle be exported into the company's own incident and audit systems?
- Who can change the policy, the tool permissions, and the evaluation suite?
An agent that sounds certain is easy to build. An agent that leaves enough evidence for somebody else to reject, approve, reproduce, or roll back its action is the thing worth operating.
Sources: OpenAI Presence announcement · OpenAI announcement on X · VentureBeat reporting on Presence · Help Net Security coverage