OpenAI Presence Gives Each Agent One Job and Only That Job's Keys. The Scoping Is the Product.

OpenAI's new enterprise agent platform starts every deployment with a single narrow task and the minimum access that task needs. That discipline is copyable even if you never buy the platform, and it says more than the launch does.

Read the OpenAI Presence announcement looking for the model and you will miss the actual design. There is no new frontier model here. What Presence ships is a rule: every deployment starts with one specific job, like resolving a billing dispute or an employee IT ticket, and the agent gets only the knowledge and system access that one job requires. Nothing more.

That sounds almost too plain to announce. It is also the most interesting sentence in the whole launch, because it inverts how most people build agents. The default instinct is to give the model everything and hope the prompt keeps it in line. Presence does the opposite. It fences the job first, then pours the model into the fence.

Why "can the agent do it" stopped being the question

For two years the enterprise pitch was a demo. Watch the agent book a flight, file a ticket, answer a customer. The demo always worked. The deployment usually did not, and the reason was never intelligence. It was accountability. Nobody could say what the agent was allowed to touch, when it should stop and ask a human, or who owned the outcome when it got something wrong in production.

Presence is OpenAI's answer to that, and the answer is structural rather than clever. The company describes it as a deployment platform, not a model, and the phrasing matters. A billing agent under Presence can look up an account, apply a documented policy, and take an approved action, and that is the ceiling. It cannot wander into the refunds system because refunds were not part of its job definition. The access boundary is drawn before the agent runs, at the point where a human decided what this specific deployment is for.

Here is my position. The scoping is the product, and the model is almost incidental to why this works. You could run a weaker model inside this same structure and still ship something a compliance team would sign off on, because the safety does not come from the model behaving. It comes from the model not having the keys to misbehave with. That is a design principle any team can copy, and most are not copying it yet.

What Presence actually assembles

Strip the announcement to its parts and you get six of them working together, per OpenAI's own description: policies and standard operating procedures, guardrails, a set of approved actions, simulations, evaluation graders, and a Codex-powered improvement loop. None of those is a model feature. All of them are the operating scaffolding that a working agent needs and that a raw API call gives you none of.

The flow goes like this. Before launch, the team runs the agent against common requests, edge cases, and the higher-risk scenarios, and graders check whether it reached the right outcome, followed policy, used its tools correctly, and escalated when it should have. Guardrails sit ready to step in when a conversation moves outside the boundary the company drew. Only then does it go live.

After launch is where the design gets more opinionated. Production sessions and escalations show where the agent is failing, and Codex reads those signals and proposes changes to the agent's behavior. A human tests each proposed change against the version running in production, approves it, and rolls it out. The agent adapts without anyone rewriting it from scratch, and without anyone letting it rewrite itself unattended.

OpenAI is running this on its own English-language phone support line, and the number they publish is the strongest evidence they have. Within weeks it met or exceeded the benchmarks the company uses to grade its human support staff, and it now resolves about 75% of inbound issues with no human help. The Codex improvement loop cut human handoffs by 15 percentage points in ten days. Take the exact figures with the salt they deserve, since OpenAI is grading OpenAI here, but the shape of the claim is credible: a scoped agent with a tight feedback loop gets better fast on a narrow job.

Put this into practice without buying anything

The good news for anyone not on OpenAI's enterprise call list is that the valuable part of Presence is a pattern, and the pattern is free. You can build the same discipline around your own agents today. Here is the lowest-friction version.

1. Write the job down as one sentence before you write a prompt. Not "a support agent" but "resolves duplicate-charge disputes under $50 for existing accounts." If you cannot say it in one sentence, the scope is too wide and the agent will wander. This takes ten minutes and saves you a week.

2. Give it least-privilege access, not a master key. Scope the API tokens and database permissions to exactly that one job. A duplicate-charge agent needs read on transactions and one write path for the credit. It does not need the customer table or the refunds endpoint. Row-level security bound to the account in question beats a broad key every time.

3. Write the escalation rule as code, not as a hope. Decide the conditions that force a human handoff, disputes over a dollar threshold, any account flagged for fraud, any request the agent cannot map to its policy, and make those hard stops rather than suggestions in the prompt.

4. Build a grader before you ship. A dozen test conversations covering the common case, two nasty edge cases, and one adversarial attempt. Check whether the agent hit the right outcome and escalated when it should have. Run it on every change. This is the piece almost everyone skips, and it is the piece that tells you the agent got worse before your customers do.

5. Review the improvement loop like a pull request. If you let a model propose changes to your agent's instructions from production logs, treat each proposal as a diff a human reads and approves. Never let the loop close itself. That single rule is what separates Presence's design from a system that drifts.

You do not need OpenAI's platform to do any of that. You need the willingness to fence the job before you fill it, which is a habit, not a purchase.

Where this bites

The honest account starts with the delivery model, because it undercuts the word "product." Presence is not self-serve. Deployments are led by OpenAI Forward Deployed Engineers and select systems integrators, and interested companies "contact your OpenAI account team." That is a consulting engagement wearing a product label. The scaffolding is real and reusable, but the on-ramp is a sales call and a services timeline you cannot see the cost or length of from the outside.

The proof points are softer than they read, too. The named design partners are BBVA, SoftBank, and IAG, and OpenAI's own language has BBVA "exploring," SoftBank "testing," and IAG "exploring" the product. Those are pilots, not fleets of production agents resolving millions of calls. The only deployment running at real volume is OpenAI's own support line, graded against a benchmark OpenAI defined. That is not nothing, but it is one data point wearing a suit.

The Codex improvement loop deserves its own worry. An automated system reading production transcripts and proposing edits to how your agent behaves is a genuinely useful idea and a new instruction surface at the same time. The human approval gate is the whole safety story, and approval gates decay when the proposals are usually fine and the reviewer is busy. The tenth rubber-stamped change is where a policy gets looser by a notch nobody registered, and the system is built to make rubber-stamping easy.

And the lock-in is total by design. Your policies, your evaluations, your escalation rules, and your improvement history all live inside OpenAI's platform. The scoping discipline is portable. The implementation is not. If you build your whole agent operations practice on Presence, you have chosen a vendor for the layer that governs everything, which is exactly the layer you least want to be unable to leave.

What to watch

The real question Presence raises is not whether it works. On a narrow job with a tight loop, it clearly can. The question is who gets to have this. Right now the answer is large enterprises with an OpenAI account team and a systems integrator on retainer, while everyone else gets the pattern and has to build the scaffolding themselves.

That gap could close two ways. Either the operating scaffolding commoditizes into open tooling any team can run, or "agents you can actually trust in production" becomes a tier you buy rather than a discipline you practice. Watch which one happens over the next few quarters, because it decides whether the interesting part of this launch stays a principle anyone can use or hardens into a product only some companies can afford. If you have already fenced an agent to one job and watched it hold, I would like to know where the fence held and where it did not.

Sources: OpenAI, "Introducing OpenAI Presence"; Help Net Security, "OpenAI Presence connects AI agents to enterprise data with built-in guardrails"; VentureBeat, "OpenAI unveils Presence".