With Presence, OpenAI named the real enterprise problem out loud — and then shipped the discipline for it.
The framing, in OpenAI's own words: the challenge is no longer proving that an agent can work, it is making one reliable enough for high-value production work, and keeping it reliable as products, policies, and user behavior change [1]. That is drift, and it is the failure mode a demo never shows. Presence answers it not with a better model but with a loop — simulate and grade before launch, observe production after, and gate every change on a human [1]. For an architect, the loop is the product, and it is worth reading as an architecture.
The problem is drift, not capability
OpenAI is explicit that an agent which works at launch can become less reliable when the conditions around it move [1]. This reframes the whole job. Capability is assumed; the engineering problem is sustaining correctness under change — new policies, new products, new user behavior. Presence treats that as a first-class lifecycle concern rather than a post-hoc monitoring add-on, which is exactly the shift an enterprise architect has to internalize: you are not deploying a model, you are committing to keep a system correct over time.
Simulate and grade before launch
Before a Presence deployment reaches users, teams test it against common requests, edge cases, and higher-risk scenarios, with simulations and graders checking whether it reached the right outcome, followed policy, used tools correctly, and escalated when appropriate [1]. Guardrails intervene when an interaction moves outside the company's boundaries [1].
Read that as a spec, not a feature list. Four questions — right outcome, policy followed, tools used correctly, escalation appropriate — are precisely the acceptance criteria an architect should be able to state for any production agent, and OpenAI has made them the pre-launch gate. The guidance elsewhere reinforces the posture: OpenAI treats guardrails as a layered defense, combining model-based checks, deterministic rules, and moderation rather than trusting any single one [4]. Defense in depth at the boundary, validated by simulation before a real user is ever exposed.
The pre-launch gate is an acceptance test with teeth: right outcome, policy honored, tools used correctly, escalation when it should. State those for your own agents whether or not you deploy on Presence.
Read the production record, propose, approve
The discipline continues after launch, and this is the part an architect should study closely. Production sessions, escalations, and quality signals show where the agent is working and where it needs attention as conditions change; Codex, using the Presence plugin, investigates those signals and proposes updates; teams then test each proposed change against the version already in production before approving a controlled rollout [1].
Two properties matter. First, the system reads the production record to diagnose — the signal for improvement comes from what actually happened, not from a score alone. Second, and decisively, the improvement loop is proposal-gated: Codex suggests, a human tests and approves, and nothing rewrites itself unchecked [1]. OpenAI built the anti-pattern out on purpose — an agent that silently re-tunes itself in production is exactly the thing a risk committee cannot sign. The human gate is the attestation point.
The same instinct runs through OpenAI's developer surface. Tracing is built into the Agents SDK and on by default: every run emits a structured record of model calls, tool calls, handoffs, guardrails, and custom spans, inspectable in a traces dashboard [2][3]. The production record is treated as a first-class artifact — the thing you read to understand what the agent did and why a change is warranted. That is the substrate the whole improve-with-control loop stands on.
Least privilege, by job
Presence scopes access the way a security architect would. Each deployment starts with a specific job — resolving a billing issue, supporting an insurance claim, an IT service request — and the agent receives only the knowledge and system access that job requires [1]. The company sets the policies: what the agent may do, when it needs approval, when a person takes over [1].
Job-scoped least privilege plus explicit escalation is not a convenience; it is blast-radius control designed in at deployment. It also composes with the governance patterns OpenAI documents for builders — layered guardrails coupled with authentication, authorization, and access controls as standard security measures, not as a substitute for them [4][5]. The architecture assumes the agent is one component in a governed system, not a trusted actor unto itself.
The discipline OpenAI runs on itself
Presence is the productized form of a discipline OpenAI documents practicing on its own engineering. In its harness-engineering account, humans stay in the loop but work at a different layer of abstraction — prioritizing work, translating user feedback into acceptance criteria, and validating outcomes [6]. When an agent struggles, the team treats it as a diagnostic signal: identify what is missing — a tool, a guardrail, documentation — and encode that capability back into the repository, having the agent itself write the fix [6]. Testing, validation, review, feedback handling, and recovery are encoded directly into the system, and agents are given access to observability tooling — logs, metrics, traces — so they can self-validate rather than be trusted blind [6].
Two things make this more than a stunt. Invariants are enforced mechanically — custom linters and structural tests in CI — rather than requested politely, so the guardrails hold whether or not the model cooperates [6]. And OpenAI is candid that the results depend heavily on the investment made and should not be assumed to generalize without similar effort [6]. That candor is the tell of a real practice, not a demo. The same acceptance-criteria-and-feedback loop Presence offers an enterprise is the one OpenAI runs on itself — encoded into the environment, enforced deterministically, and read back from the trace. An architect can borrow the pattern directly: state the invariants, enforce them where the model cannot argue with them, and make the record the thing you improve from.
Presence is the production discipline for trustworthy agents, shipped by OpenAI: simulate and grade before launch, read the production record after, propose improvements, and gate every change on a human. It answers drift — the failure a demo never shows — with a loop instead of a bigger model, scopes access to the job, and treats the execution record as the artifact everything else reads.
