A rented operating layer needs portable records

OpenAI Presence puts the operating layer around a production agent inside the product being purchased. OpenAI says that layer includes the rules, tests, permissions, approved actions, monitoring, and human handoff that make an agent fit for one defined job. When the provider supplies both the model and that deployment work, the enterprise is renting an operating capability. Its controls and records need to remain usable after a provider change.

An agent here means software that can complete several steps and take actions a company has approved. OpenAI says each Presence deployment begins with a specific job, such as handling a billing issue or an employee service request. According to the announcement, the agent receives only the knowledge and system access required for that job, while the company sets what it may do, when approval is required, and when a person takes over.

OpenAI says Presence is not a self-serve software purchase. The company describes it as a deployed product in limited general availability for eligible enterprise customers, with deployments led by its Forward Deployed Engineers and selected global systems integrators. The announcement says OpenAI works with a customer to identify a workflow, connect the necessary knowledge and systems, establish permissions and policies, test the agent, and put it into production.

The build-versus-buy decision now includes the operating decisions that determine whether software may act.

The product includes operating judgment

OpenAI lists policies and standard operating procedures, rules or checks that can intervene, approved actions, simulations, evaluation tools, and a Codex-powered improvement process as Presence components. Before release to users, OpenAI says teams can test common requests, edge cases, and higher-risk scenarios, then use simulations and graders to check outcomes, policy compliance, tool use, and escalation behavior.

OpenAI describes continuing vendor involvement after launch. According to the announcement, production sessions, escalations, and quality signals identify where an agent needs attention. OpenAI says Codex investigates those signals and proposes updates, which teams can test against the production version and approve for a controlled rollout.

Those are OpenAI’s product statements, not independently verified performance claims. OpenAI is neither a Muniment customer nor an endorser. Presence is useful public evidence here because its announced delivery model places implementation expertise and continuing operational work within the vendor offering.

Portability starts before the first deployment

The portability requirement that follows is Muniment’s analysis, not a feature OpenAI claims for Presence. An enterprise buying this kind of operating layer should be able to export five things in usable form:

1. Policies in the form that governed each released version.
2. Approval rules, including who could authorize which action and under what conditions.
3. Test sets, expected outcomes, graders, and results tied to the version tested.
4. Activity records that show inputs, system access, actions, approvals, outcomes, and the deployed version.
5. Escalation definitions and handoff records, including the reason a person took over.

Portable means more than a download button. The records need stable identifiers, timestamps, version links, and formats another team can interpret without reconstructing the vendor’s internal system. A policy export without the approval rule it invoked is incomplete. A test result without the deployed version is not evidence of what reached users. An activity log without the action and authority behind it cannot answer who permitted the work.

These records also need a portability test. Before production, a team should prove that it can export the current policy set, rerun a representative evaluation outside the managed deployment, and trace one completed action from request through approval and escalation. That exercise identifies dependencies while the people who made the decisions can still explain them.

Renting execution does not transfer accountability

OpenAI says companies decide which policies, evaluations, and escalation rules remain consistent across deployments and which change by workflow or channel. That is already an ownership decision, even when the surrounding work is delivered as a service.

The earlier case for treating the operating layer as an owned asset focused on keeping workflows, evaluations, routing rules, and cost records under organizational authority while models change. Presence adds a concrete case to that argument. A provider can perform more of the deployment and maintenance work, but the enterprise remains accountable for what the agent was allowed to do and what it actually did.

Procurement should therefore ask for the export and replay path with the same seriousness it applies to system access and security review. A production agent can change providers. Its authority record cannot disappear during the change.