OpenAI's Presence Ships With Engineers, Not a Deploy Button: What the Gap Between Enterprise Agents and Git-Push Reveals

On July 22, 2026, the best-resourced AI agent vendor on the planet launched its enterprise agent platform — and you cannot sign up for it. OpenAI's Presence, now in limited general availability, bundles everything a production voice or chat agent needs: policies, guardrails, approved actions, simulation, session records, and a Codex-powered improvement loop that cut human handoffs by 15 percentage points in ten days on OpenAI's own support line. But there is no self-service console. Every deployment is led by OpenAI's Forward Deployed Engineers or a hand-picked systems integrator, sold "as a project rather than a product," priced per customer, per engagement.

Here is the thesis up front, because it is the answer this post owes you: Presence's headcount-shaped deployment model is not one problem, it is two problems wearing one trench coat. The first — bespoke integration, policy design, deciding what an agent is allowed to do inside a bank — is genuinely hard and genuinely resists self-service. The second — standing up the agent's backing services, wiring TLS and secrets, staging a rollout, watching logs, shipping the next iteration — is deploy-and-operate mechanics that a git-push platform made boring years ago. OpenAI is currently solving both with the same expensive resource: engineers. The interesting question is how much of that headcount is doing work a deploy pipeline should be doing instead.

What Presence Actually Is​

Strip away the launch-day framing and Presence is a managed enterprise program with an unusually honest shape. The facts, as reported at launch:

• Limited general availability, enterprise only. There is no signup page. OpenAI states that "OpenAI Forward Deployed Engineers and select global systems integrators lead each rollout."
• Sold as a project, not a product. Each engagement targets a single workflow — billing disputes, insurance claims, IT requests — rather than a general-purpose agent. Pricing is undisclosed and "set per customer and per deployment."
• A six-stage deployment process covering scoping, security review, testing and simulation, staged rollout, and iteration.
• Scoped-down agents by design. Agents receive only the knowledge and system access their task requires. Customers define operational rules, approval requirements for sensitive actions, and escalation triggers. Guardrails, session records, and structured escalation paths are built in.
• A Codex-powered improvement loop. Codex reads production sessions and human escalations, then proposes behavioral changes that are tested before rollout. On OpenAI's own English-language support line (1-888-GPT-0090), the agent now resolves 75% of inbound issues without human assistance, and that Codex loop cut human handoffs by 15 percentage points in ten days.
• Design partners, not scale customers. BBVA Mexico (voice banking support), SoftBank (Japanese-language frontline agents), and Australian insurer IAG (surge support during emergencies) are the named early adopters — all characterized as design partners.

The staffing behind this is its own story. OpenAI stood up a majority-owned deployment subsidiary — DeployCo — earlier in 2026, and bootstrapped it by acquiring London-based Tomoro, bringing roughly 150 experienced Forward Deployed Engineers and delivery playbooks from clients like Tesco, Virgin Atlantic, and Supercell. The company whose entire history is "expose a capability as an API and let developers figure it out" built a consulting arm, because for this category the API alone was not closing.

That is the launch. Now the decomposition.

The Decomposition: Which Half of the Engagement Actually Needs an Engineer?​

Take Presence's own six-stage process and its published feature set, and sort every line of work into two buckets: work that is bespoke by nature — it depends on the customer's business, systems, and risk tolerance, and no tool can decide it for them — versus work that is deploy-and-operate mechanics — the same for every customer, differing only in configuration.

The left column is the part that deserves the Forward Deployed Engineer. Nobody outside BBVA can decide which account actions a banking agent may take without human approval; that conversation is worth flying someone to Mexico City for.

The right column is a different animal. Standing up a tool server, wiring its secrets, giving it a stable HTTPS endpoint, rolling a change out gradually, rolling it back when the simulation flags a regression — none of that depends on the customer's business. It is the same work whether the tenant is a bank or a burrito chain, and it is precisely the work that git-push platforms — Heroku, then Render, then their self-hosted descendants — turned into a single command over the last fifteen years.

How do the FDE hours split between the columns? OpenAI doesn't publish that, so treat what follows as an argued estimate, not a measurement. But the shape of the six-stage process is telling: scoping and security review are front-loaded, one-time work, while testing, staged rollout, and iteration — the stages Presence explicitly names as ongoing — live almost entirely in the right column. The Codex loop makes this concrete: if the improvement cycle proposed enough changes to cut handoffs 15 points in ten days, someone (or something) shipped a tested change roughly every day. That cadence is a deployment pipeline's job description. Every iteration an engineer shepherds by hand is an iteration a pipeline should have shipped.

The Steelman: Why Headcount Is a Rational Answer Right Now​

Before dunking on consulting revenue, take the counter-argument seriously, because it is strong.

Gartner projects that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing failures of governance and operational discipline — exactly the left column of the table. The graveyard of 2025's agent pilots is not full of projects that couldn't get a container running; it is full of projects where nobody defined what the agent was allowed to do, nobody designed the escalation path, and the first hallucinated refund ended the program. OpenAI looked at that failure rate and concluded, reasonably, that shipping a console would produce forty-percent-cancelled deployments with its logo on them.

There is also an honest reading of the design-partner strategy: BBVA, SoftBank, and IAG are not customers so much as instruments. OpenAI is paying with engineer time to learn what enterprise agent deployment actually requires, the same way Palantir's original forward-deployed model turned embedded engineers into product requirements.

And the concession this post owes: a git-push deploy model does not solve the left column. No platform, ours included, can tell an insurer which claims an agent may approve. If your mental model is "self-service deploy makes the FDE unnecessary," the table above says otherwise — it makes roughly half of the FDE's job unnecessary, and it is the half that doesn't require their judgment.

But notice what the steelman actually defends. Every argument for headcount is an argument about the bespoke column. None of it explains why the mechanical column — the deploys, the rollouts, the logs — should also arrive as billable engineering hours. That half is only bundled in because Presence has no self-service surface to put it on.

The Same Right Column, as One Command​

Here is what the mechanical half of a Presence engagement looks like when it lands on a Render-compatible, git-push platform instead of an engineer's laptop.

An enterprise agent's footprint, stripped of mystique, is ordinary services: a webhook handler that receives conversation events, a tool server (increasingly an MCP server) that exposes the approved actions, maybe a retrieval sidecar. Each is a repo. Deploying one is:

git push production main

The platform builds the service, provisions TLS, injects secrets from its store, and exposes an HTTPS endpoint. Now map Presence's right-column stages onto that model, line by line:

• Codex proposes a behavioral change → the change is a commit on a branch. It has a diff, an author, and a review trail — the session-record audit story falls out of version control for free.
• Testing and simulation → a preview environment spun from the branch with production-shaped configuration. The simulation stage stops being a bespoke rig an FDE assembles and becomes a platform primitive.
• Staged rollout → a deploy with health checks and instant rollback. The "staged" part is progressive delivery, not an engineer watching a dashboard on a Tuesday night.
• Session records and monitoring → the platform's logs and metrics, queryable by the same automation that proposed the change.

The compounding effect shows up in the iteration cadence. Presence's own numbers say the improvement loop wants to ship roughly daily. Through an engineer-led process, each of those iterations costs coordination: someone schedules the rollout, someone watches it, someone documents it. Through a git-push pipeline, the Codex loop closes on itself — propose, test in preview, merge, staged deploy, observe, repeat — and the human in the loop reviews policy-relevant diffs instead of performing deployments.

This is also where the agent-as-operator framing stops being futurism and becomes a requirements list. An improvement loop that ships daily needs a platform whose state is machine-readable and whose deploy surface an agent can drive directly — not a ticket queue with an engineer at the end of it. That is the design bet behind Bex.co, the open-source, AI-native Render alternative: push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API and AI agents as first-class operators. The left column of the table stays yours — no platform can write your approved-action policy — but the right column becomes the same one-command path for an agent's tool server as for any other service you run.

What "We'll Deploy It for You" Predicts​

Read as a signal rather than a product, Presence says three things about where this market is.

First, the model was never the bottleneck — the deployment path is. OpenAI has the strongest models and effectively unlimited capital, and its answer to enterprise agents in 2026 is 150 acquired consultants and a six-stage manual process. That is what a category looks like before its deployment layer is standardized: mainframes had systems engineers, early websites had integrators, pre-Heroku web apps had ops teams. Each of those consulting layers was eventually compressed into tooling.

Second, the compression will be asymmetric. The bespoke column shrinks slowly — policy templates, approved-action libraries, and per-vertical playbooks will chip at it, and DeployCo's engagements are plainly the R&D for exactly that productization. The mechanical column can collapse fast, because the tooling already exists; it just isn't what Presence ships today. Watch for the tell: the day Presence grows a self-service console, its launch feature list will be the right column of the table above.

Third, the teams that don't get a Presence engagement — which is nearly everyone, at design-partner scale with undisclosed project pricing — still have to ship agents this year. For them the practical reading is straightforward: buy or build the judgment layer deliberately (scoping, policies, escalation — the part worth paying experts for), and refuse to pay headcount rates for the deploy layer, because that part is a solved problem with a git push in front of it.

The best-resourced agent vendor in the world just told you enterprise agent deployment isn't self-service yet. The half of that sentence worth internalizing is "yet" — and the half of the work worth automating first has been automatable all along.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with AI agents as first-class operators. Star the repo on GitHub or deploy your first agent's tool server today.

Sources​

• AI News: OpenAI Presence — enterprise AI agents, engineers included
• SaaS Sentinel: OpenAI Launches Presence, an Enterprise Platform for Voice and Chat AI Agents
• Koishi AI: OpenAI Presence Platform — Managed Enterprise AI Agents
• OfficeChai: OpenAI Deployment Company Acquires Tomoro, Gets 150 Forward Deployed Engineers
• Tomoro: Tomoro Acquired by OpenAI Deployment Company