Why OpenAI's Presence Ships Only via Forward Deployed Engineers — The FDE Signal for Enterprise AI
OpenAI won't let enterprises buy its new Presence agent off the shelf — it deploys only through Forward Deployed Engineers and systems integrators. That decision is a signal: as models commoditize, the hard part (and the margin) moves to deployment. Here's what the FDE shift means, and how any company can reuse the playbook.
When OpenAI launched Presence, its new real-time agent for enterprises, it did something telling: it refused to sell it as a self-serve product. Presence ships only through OpenAI's Forward Deployed Engineers (FDEs) and a handful of systems integrators. The reason isn't caution for its own sake — it's that the models themselves are commoditizing, and the real gap between "we bought an AI" and "the AI works in production" lives in deployment, which cannot be packaged into an API. This article breaks down why frontier labs are converging on forward-deployed delivery, and how any company — not just those with an OpenAI-sized team — can reuse the playbook.
What is OpenAI Presence, and why does it ship only through Forward Deployed Engineers instead of self-serve?
Presence is an enterprise-grade, real-time agent that works across voice and chat, with early use cases in customer service, outbound sales, and high-stakes internal workflows. What makes it worth studying isn't the feature list — it's the delivery model. As The Register reported, OpenAI stated plainly: "Deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators. Presence is not yet available as a self-serve product."
OpenAI isn't asking customers to trust something it hasn't run itself. According to OpenAI's own launch announcement, it has been dogfooding Presence on its English-language phone support line, where the agent verifies a caller's identity, pulls in account context, and executes approved actions — handling billing, account changes, and eligible refunds — before handing off to a human when a request needs one.
The takeaway for enterprise buyers: even the lab that built the model doesn't believe you can bolt an agent onto high-stakes workflows without engineers in the room. That's the whole point.
Why are frontier labs moving to forward-deployed delivery — and where does the money go once models commoditize?
The economics explain the shift. As frontier models converge in capability, raw model access becomes a commodity, and differentiation — along with margin — migrates to the "plumbing": the integration, deployment, and orchestration work that turns a capable model into a working system. The Register summed up the logic in a single line: "As AI models become commoditized, maybe there's margin in the plumbing."
OpenAI is building for exactly that reality. Presence is delivered by its consulting arm — the OpenAI Deployment Company and Forward Deployed Engineers, a "tech installation workforce" that debuted last year and, per the same report, was bolstered by OpenAI's acquisition of consultancy Tomoro in May. You can see that consolidation first-hand on Tomoro's own site, which now states it "is now the OpenAI Deployment Company." A frontier lab buying a consultancy to expand its deployment workforce is not a side note; it's a statement about where the durable value sits.
This is the thesis 6am has argued from the start: the model is the raw material, and the value is created at the point of deployment. (For the underlying definition of the model, see what value-based FDE delivery actually means — that piece defines the model; this one is the news-driven sequel showing a frontier lab adopting it.)
What's the difference between FDE delivery and traditional IT outsourcing?
Forward-deployed delivery is not "outsourcing 2.0." Traditional outsourcing bills against hours or deliverables, keeps a hard vendor–client boundary, and ends when the project ships. FDE delivery embeds engineers inside the customer's team, aligns on business outcomes rather than tickets, keeps iterating after go-live, and turns every failure into reusable capability. The distinction matters because AI deployment is high-uncertainty work that needs deep business context — precisely the kind of work a fixed-scope contract handles badly.
| Dimension | FDE Delivery | Traditional IT Outsourcing |
|---|---|---|
| How it's billed | Aligned to business outcomes / value | By hours or deliverables |
| Relationship to the customer | Embedded in the team, shared goals | Vendor–client, spec-and-sign-off |
| Iteration | Continuous tuning after launch, co-evolves | Ends when the project is delivered |
| Knowledge | Bad cases become reusable capability | Lost when the project closes |
| Best fit | High-uncertainty AI deployment needing deep context | Well-specified, spec-able engineering |
The anchor for this table is the fact The Register surfaced — that OpenAI leads Presence deployments with its own FDEs and integrators rather than a self-serve product. The conceptual contrast is methodology, and it's why "just buy the API" quietly fails for the workflows that matter most.
Why does enterprise AI deployment need people on the ground at all?
Here's the reverse-engineered answer: if even OpenAI won't let enterprises stand up agents on their own, then "we bought a model" is nowhere near "we deployed it." The failure data points the same way. Gartner has predicted that by 2027, half of the organizations planning to shift customer service to AI will abandon those plans (as reported by The Register). Half. The prediction is about scale, not cause — but in our experience the projects that stall rarely fail because the model can't hold a conversation. They fail in deployment: grounding the agent in real systems, handling the edge cases, and owning the accountability when it acts.
That's why we'd argue for people on the ground. When no one bridges the business and the technology, AI initiatives are, in our experience, far more likely to stall before they reach production. For a fuller treatment of the failure modes, see why enterprise AI deployment is hard.
How can a company reuse the big labs' FDE playbook without an OpenAI-sized team?
You don't need to build an OpenAI-scale deployment company to copy what makes it work. The pattern reduces to four moves:
- Diagnose the real bottleneck first. Start from the business constraint, not the tool. Find the workflow where an agent would actually change the numbers.
- Put outcome-aligned engineers in the room. Whether internal or an external FDE partner, the people doing the work should be measured on the business result, not hours billed.
- Start with one high-value, high-risk workflow. OpenAI began with its own phone support before selling Presence outward. Prove it on something that matters, then expand.
- Turn every bad case into reusable capability. The compounding advantage isn't the first deployment — it's that each failure hardens into knowledge the next one reuses.
If you're not sure which workflow to start with, the fastest way to find out is a few minutes with 6am's free AI diagnosis — it surfaces the highest-value place to deploy first. Teams that want to build the capability in-house can start with our courses.
Mini FAQ
Is OpenAI Presence available as a self-serve product? No. Per The Register, "Presence is not yet available as a self-serve product." Deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators.
Why did OpenAI acquire Tomoro? To expand its deployment workforce. The Register reports OpenAI's Forward Deployed Engineering / consulting arm "was bolstered by the acquisition of consultancy Tomoro in May," and Tomoro's own site now describes itself as "the OpenAI Deployment Company" — a signal that the lab sees durable value in deployment, not just the model.
What does "margin in the plumbing" mean for enterprise AI? As models commoditize, differentiation and profit shift to integration and deployment — the "plumbing." For most companies, that means the payoff comes from how well AI is deployed, not from which model is bought.
More questions on how AI actually lands in production? See our FAQ.
