From Prompting to Production: How Codex-Style Agents Are Learning to Do Real Work

A model that can respond intelligently in a single turn is useful. A model that can sustain coherent reasoning, maintain context, use tools, recover from errors, and pursue a goal over minutes, hours, or even days is something categorically different. It begins to resemble not just a conversational system, but an operational agent.

This is the broader context behind some of the recent updates we have made to the Agents SDK. The motivation is straightforward: as models become better at long-horizon work, developers need infrastructure that allows those models to operate reliably, safely, and flexibly in real production environments.

One of the clearest examples of this transition is Codex, our agentic coding tool. Many people already know Codex as a system that can help build software, implement features, perform refactors, write tests, migrate codebases, and handle complex engineering tasks from beginning to end. In ordinary use, you might see Codex work for several minutes, perhaps up to an hour, depending on the task. With goal-driven workflows, however, we have seen much longer trajectories. Internally, people have run Codex on tasks lasting days, and in some cases up to a week.

That matters because real engineering work is rarely a single-step problem. Building a feature often requires reading a repository, understanding its architecture, locating relevant abstractions, modifying multiple files, running tests, interpreting failures, making corrections, and then validating the result. A model must not only generate code; it must sustain a chain of purposeful action. Codex is interesting because it demonstrates that models can increasingly operate across this entire workflow rather than merely assisting with one narrow part of it.

Another example is our Codex-powered security agent. Security work is a domain where long-horizon reasoning is especially important. Finding a vulnerability in a repository is not the same as matching a string pattern or running a static scanner. It often requires understanding legacy code, tracing control flow, identifying implicit assumptions, validating exploitability, and then proposing or implementing a remediation. The security agent uses agentic reasoning to analyze repositories, including our own code and code that we depend on, in order to find, validate, and help remediate complex vulnerabilities.

This is precisely the kind of problem where models are becoming more valuable. They can read large bodies of code, form hypotheses, inspect edge cases, and iterate. They are not perfect, and they still require strong evaluation and oversight, but their ability to perform structured investigation is improving rapidly.

A third example is our internal data analysis agent. This agent combines Codex-style table and file understanding with product knowledge, allowing it to answer data analysis questions that previously required substantial manual effort. In the past, if I wanted to know how many people were using the Agents SDK, or how many requests came through the Responses API two days ago, I might have had to spend an hour finding the right tables, writing SQL, debugging the query, checking assumptions, and formatting the result. Now I can often ask the question directly, and a few minutes later I have a useful answer.

The important point is not simply that the agent writes SQL. The more significant point is that it connects product context, data context, and analytical reasoning. It can move from a natural-language question to a concrete investigation. That is a much more powerful abstraction than a traditional dashboard or a one-off query.

However, there is a hard reality behind all of this: building production-grade agents is still difficult.

The first major challenge is performance. It is not enough to connect a model to tools and hope that it behaves intelligently. Different models have different strengths, different tool-use patterns, different context-management requirements, and different failure modes. As models become more specialized, they are increasingly optimized for particular harnesses and environments. That creates a tension. On one side, developers want flexibility: they want agents that can work across models, providers, infrastructures, and workflows. On the other side, maximum performance often requires staying close to the distribution in which a model was trained or optimized. Balancing those two demands is nontrivial.

The second challenge is runtime management. Modern agents, especially computer-using agents, do not merely produce text. They interact with files, repositories, containers, sandboxes, browsers, terminals, databases, APIs, and other external systems. Once an agent is doing real work inside an environment, the environment itself becomes part of the computation.

This raises difficult engineering questions. Where does the agent run? What happens if the container dies? What happens if the sandbox expires? Was there important state inside that environment? Can the agent resume? Can we snapshot the environment? Can we rehydrate it somewhere else? Can we preserve enough information for the agent to continue without corrupting the task?

These problems are not cosmetic. They are load-bearing. If an agent is running a long migration, a complex refactor, or a security investigation, losing runtime state can destroy hours of progress. Production agents require resumability, observability, isolation, and robust state management. Building all of that from scratch is time-consuming and complex.

The third challenge is customization. Developers rarely want a generic, brittle framework that works only for toy examples. They want to bring their own data, their own tools, their own skills, their own safety policies, and their own execution environments. They want agents that fit into existing systems rather than forcing those systems to conform to an abstract framework. In practice, the most useful agents are deeply adapted to their domain.

This is why the Agents SDK is important. The goal is to provide an open-source, transparent, and customizable framework powered by a Codex-style harness, while allowing developers to decide where their agents actually run.

A key update is the introduction of sandbox-using agents. In the simplest case, when people use Codex locally, the sandbox may effectively be their own laptop. The code, terminal, files, and execution context are all in one place. But in production, that is often not the right architecture. Developers may want agents to run in isolated cloud environments for safety, scalability, reproducibility, and operational control.

With the Agents SDK, developers can choose the sandbox infrastructure that matches their system. For example, they may already use platforms such as E2B, Modal, Cloudflare, Vercel, Docker, or local development environments. Rather than forcing everyone into one runtime model, the SDK is designed to support multiple sandbox providers as first-class execution targets.

This separation is important. The agent’s reasoning loop should not be tightly coupled to a single infrastructure assumption. A developer should be able to define the agent’s tools, policies, memory, skills, and task structure while still choosing the execution substrate that makes sense for their application. One company may prioritize ephemeral isolated containers. Another may prioritize serverless deployment. Another may need GPU-backed environments. Another may simply want local testing before moving to the cloud.

In this sense, the Agents SDK is not just a convenience layer. It is an attempt to make long-running, tool-using, production-grade agents more composable. It acknowledges that agentic systems have several distinct layers: the model, the harness, the tools, the sandbox, the runtime state, the developer’s data, and the operational policy. If these layers are entangled, the system becomes fragile. If they are separated cleanly, developers can build more reliable and adaptable agents.

I see this as part of a larger transition in software. In the first phase of modern AI, we focused on prompts. In the second phase, we focused on tools. Now we are moving into a third phase: durable agentic workflows. The central question is no longer simply, “Can the model answer this?” It is, “Can the model operate inside a real environment, pursue a goal, handle interruptions, recover from errors, and deliver a verifiable result?”

That is a much more demanding standard. It requires better models, but it also requires better systems engineering. Long-horizon agents need structured execution, strong isolation, state persistence, observability, evaluation, and domain-specific customization. They need to be powerful enough to do real work, but constrained enough to be safe and predictable.

Codex shows what this looks like in software engineering. The security agent shows what this looks like in vulnerability analysis. The internal data agent shows what this looks like in analytical workflows. The Agents SDK is our attempt to give developers the foundation to build similar systems in their own environments.

The deeper point is that AI agents are becoming less like autocomplete and more like computational coworkers embedded in operational systems. They still need supervision, constraints, and careful design. But their trajectory is clear: they are becoming capable of longer, more coherent, more consequential work.

That is why production-grade agent infrastructure matters. The future will not be built by models alone. It will be built by models connected to the right harnesses, the right tools, the right sandboxes, and the right runtime abstractions. The Agents SDK is designed for that future: a future where agents do not merely generate answers, but complete real tasks end to end.