OpenAI Presence: What a Guardrailed Enterprise Agent Platform Means for Product Teams

OpenAI launched Presence on July 22, enterprise software for deploying AI agents across voice and chat with the access controls and testing tooling that most teams currently build themselves, badly, under deadline pressure. If your team has been assembling an internal agent stack piece by piece, this is worth twenty minutes of your attention before the next planning cycle, not because it’s a magic fix, but because it names the exact gap most in-house builds are quietly running without.

What Presence actually is

Strip away the launch framing and Presence is three things bundled together:

Access control. Organizations define exactly what knowledge an agent can read, which enterprise systems it can call into, and what actions it’s authorized to take on its own versus what needs a human sign-off. This is the part every serious internal agent deployment ends up building anyway, usually as a custom permissions layer sitting in front of whatever orchestration framework the team picked.

Simulation and monitoring. Before an agent goes live, Presence runs it through simulated real-world scenarios, then keeps monitoring production performance after launch. This is the evaluation half of the problem, the part that separates “the demo worked” from “it holds up against messy real input at volume.”

A review loop. OpenAI’s Codex reviews production interactions and proposes behavior changes, and staff test and approve those changes before they ship. This is the closest thing to a formal change-management process for agent behavior that a vendor has shipped as a first-class feature rather than something a customer has to invent internally.

None of these three ideas are new. Access control, evaluation harnesses, and approval workflows for AI behavior changes are things capable teams have been building since agent deployments got serious in 2025. What’s new is a vendor packaging all three as one product, tied directly to the model provider, rather than each team assembling its own version on top of a raw API.

Who’s actually running it

OpenAI says Presence already handles its own English-language phone support line, claiming a 75% resolution rate for inbound calls without human intervention. That’s OpenAI’s own number about its own deployment, worth reading with the appropriate skepticism reserved for a vendor’s case study about itself, but it does tell you the product graduated from an internal tool before becoming a sales pitch, which is a better provenance than most enterprise AI launches can claim.

Named external customers span a reasonable spread of use cases: BBVA Mexico for customer interactions, SoftBank Corp for Japanese-language agents, and Retail Insurance Australia for customer-facing support. Target use cases beyond those three include outbound sales development, procurement, and IT service functions, the same categories that have been the proving ground for enterprise agent deployments generally.

The decision that actually matters

The headline comparison people will reach for is “Presence versus building your own from scratch,” and for a team starting from zero, Presence is a legitimate way to skip months of infrastructure work. But most teams reading this aren’t starting from zero. They already have some version of an agent deployment, built on whatever orchestration approach they picked when this became a priority, with access control bolted on unevenly and evaluation that’s more ad hoc than anyone wants to admit in a status meeting.

For that more common situation, the real comparison is narrower: does Presence’s governance and review tooling replace enough of your current in-house scaffolding to justify the coupling? Moving your agent deployment layer onto a single vendor’s platform is a real commitment, not just a config change, and it means your access-control model and evaluation process now live inside OpenAI’s product roadmap rather than your own codebase. That’s a fine trade if your in-house tooling was thin and your team’s real expertise is in the business logic the agent executes, not the deployment infrastructure around it. It’s a worse trade if you’ve already invested seriously in your own evaluation pipeline and the value you’d get from Presence is mostly the Codex review loop, which you could reasonably build a lighter version of yourself.

Rolling out through limited general availability with OpenAI Forward Deployed Engineers involved also tells you something: this isn’t a self-serve toggle yet. Expect a sales conversation and an implementation timeline, not an API key you generate this afternoon.

What to actually do with this

If you’re advising a client, or making the call internally, on whether to adopt Presence versus continuing to build in-house:

1. Audit what you actually have today for access control and evaluation before comparing against Presence’s feature list. Teams overestimate how solid their current guardrails are until someone asks for a demo of the approval workflow.
2. Treat the 75% resolution figure as OpenAI’s own number for OpenAI’s own use case, not a benchmark you should expect to match on day one with a different domain and different data.
3. If your agent work already touches platforms with their own credential and access-control weaknesses, the governance layer Presence adds is solving a real, current problem, not a hypothetical one. That’s the strongest argument for it, independent of the vendor doing the selling.

Presence is a genuinely useful data point on where enterprise agent deployment is heading: governance and evaluation as first-class product features, not afterthoughts bolted onto a chat API. Whether it’s the right platform for your team depends less on what OpenAI built and more on how much of it you’ve already built yourself.