OpenAI has published a document on safety lessons learned from deploying models that reason over long horizons. The central point: when an agent works for minutes or hours on an objective, new security risks emerge during deployment that pre-release testing fails to catch.

The document’s thesis is concrete. The traditional “safety checkpoint” paradigm assumes you can test a model, certify it’s safe, and then release it. With long-horizon models this approach breaks down: risky behavior only manifests when the agent is running in production, with access to tools, in sessions that last a long time. Security becomes a continuous process of monitoring and iteration, not a final exam.

Why this matters to you. If you’re putting agents into production that run for extended periods, and we’ve covered what happens when things go wrong in this concrete case, OpenAI’s document names a problem you’ve probably already encountered. An agent that works fine in your ten-minute tests can behave unpredictably after an hour of execution. Pre-release checkpoints tell you how the model behaves in isolation; deployment shows you what it does when it has tools, memory, and complex objectives.

The practical implication is that designing an agent for production must include telemetry and runtime guardrails, beyond pre-launch testing. This already applies to anyone using Claude Code or Codex on long sessions: the point is building a process that observes and corrects while the agent works.

To understand how to structure these controls, the course lesson on costs, latency, and security addresses the jump from demo to deployment.

In detail

What came before.

Until now, standard practice for model safety followed a linear schema: training, testing on security benchmarks, red-teaming, certification, release. The model passed an exam and became “safe.” This approach works when the model responds to isolated single queries. It works much worse when the model must maintain coherent behavior over long horizons, with tools, memory, and objectives that change during execution.

What changes.

OpenAI’s document introduces a distinction that anyone building agents in production should keep in mind. Safety as checkpoint means: I test the model before release and, if it passes, I declare it safe. Safety as process means: I release with telemetry, monitor behavior during real execution, collect failure cases, and iterate. The second integrates the first with a layer the checkpoint cannot cover.

Risks that only emerge during deployment are a particular type. A model reasoning over long horizons can develop task-completion strategies that weren’t predictable from tests on short sessions. It can accumulate state in ways that change subsequent behavior. It can use tools in combinations a single test doesn’t explore. OpenAI’s document describes them as a structural category of risks inherent to the long-horizon paradigm, not as specific bugs.

The technical detail for those not doing research.

A “long-horizon model” is a model trained to reason over sequences of steps that can last minutes or hours, not seconds. The difference between an assistant answering a question and one that must complete an entire project: gathering information, making intermediate decisions, remembering what it already did, adjusting the plan. The surface of possible behavior grows with the horizon length, and the surface of risk grows with it.

The telemetry OpenAI describes as necessary is standard observability for those who’ve built distributed systems: logging agent actions, monitoring sequences of tool calls, detecting anomalous patterns in continuous behavior. Applied here to model behavior rather than backend service behavior.

Limitations of what we know now.

The document is a primary source from OpenAI on its own work. It’s honest about risks they’ve observed, but remains a technical post, not a peer-reviewed paper with repeatable metrics. It describes the practice of a single lab: what works for OpenAI may not transfer mechanically to other contexts, especially for those using open-weight models with less monitoring infrastructure.

The more practical question remains open: how much does it cost, in time and resources, to implement safety as process in production? OpenAI doesn’t provide numbers on this. For those building agents on small budgets, continuous telemetry can be a significant cost, and the document doesn’t help quantify it.