OpenAI: Introducing OpenAI Presence

OpenAI launching Presence, an enterprise agent platform, tells you the frontier labs have decided the model is not the product anymore. The deployment layer is. And that is the exact moment to say the quiet thing plainly: a platform can ship you the layer, but it cannot ship you the outcome. Presence gives large companies a standardized way to run agents in production. It does not give them a working workflow their team actually relies on. That gap is still the job, and it still belongs to someone.

For most of the last two years the labs sold you raw capability. Better models, longer context, cheaper tokens. The pitch was: here is the engine, go build. Presence is a different move. It is OpenAI walking down the stack toward the thing that has always been hard, which is getting an agent to run reliably inside a company that has its own data, its own tools, and its own idea of what "done" means.

The dominant pattern: buy the platform, assume the outcome follows

The default reflex when a lab ships a deployment platform is to treat the platform as the finish line. Procurement signs a contract. A slide says "enterprise agent platform." Everyone assumes the agents will now show up, plug in, and produce results.

This is the same mistake teams made with every layer that came before. They bought the CRM and assumed clean pipeline. They bought the data warehouse and assumed insight. They bought the automation tool and assumed the process would automate itself. The tool arrives. The outcome does not, because the outcome was never inside the box.

A platform is a set of capabilities held in place by defaults. Your business is a set of exceptions held together by people who know the exceptions. Those two things do not meet on their own. Presence standardizes auth, orchestration, monitoring, and guardrails. Useful. But standardization is a way of serving the average company. No company is the average company at the point where the work actually gets stuck.

So the platform ships, and three months later the honest status is: the agent demos beautifully in the sandbox and touches almost nothing that matters in the actual business. That is not a Presence failure. It is the predictable result of buying a layer and calling it a system.

The mechanism: the deployment layer is not the deployment

Here is the distinction Presence forces into the open. The deployment layer is the infrastructure that lets an agent run in production. The deployment is the specific, messy work of making one particular workflow survive contact with one particular company.

A deployment layer is generic on purpose. A deployment is specific on purpose. Confusing the two is how AI budgets get spent with nothing to show.

The person who closes that gap is a forward-deployed engineer. A forward-deployed engineer builds the specific system a field owner needs, then hands it off legible enough that a local champion can run it. Presence changes what that engineer builds on. It does not remove the reason the engineer exists.

Think about what actually breaks when you move from a demo to a live workflow. The agent needs your data, which is dirty. It needs to call your tools, which have undocumented quirks. It needs to know when to stop and ask a human, which nobody has defined. It needs to fail safely, which requires someone to decide what "safely" means for your risk tolerance. None of that is a model problem. None of it is a platform problem. All of it is a judgment problem, and judgment is what a platform can never sell you.

Why the labs walking down the stack proves the point

The contrarian read is that Presence is evidence for the forward-deployed model, not against it. When OpenAI ships a deployment platform, it is admitting that raw capability was never enough on its own. The value was always at the point of contact with a real business.

But OpenAI cannot go to the point of contact. It is a lab serving millions of accounts. It has to build for the average, because building for one company at a time does not scale to its size. So it does the largest generalizable slice of the problem, the layer, and leaves the last, specific, unglamorous mile to whoever is standing in your building.

That last mile is where outcomes live. It always has been. SaaS was a workaround for a world where building software was expensive, so you rented the average solution and bent your process around it. Now that building is cheap, the average solution is a worse deal than it looks, because the specific solution someone actually needs is within reach. Presence lowers the cost of the layer. It raises the relative value of the person who builds the specific thing on top.

What this looks like in practice

Take a claims operations team at a mid-sized insurer. They adopt Presence because IT wants one governed way to run agents. Good decision. Now they want an agent that triages incoming claims and drafts the first response.

Here is what Presence hands them and what it does not.

Presence gives them the runtime, the identity and permissions, the audit log, and the monitoring. What it does not give them: the definition of which claims are safe to auto-draft and which must route to a senior adjuster, the connection to their thirty-year-old claims system that returns half its fields as free text, the rule that says a mention of injury always escalates, and the calibration loop that catches the agent when it gets confidently wrong on an edge case.

A forward-deployed engineer builds exactly those pieces, on top of Presence, for that team, and then hands it off so the claims lead can adjust the escalation rules without filing a ticket. The consequence is concrete: the agent handles the routine 60 percent, the adjusters keep the complex 40 percent, and the workflow survives a Monday when the claims system throws a schema nobody warned about. The platform made that build cheaper. It did not make it exist.

What changes, what stays the same, and the trade-off

What changes with Presence: the infrastructure work gets faster and safer. You spend less time building runtimes, auth, and monitoring from scratch. That is real, and you should take it.

What stays exactly the same: someone still has to own the gap between deciding to build an agent and the agent actually working inside your business. Nobody buys an agent platform. They buy fewer manual triages, faster response times, cleaner handoffs, a workflow the team trusts. Outcomes, not layers.

The honest trade-off is this. Presence makes it easier to stand up something that demos well, which means it also makes it easier to fool yourself. A system that demos well and goes unused is still a failure. The platform lowers the cost of the impressive-looking prototype and does nothing to raise the odds of adoption. Adoption is a design choice made by someone who thought about the people who have to use the thing, not a feature you switch on.

So the right way to read Presence is not "the labs will handle deployment now." It is "the labs just handed you a much better foundation, and the specific system on top of it is more your job than ever." The platform is the engine. Judgment is still the product. The hard part is still deciding what should exist and which trade-offs are worth making, and no lab is going to make those calls for your business.

If you have a problem, if no one else can help, and if you can find them, maybe you can hire Nyyon.