All writing

OpenAI Presence: When Your Model Provider Becomes Your Competitor

The most dangerous competitor doesn't announce itself as a competitor. OpenAI just launched Presence — an enterprise agent deployment platform that bundles model, guardrails, governance tooling, and Forward Deployed Engineers into a single, undisclosed-price contract. If you're building a voice or workflow automation product targeting enterprise, OpenAI is no longer just your infrastructure provider. It's now in your account.

Let me break down what this actually is, why the architecture signals something important, and what founders and CTOs should do about it.

What Presence Actually Is (Strip the Press Release)

According to OpenAI, Presence bundles:

  • Policies and standard operating procedures baked into the agent
  • Guardrails and approved action sets
  • Simulation and evaluation tooling
  • A Codex-powered improvement loop
  • Scoped, least-privilege deployment per job function

The architecture isn't novel — this is exactly what any competent agentic stack looks like when you've shipped enough agents to know what breaks. The novelty is who's packaging it and how they're selling it.

This is not a self-serve API product. Deployments are led by OpenAI's Forward Deployed Engineers and select global systems integrators. That means a sales cycle, a scoping engagement, and a contract with undisclosed pricing. This is services-led enterprise software — the model is table stakes, the services layer is the margin.

OpenAI dogfooded it first, which is worth noting. Presence now handles roughly 75% of OpenAI's own inbound support volume, and reportedly matched their help desk quality within weeks. That's a credible proof point, and it's exactly the reference case an enterprise procurement team wants to hear before signing a seven-figure deal.

Three named launch customers — BBVA Mexico, SoftBank Corp., and Retail Insurance Australia (part of IAG) — cover three different verticals, three different languages, and three different regulatory environments. That's a deliberate signal: this isn't a US English customer support demo, it's a global deployment play.

The Real Move: From Model Provider to Systems Integrator

This is the thing most commentary has missed. OpenAI isn't just building an agent product. It's building a deployment capability — and it's backing that with $4 billion in committed capital and a dedicated OpenAI Deployment Company subsidiary that was formed just two months ago at a $10 billion valuation.

That is not a product bet. That is a services business being capitalized at scale.

Anthropic is doing the same thing through Ode, its consulting arm. When the two frontier labs both simultaneously pivot toward services-led deployment, the pattern is clear: raw model capability is commoditizing faster than anyone publicly admits, and the durable margin is in the deployment layer.

The implication for anyone building on top of these APIs: the moat is no longer access to the model. The moat is domain knowledge, vertical depth, data integrations, and governance architecture — all the things OpenAI's FDEs will spend 6 to 12 weeks rebuilding from scratch for every customer they land.

The Least-Privilege Architecture Is the Part You Should Steal

The design decision I find most interesting in the Presence brief isn't the guardrails or the evaluation tooling — it's the scoped, least-privilege agent design. Each agent deployment starts with a specific job. The agent gets only the knowledge and system access that job requires. Policy determines what it can do, when it escalates, and when a human takes over.

This is exactly the pattern I'd advocate for regardless of vendor. I've written about explicit state machines for agent control — the same principle applies here. The agent that can do anything is the agent that will eventually do the wrong thing in production. Scoping isn't a limitation, it's the engineering discipline that makes enterprise deployment survivable.

If you're building agents right now, apply this framework:

Design QuestionPermissive (Wrong)Scoped (Right)
Knowledge accessFull knowledge baseFiltered to job domain
System permissionsAll available toolsTool set per job scope
Escalation triggerModel decidesPolicy-defined conditions
Human handoffOn failure onlyOn ambiguity + failure
Action approvalAutonomous by defaultApproval gates for writes

This table should be the first thing your team fills out before you write a single line of agent code.

The Security Timing Is Not Coincidental

Presence launched the same week that OpenAI and Hugging Face are jointly investigating a security incident where advanced models exploited vulnerabilities to access information on Hugging Face's production infrastructure. I covered the broader pattern of agentic production breaches earlier this month — this isn't theoretical anymore.

Launching an enterprise deployment product the same week as a confirmed model-driven security incident is either terrible timing or a deliberate framing: "buy the managed product, don't run this yourself." I won't speculate on which. But any CTO evaluating Presence should be asking hard questions about the control plane:

  • Who has eyes on the agent's action logs in real time?
  • What's the blast radius if the agent is manipulated via adversarial input in the customer channel?
  • How does Presence's guardrail layer interact with prompt injection in a voice context?

Pricing and contractual terms are undisclosed. That means your security audit clauses, your data residency requirements, and your breach liability terms are all TBD. Don't sign anything before your legal team has those answers.

What This Means If You're Building a Vertical AI Product

If your product is horizontal — "AI agents for customer support, for any company" — OpenAI Presence is now a direct competitor with an incumbent distribution advantage, an existing enterprise trust layer, and a sales team that's already in the room. That fight is unwinnable on OpenAI's terms.

If your product is vertical — "AI agents for MENA banking compliance," "AI agents for Arabic-language insurance claims," "AI agents for medical device support in GCC regulatory environments" — Presence is a floor-raiser, not a ceiling. OpenAI's FDEs will build you a generic customer support agent in 8 weeks. They will not replicate your domain-specific training data, your integration with legacy core banking systems, your understanding of the regulatory edge cases that matter in your market, or the trust relationships you've built with the procurement contacts who actually sign the purchase order.

The commoditization of generic deployment is good news for vertical specialists. The bar for "good enough" just moved up. That's not a threat — it's a forcing function to build something actually differentiated.

Here's the decision rule I'd apply:

  • If your agent's core value is orchestration and routing → Presence will eat your lunch within 18 months
  • If your agent's core value is domain-specific data + workflow integrations → Presence raises buyer expectations but doesn't replace you
  • If your agent's core value is compliance with specific jurisdictional or vertical regulation → Presence won't touch that problem for years, if ever

What to Actually Do

1. Audit your differentiation layer this week. List every component of your agent stack. Mark each one: "OpenAI/Anthropic could deploy this in 8 weeks" vs. "this requires our domain depth." If the first bucket is larger, you have a positioning problem, not an engineering problem.

2. Lock down your least-privilege architecture now. Whether you're on Presence or building on raw APIs, scope your agents to specific jobs, define explicit escalation policies, and document the access each agent needs. This is table-stakes governance and it will come up in every enterprise procurement conversation from here.

3. Build your governance artifact before the sales cycle. Presence wins enterprise deals partly because it shows up with evaluation tooling and simulation artifacts. Build equivalent evidence: evals, red-team results, audit logs, and a clear human-in-the-loop diagram. These are now competitive requirements, not nice-to-haves.

4. Clarify your data story before your customers ask. Presence's data handling terms are undisclosed. That's an opening. If you can tell your customer exactly where their data lives, who touches it, and what the residency guarantees are — especially in regulated markets — you have a concrete differentiator over a white-glove OpenAI engagement that hasn't published its terms.

5. Watch who the global SIs partner with. OpenAI is deploying Presence through "select global systems integrators." Those SIs are already in enterprise accounts. If your product doesn't have an SI partnership or a clear co-sell motion, figure that out — because the distribution math just got harder for direct-only players.

OpenAI becoming your competitor is only an existential problem if you were competing on the wrong thing. If you were building generic deployment, you were always one product launch away from this moment. The answer isn't to panic — it's to go deeper on the vertical, the data, and the trust relationships that OpenAI's FDEs can't replicate from a conference room in San Francisco.

Working on something like this? I take on a few fractional-CTO and AI engagements at a time.

The AI CTO playbook

Get my AI playbooks — straight to your inbox

Practical notes on shipping production AI, scaling teams, and the calls a CTO actually has to make. A few times a month. No spam, no fluff.