Designing Guardrails for AI Agents: Lessons from the OpenAI Presence Announcement

Adopting an AI agent is not just a matter of determining what the model can do.

Organizations must also translate policy questions into an operational design: what the agent may do, which actions require case-by-case approval, and when the agent must stop and hand the interaction off to a human.

On July 22, 2026, OpenAI announced OpenAI Presence, a managed enterprise platform for building, deploying, operating, and continuously improving governed AI agents.

For voice and chat agents, Presence brings together policies and standard operating procedures (SOPs), guardrails, pre-approved actions, simulation and evaluation tools, and a Codex-assisted improvement process.

The announcement does not disclose the detailed technical implementation of the guardrails. Instead, it outlines the building blocks organizations need to operate enterprise agents in production. Using the design elements described in the public materials as a starting point, this article sets out the practical questions that organizations must resolve internally when deploying AI agents.

It is intended not only for companies considering Presence, but also for practitioners building guardrails with other vendors’ products or in-house systems. It does not attempt to provide a comprehensive overview of Presence’s pricing, speech-recognition accuracy, or other product specifications.

Presence as a Managed Enterprise Platform

By OpenAI’s account, Presence is not a standalone AI model but a managed enterprise platform for deploying AI agents for customer support and internal service requests.

The deploying organization defines what the agent may do, when approval is required, and when the interaction must be handed off to a human. Guardrails, OpenAI says, can step in when an interaction moves outside the boundaries the organization has set.

OpenAI says the platform also includes, as part of the same package, tools to simulate scenarios before going live and mechanisms to evaluate behavior after launch.

One more thing that stands out in OpenAI’s description is a continuous-improvement process built on Codex, OpenAI’s own coding agent. According to OpenAI, Codex—using a Presence plugin—investigates issues surfaced from production sessions, escalations, and quality signals, and proposes updates. The customer’s team then tests the proposed changes against the production version and, once they are approved, rolls them out in a controlled manner.

In other words, the announcement describes a process in which update proposals are created from signals gathered in production, then applied after testing and approval.

OpenAI says it has already deployed this platform on its own English-language phone support, where it resolves 75% of incoming inquiries without human help.

For now, Presence is offered as a limited general-availability program for eligible enterprise customers. OpenAI says deployments are led by its Forward Deployed Engineers (FDEs) and a small number of global system integrators, and that it is not yet available as a self-service product. Companies considering it are directed to contact OpenAI’s account team.

Separating Scope, Approval, and Runtime Enforcement

The first thing that caught our attention in this announcement was not model performance, but how permissions and approval points are structured.

When people hear “implementing guardrails,” they tend to picture a scheme in which a human pre-approves every single interaction. But that erodes the point of using an AI agent for high-volume, routine work in the first place.

The Presence announcement points to a different approach: rather than requiring human approval for every action, organizations define in advance the scope within which the agent may act autonomously, the conditions that require case-by-case approval, and the conditions that trigger a human handoff. As for guardrails, OpenAI says they can step in when an interaction moves outside the boundaries the organization has defined.

This separation allows organizations to focus human attention on exceptions, high-risk actions, and change approvals rather than reviewing every case.

We find it easier to organize this structure into four layers.

1. Policy — what is allowed and what is prohibited.
2. Authorization and approval — which actions can run autonomously, and which require case-by-case approval.
3. Runtime enforcement — whether prohibited actions or exceeded limits can actually be stopped.
4. Evaluation and change management — how evaluation before and after production, updates, approvals, and rollbacks are handled.

What matters in particular is distinguishing the guardrail decisions made within the agent platform from the permission controls enforced by the connected systems—CRM, payments, ticketing, and the like. For example, even if the agent determines that a given refund is within the allowed range, the impact of a failure or a wrong decision can only be contained if the connected system also enforces amount limits, eligible customers, action counts, identity verification, and write permissions.

This design depends on one prerequisite: the boundaries must be defined in concrete terms. If those boundaries remain vague, the system has no reliable criteria for identifying deviations, increasing both unnecessary interventions and missed violations. Defining those boundaries remains the deploying organization’s responsibility; vendor features cannot do it on their own.

At MIF, we treat analysis and recommendation, decision-making, and execution as distinct permission domains.

Human Approval Alone Does Not Guarantee Better Performance

In Presence’s improvement process, OpenAI says the update proposals Codex puts forward are applied only after the customer’s team tests and approves them.

Having a human approval step is important in itself, but it does not by itself guarantee that a human–AI combination will perform better.

In a systematic review and meta-analysis by Vaccaro and colleagues (Nature Human Behaviour, 2024), human–AI combinations outperformed humans alone on average, but underperformed whichever of the human-only or AI-only conditions performed better. In decision-making tasks, human–AI combinations also performed worse, on average, than the better standalone performer. That said, this study is mainly concerned with task performance; it does not directly evaluate safety or the change-approval process in Presence.

The limited takeaway is that adding a human to a process does not automatically create synergy. The study does not tell us what information should be presented to approvers in a Presence workflow.

From a change-management perspective, however, approvers should at least be able to review the proposed changes, the rationale for the change, the affected policies, test results, regression test results for existing scenarios, and rollback conditions. If the reason for a change, its scope of impact, and the evaluation results are not presented adequately, approval becomes a formality, and the safeguard of “a human verifies and approves” ceases to work in practice.

When evaluating a product, it is worth examining exactly what information is presented to approvers. The risks involved vary from case to case, but the shape of change management—drafting a change, testing it, and applying it only after a human approves—mirrors the way we run our own content operations.

How to Interpret the 75% Figure

The 75% figure also requires careful interpretation.

OpenAI says that, on its own English-language phone support, it resolves 75% of incoming inquiries without human help.

But this is a figure OpenAI reports for one of its own support channels; it should not be treated as a benchmark for typical Presence deployments. The share that can be resolved varies widely with the industry, the complexity of the inquiries, and how well existing FAQs and knowledge bases are maintained.

The target language and channel are stated, but the criteria for what counts as “resolved,” the exact measurement period, the mix of inquiries, and any exclusions cannot be confirmed from the announcement. This 75% is a figure published by OpenAI, and—at least in OpenAI’s official announcement—there is no description of the measurement method or of any third-party verification.

When considering deployment, organizations should ask the vendor for simulation results under conditions that closely resemble their own inquiry mix.

Three Control Layers to Define Before Deployment

When deploying an AI agent with guardrails, the following framework can help distinguish what should be configured in the product from what the adopting organization must establish internally.

This is only an example; where the lines are actually drawn is something each organization decides according to the size of the risk in the work, how easily an action can be undone, and its own organizational setup.

Control layer	Primary responsibility	Key questions
Business rules and governance	Allowed actions, prohibited actions, the conditions that require case-by-case approval, and the conditions for handing off to a human	Are exception conditions made concrete? Are the approver, the response deadline, the handling when the approver is unavailable, and periodic reviews all decided?
Agent operations platform	Applying policies and SOPs, simulation, evaluation, deviation detection, notification, escalation, and change management	How are misses and over-intervention evaluated? Does processing stop when a control fails? Can you compare behavior before and after a change? Are staged rollout and rollback possible?
Connected systems	Restricting what information can actually be read and written, and what actions can be performed	Does it follow least privilege, with read and write separated? Are transaction and frequency limits, allowlists, identity checks, and access restrictions enforced in the connected system, and are actions recorded in audit logs?

What matters here is not treating detection by guardrails and enforcement by connected systems as the same thing.

Even when the boundary decision within the agent platform is wrong, you need a structure in which the connected system’s authorization, amount limits, allowlists, and action-count limits can contain the impact.

Guardrails do not replace identity management, access control, input validation, auditing, or the means to stop and recover.

Conclusion

The practical takeaway from the Presence announcement is that guardrails should not be treated as a single feature; they need to be designed as a combination of policy, action permissions, case-by-case approval, runtime enforcement, escalation, evaluation, and change management.

Vague boundaries increase both unnecessary intervention and missed violations. And if the connected systems’ permissions are too broad, the impact of a wrong decision by the agent cannot be contained.

As a first step in considering deployment, we recommend documenting the following five items for each use case: the information the AI can view, the actions it can run autonomously, the actions that require case-by-case approval, the conditions under which it must always hand off to a human, and the actions to prohibit or restrict in the connected systems.

When evaluating an agent operations platform, including Presence, organizations should look beyond whether guardrails exist. They should determine where each condition is defined, where it is enforced, and how proposed changes are tested, approved, rolled out, monitored, and rolled back.

Sources and Verification

This article was written on July 23, 2026, drawing primarily on OpenAI’s official announcement “Introducing OpenAI Presence” (July 22, 2026) and on “When combinations of humans and AI are useful: A systematic review and meta-analysis” by Michelle Vaccaro, Abdullah Almaatouq, and Thomas W. Malone (Nature Human Behaviour, vol. 8, pp. 2293–2303, 2024).

Performance figures such as the 75% for Presence are values published by OpenAI and do not indicate a general effect of adoption.

Availability terms, covered regions, features, pricing, and the like may change going forward.

For the latest information, please refer to OpenAI’s official announcement.