OpenAI Is Selling the Agent Factory
The Short Version
OpenAI is no longer just selling the agent.
It is selling the factory around the agent.
On July 22, OpenAI introduced OpenAI Presence, an enterprise product for deploying voice and chat agents across customer and internal workflows. The official page says Presence connects agents to company systems, policies, permissions, simulations, evaluations, guardrails, escalation paths, and human approval.
That is a lot of nouns.
It is also the point.
Presence is not "here is a smarter model, good luck."
It is OpenAI saying:
We will help you choose the workflow, connect the systems, define the policies, test the agent, monitor production sessions, propose improvements, and roll out changes under approval.
Very casual. The chatbot has become a managed operational system.
The useful story is not that OpenAI wants enterprise revenue.
Of course it does.
The useful story is that model labs are moving up the stack into deployment, quality control, systems integration, and business-process software. OpenAI already launched the OpenAI Deployment Company in May to embed Forward Deployed Engineers into organizations. Presence is the product version of that same thesis.
The model is no longer the whole sale.
The sale is:
Can we make this agent reliable enough to touch your customers, your claims process, your IT tickets, your procurement flow, and your internal systems without turning every incident into a meeting with legal?
That is a much harder business.
It may also be the real enterprise AI business.
Presence is not a wrapper
The lazy version of the story is:
OpenAI launched a customer-support agent.
Fine.
Another support bot.
Please hold while the future routes your issue to a knowledge base.
That undersells it.
OpenAI says Presence starts with a specific job: billing issues, insurance claims, employee IT requests, customer support, outbound sales, procurement, HR. The company receives only the knowledge and system access required for that job. The customer sets policies for what the agent can do, when it needs approval, and when a person should take over.
That is not a wrapper.
That is workflow architecture.
It means the product is less about the chat bubble and more about the surrounding machinery:
- standard operating procedures
- permissions
- tool access
- simulations
- evals
- graders
- guardrails
- escalation rules
- production monitoring
- change management
- human approval
Beautiful. We finally made agents enterprise-ready by surrounding them with the exact amount of process that makes enterprises enterprise.
But that process is not decoration.
It is the product.
Yesterday I wrote that long-running agents need brakes. Presence is the commercial version of the same idea, but aimed at businesses: not just "can the agent act?" but "can the company govern how it acts?"
The agent has to keep changing
One detail in OpenAI's post matters more than it looks.
Presence is designed to improve after launch.
OpenAI says production sessions and escalations reveal gaps. Codex can investigate those signals and propose updates. Teams can test proposed changes against the production version, then approve a controlled rollout.
That is the part that makes this different from old automation.
Traditional enterprise software often fails because it freezes a process that is already changing. The policy changes. The product changes. The customer changes. The support team invents an exception. The workflow slowly diverges from the implementation until everyone starts copying notes into a spreadsheet called "temporary."
AI agents make that drift faster.
An agent that talks to customers will encounter new edge cases every day. It will learn where the policy is ambiguous, where the knowledge base is stale, where users ask questions no one anticipated, and where the handoff to humans is too late or too early.
So the real system is not:
Agent launches.
Agent works.
Done.
The real system is:
Agent launches.
Agent fails in interesting ways.
The company learns.
The workflow changes.
The evals change.
The agent changes.
The approval process decides whether the change is allowed.
That loop is the product.
OpenAI is not just selling an agent that answers the phone.
It is selling a way to keep changing the agent after it answers the phone.
This is where SaaS gets nervous
Presence puts OpenAI in a strange position.
It is still a model company.
It is also becoming a systems integrator.
It is also becoming an enterprise software vendor.
It is also potentially competing with the companies that used to build on top of its models.
If Presence handles customer support, outbound sales, claims, IT help desk, HR, and procurement, then OpenAI is not only a supplier to software vendors in those categories. It is moving into their territory.
Not necessarily by replacing them.
At least not immediately.
Presence still needs company systems. It has to connect to CRMs, ticketing tools, identity systems, policy databases, call-center stacks, knowledge bases, billing systems, HR tools, and whatever terrifying internal app was built in 2014 and somehow still runs payroll.
So the likely near-term shape is integration, not total replacement.
But the strategic pressure is obvious.
If the agent layer becomes the place where customer conversations happen, then the agent layer starts to own the workflow. The underlying SaaS app becomes one of the systems the agent uses.
That changes power.
The question for SaaS companies is no longer only:
Can we add AI features?
It is:
Do we remain the system of work, or do we become a tool inside someone else's agent?
Very fun question to bring to the next board meeting.
OpenAI wants deployment data too
There is another subtle piece here.
OpenAI says Presence was developed in collaboration with its Research team, and that generalized insights from deployments inform research and product development.
That makes sense.
It is also strategically important.
The companies that see real agent deployments will learn what agents actually fail at.
Not benchmark failures.
Real failures:
- customers who phrase the same problem five different ways
- policies that contradict each other
- tools that return weird states
- approval rules that are too strict
- escalation paths that are too slow
- agents that sound confident but miss the actual issue
- humans who override the agent for reasons the eval did not capture
That is incredibly valuable feedback.
The model lab that operates the deployment layer gets a better map of where agents need to improve. It sees the business cases, the failure modes, the workflows, the integrations, and the places where companies are willing to pay.
That is a data advantage.
Not necessarily training-data in the narrow sense.
A product-learning advantage.
Presence turns enterprise deployment into a feedback loop for the lab.
Limited availability is part of the signal
Presence is not self-serve.
OpenAI says it is available to eligible enterprise customers through a limited general availability program, with deployments led by OpenAI Forward Deployed Engineers and select global systems integrators.
That matters.
If this were a normal SaaS feature, the button would say "Start free trial."
Instead, it says: talk to your account team.
That is not just enterprise sales theater. It tells you what the product still requires.
It requires integration work.
It requires policy mapping.
It requires access reviews.
It requires eval design.
It requires change management.
It requires human owners.
The absence of self-serve is a useful honesty marker. Production agents are not yet plug-and-play for serious workflows. The market keeps saying "agents." The work keeps saying "implementation."
That is why OpenAI's Deployment Company matters. The lab is building a services arm because the model alone does not produce the outcome.
The frontier capability is necessary.
The deployment muscle is what makes it billable.
What buyers should ask
Presence may be genuinely useful.
It also raises the right buyer questions.
If a company brings an AI lab into customer support, claims, HR, IT, sales, or procurement, it should know:
- Who owns the SOPs and policy definitions?
- Which systems can the agent read or modify?
- Which actions require approval?
- What counts as a successful resolution?
- Who designs the evals?
- Can the customer export logs, evals, prompts, and policy rules?
- How are proposed agent changes reviewed?
- Can another vendor run the same workflow later?
- What happens if OpenAI changes the underlying model?
- What happens if the customer wants to use a non-OpenAI model for part of the workflow?
- Who is accountable when the agent follows policy but the policy is wrong?
That last one will matter.
Enterprise AI will fail in boring ways.
Not always because the model hallucinated.
Sometimes because the policy was unclear, the integration was brittle, the approval path was wrong, or the business process was already a mess before the agent arrived.
The agent will not magically fix that.
It will reveal it at scale.
The bottom line
OpenAI Presence is not the biggest AI model story of the week.
It may be the more important enterprise story.
It shows that the frontier labs are no longer content to be intelligence suppliers. They want to own the deployment layer: the policies, evals, guardrails, escalation paths, workflows, and improvement loops that turn a model into something a company can put in front of customers.
That is where the money is.
That is where the lock-in is.
That is where the failures will be.
The agent race is not only about who has the best model.
It is about who owns the factory that turns models into work.