OpenAI Presence launched on July 22 as a managed layer over OpenAI's models for enterprise voice and chat agents. It is not a self-service product. Deployments are scoped one at a time and led by OpenAI's own Forward Deployed Engineers or a short list of systems integrators, with no published pricing.
What Presence sells is not a model. It sells an operating loop: scope what the agent can read and call, simulate it against edge cases before launch, then have Codex read production sessions and propose behavior changes that a human approves before they ship.
OpenAI published that same loop as a free cookbook, with named off-the-shelf tooling at every stage. The part you cannot download is the person in your organization who owns the eval set.
What actually shipped
Presence sits on top of OpenAI's models and handles the parts that have nothing to do with model quality. Three components, all of them familiar to anyone who has tried to put an agent in front of customers.
Access scoping comes first. You define what knowledge the agent can read, which internal systems it can call into, and which actions it is authorized to take. Not a system prompt asking it nicely, an enforced boundary.
Simulation comes second. Before launch, you run the agent against common scenarios and edge cases, and the platform checks four things: did it reach the right outcome, did it stay inside policy, did it use tools correctly, and did it escalate when it should have. That is a pre-deployment gate, and in my experience it is the piece teams skip.
The review loop comes third, and it is the interesting one. After launch, Codex reads production interactions and proposes behavior changes. Staff test those changes and approve them before anything ships. OpenAI reports one deployment cutting human handoffs by 15 percentage points in 10 days on that loop alone.
The reference deployment is OpenAI's own English-language phone support line, which it says resolves 75 percent of inbound calls with no human involved. Treat that number as a ceiling under ideal conditions rather than a target. It is OpenAI's domain, OpenAI's data, and OpenAI's engineers.
Three launch customers are named. BBVA Mexico is using it for customer interactions. SoftBank Corp. deployed Japanese-language agents. IAG, through Retail Insurance Australia, is targeting simple non-event claims so human specialists stay free for complex ones during severe weather. IAG's retail CEO Julie Batch framed it around support during "moments that matter," which is the honest version of the use case: the agent takes the routine volume so the queue shortens for everyone else.
Check where IAG actually is, though. As of the launch coverage, the engagement is in solution design, with implementation targeted for the second half of calendar 2026. The flagship customer is not live yet.
The loop is the product
Strip the branding and Presence is an answer to a question that has been sitting unanswered in a lot of engineering orgs since the first agent went to production: what is the maintenance procedure?
The build procedure is well covered. You write the prompt, wire the tools, ship it. The second procedure usually does not exist. The agent goes live, it does something odd on a Tuesday, someone edits the prompt, and nobody can say whether that edit helped or quietly broke three other paths.
Presence packages the missing procedure. Traces from production, a judgment about what was wrong, a test that encodes the judgment, a gate that runs the test, and a change that has to clear the gate. That is not novel. It is continuous integration applied to a component whose behavior is not deterministic, which is exactly why teams keep failing to build it themselves. The unit under test is a conversation, and writing an assertion about a conversation feels wrong until you have done it a few times.
The vendor lock question is real and worth naming. Adopt Presence and your access-control model and your evaluation process live inside OpenAI's product, not your repository. That is a genuine tradeoff, not a dealbreaker, but it is the thing to negotiate for rather than discover later. Ask whether the eval suite is exportable.
The same loop, published for free
The second half of this story is what turns it from a press release into a useful week.
OpenAI's cookbook has a worked example called Build an Agent Improvement Loop with Traces, Evals, and Codex. It is the Presence loop with the lid off, in six stages, using tools you can install this afternoon.
Run the agent on real questions with the Agents SDK and capture traces as JSONL. Collect feedback on those traces from a human expert and from a model reading for recurring patterns. Convert that feedback into Promptfoo test cases, each combining a deterministic assertion with an LLM rubric judge, and both have to pass. Run the suite as a gate. Rank the recommended changes by evidence. Write the ranked recommendations to a handoff file, hand it to Codex, let it implement, then rerun the gate.
The concept that carries the weight is the harness, which the cookbook defines as the full contract around the model: the system prompt, model and reasoning settings, tool policy, required output artifacts, and validation checks. It is stored as one versioned config object, so v001 and v002 are comparable and promotable.
That definition is the useful export from all of this. Most teams treat the prompt as the thing they version and everything else as configuration that drifts. Once the tool policy and the output contract and the validation scripts are all inside one versioned object, you can finally answer whether last Tuesday's change was an improvement, because you have two harnesses and one eval suite rather than a vague memory and a production incident.
Why it comes with engineers attached
The staffing is the tell. OpenAI stood up a whole services organization for this. The OpenAI Deployment Company launched in May, absorbing consultancy Tomoro and roughly 150 engineers, with about four billion dollars of initial investment from 19 partners at a fourteen billion post-money valuation, plus a separate 150 million dollar partner program for third-party implementers.
That is a lot of humans wrapped around a product whose pitch is automation. It is not a contradiction. It is a statement about where the difficulty sits.
Nobody's harness generalizes. The access boundary is your systems. The policy is your compliance department's. The simulation scenarios are your actual edge cases, which nobody outside your building can enumerate. The escalation rules encode judgment your operations team has and has never written down. A Forward Deployed Engineer is there to extract all of that and turn it into a test suite, because the model is interchangeable and the test suite is not.
Which means the gap between the managed service and the free notebook is not technical. Both give you the same six stages. The service gives you a person whose full-time job is to sit with your operations lead and convert institutional knowledge into assertions.
What to take from it
If you are running an agent in production and considering Presence, the deployment model is the thing to price. You are buying scoped consulting with a platform attached, and the value shows up as a maintained eval suite. Ask who owns that suite at the end.
If you are not in the enterprise tier, the loop is published and the tooling is generic. Traces, feedback, evals, gate, ranked change, agent implements, gate again. Start with the gate, even five tests, because the gate is what turns an opinion about a prompt edit into evidence.
And whichever route you take, do the harness part first. One versioned object holding prompt, model settings, tool policy, output contract, and validation checks. It costs an afternoon and it is the difference between improving an agent and rearranging it.
The most expensive AI product OpenAI shipped this month is a maintenance procedure with engineers attached. That is not a comment on OpenAI. It is a comment on how much of production agent work turns out to be operations, and how little of it is the model.