What the OpenAI Agents API Changes About Building Long-Running Agents

For roughly the last year, building an AI agent meant building its plumbing too. You had to decide how it remembered context, called tools, ran code, recovered from failures, talked to other agents, and survived long tasks without blowing through the context window. And somewhere along the way you had to stop the whole thing from turning into an expensive pile of chained prompts.

That's starting to shift. OpenAI launched its Agents API as a public beta on September 10. It hands developers a version of the harness and infrastructure that already runs Codex. You define an agent, give it tools and an execution environment, and a managed harness takes over much of the operational work. This isn't mainly a model announcement. It's an infrastructure announcement, and for engineers that difference matters.

What changed in practice

Start with an ordinary LLM application. A user sends input, a prompt goes to the model, and an answer comes back:

User
  ↓
Prompt
  ↓
LLM
  ↓
Response

Then you add tools, so the model can decide to call one and the app feeds the result back:

User
  ↓
LLM
  ↓
Tool
  ↓
LLM
  ↓
Response

Then requirements keep growing. Now the model has to read a repository and edit its files, execute commands, look things up in docs, call APIs, keep track of events from hours earlier, hand subtasks to helpers, retry what broke, check its own output and leave artifacts behind. Your "simple AI feature" has quietly become an orchestration system, which is the exact problem the Agents API aims at. OpenAI's pitch is that an agent expected to run for a long time needs a harness underneath it: something to handle context, make tool use cheap, coordinate subagents, and stay dependable through a lengthy session. You provide the purpose, and OpenAI supplies much of the machinery.

Model versus runtime

The easiest way to read this change is to separate the model from the runtime. The model supplies intelligence. The harness supplies the environment where that intelligence can work. A simplified picture:

Your Application
                       │
                       ▼
                ┌─────────────┐
                │ Agents API  │
                └──────┬──────┘
                       │
              ┌────────┴────────┐
              │                 │
        Agent Harness       Model
              │                 │
       ┌──────┼──────┐          │
       │      │      │          │
    Tools  Context  Agents      │
       │      │      │          │
       └──────┼──────┘          │
              │                 │
              ▼                 ▼
          Execution         Reasoning
          Environment

That's a different abstraction from calling an LLM API. You're no longer asking a model for text. You're giving an autonomous software process somewhere to work.

A real workspace for the agent

One of the most important pieces is that you choose where the agent runs. That can be an OpenAI-managed sandbox, your own infrastructure or supported third-party environments, and the environment can supply the files, packages, skills and plugins the agent needs.

It matters because software engineering doesn't happen inside a prompt. A coding agent needs something closer to a project directory:

/workspace
   ├── src/
   ├── tests/
   ├── package.json
   ├── node_modules/
   ├── config/
   └── outputs/

It has to look over the project, change files, run the test suite, read the output, fix failures and run the tests again. The environment becomes part of the agent's architecture.

The harness is the interesting bit

OpenAI's example uses GPT-6 Astra, but the larger idea is the structure around the model. You configure an agent with a model, tools, an environment and multi-agent behavior. Conceptually it starts like this:

const agent = {
  model: "gpt-6-astra",

and continues with the tool list:

  tools: [
    "MCP",
    "web search",
    "custom functions"
  ],  multiAgent: {
    enabled: true,
    maxConcurrentSubagents: 3
  },  environment: {
    type: "sandbox"
  }
};

The abstraction to remember is a single equation:

Agent = Model + Tools + Context + Environment + Orchestration

That's much closer to how production software is actually assembled.

Long-running agents are a different problem

A chatbot may need to answer in five seconds, a coding agent may need five minutes, a research agent an hour, and an operations agent may watch and investigate something far longer. Engineering requirements change sharply as run time grows.

OpenAI says the Agents API has context management built for long sessions. As a session nears its context limit, the system can compact earlier material so the agent keeps working across several context windows. That's significant because context management has quietly become one of the biggest engineering headaches in agentic systems.

Picture an agent chasing a production incident. At the start it sees one symptom:

Service API is returning 5xx errors.

Then it collects evidence, step after step:

logs
↓
deployment history
↓
database metrics
↓
dependency changes
↓
Git commits
↓
error traces
↓
test results

After hundreds of tool calls the raw context gets enormous. If the agent simply forgets the early investigation, it may repeat work or decide wrongly. Long-running agents need something like state management in distributed systems, and building compaction into the harness shows how central the problem has become.

Tool calling turns into infrastructure

A powerful agent can have dozens or even hundreds of tools. Loading every tool definition into every request wastes context and raises cost. OpenAI says the Agents API includes tool search, so relevant definitions load only when needed. It also supports programmatic tool calling, where an agent runs several operations in parallel and processes the results before returning only the relevant information to the model's context.

That sounds like a small optimization, and it isn't. Take a developer agent that can reach these systems:

GitHub
PostgreSQL
Sentry
Jira
Slack
AWS
Docker
Browser
Filesystem
CI/CD
Documentation
Monitoring

Giving the model every definition every time is inefficient. A smarter flow works out which capability the task needs and loads only that:

User task
    ↓
Determine required capability
    ↓
Load relevant tools
    ↓
Execute operations
    ↓
Filter results
    ↓
Return useful context to model

It's basically dynamic dependency loading for agents.

Subagents change the programming model

The API also supports subagents. Instead of one agent working through everything in sequence, a main agent splits work into independent tasks:

Main Agent
                    │
          ┌─────────┼─────────┐
          │         │         │
          ▼         ▼         ▼
       Logs       Code      Database
      Agent       Agent      Agent
          │         │         │
          └─────────┼─────────┘
                    ▼
              Main Agent
                    │
                    ▼
              Final Analysis

This suits independent work. A production incident might need one agent inspecting recent deployments, another analyzing application errors and a third checking database performance, with the main agent merging the findings. OpenAI says the API supports several concurrent subagents, each with its own context, so work proceeds in parallel. That looks a lot more like distributed computing than classic prompt engineering.

More agents aren't automatically better

It's tempting to assemble something like this and assume the system gets smarter:

1 main agent
+ 10 subagents
+ 20 tools
+ 5 review agents

It can just as easily become slower, costlier and harder to debug. The right question isn't how many agents you can run. It's which parts of the problem are really independent. If three tasks can truly run in parallel, subagents make sense. If every step depends on the one before, parallelizing only adds complexity.

Agent design is turning into another form of software architecture, with dependencies, concurrency, state, retries, observability, failure recovery, cost, permissions and data boundaries all in play. The model is just one component.

MCP in this setup

The Agents API supports MCP too, so an agent can reach outside capabilities through MCP servers instead of having every integration hard-coded in the application:

Agent
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
       MCP           MCP           MCP
    GitHub Server  Database      Observability
        │             │             │
        ▼             ▼             ▼
     Repository      Data          Metrics

The result is more modular. The agent doesn't need to know how GitHub, your database or your monitoring system works inside. It needs to know which capability exists and how to use it, the same kind of abstraction engineers have been building for decades.

The sandbox joins your security model

Once agents run code, touch files and interact with external systems, the execution environment is a security boundary. Recent incidents have made this pressing: This week Anthropic reported one more cybersecurity test that went sideways: a Claude prototype reached outside systems it shouldn't have. In parallel OpenAI has faced scrutiny over unexpected agent behavior.

So "the model is safe, therefore my agent is safe" is the wrong thought. The real attack surface is a combination:

Model
  +
Instructions
  +
Tools
  +
Credentials
  +
Filesystem
  +
Network
  +
Execution environment

An agent with read-only database access is a different security system from one that holds this:

database write access
+
shell execution
+
internet access
+
production credentials

The API makes agents easier to build, which means developers have to get much better at defining what an agent can't do.

A new layer in the stack

For years applications were built as a frontend over a backend:

Frontend
   ↓
Backend
   ↓
Database

Then AI got added to the middle:

Frontend
   ↓
Backend
   ↓
LLM
   ↓
Tools

Agentic software pushes toward a stack with an agent runtime of its own:

Frontend
   ↓
Application
   ↓
Agent Runtime
   ├── Model
   ├── Context
   ├── Tools
   ├── Subagents
   ├── Sandbox
   ├── Memory
   ├── Verification
   └── Observability

The runtime now earns a place as its own architectural component, which widens what an AI engineer has to know. Writing good prompts is no longer sufficient. Systems engineering comes with the territory.

Skills worth building

If you're building AI applications today, these are the skills growing in value:

• Orchestration: following how an agent makes a plan, carries it out, hands off pieces and bounces back after errors.
• Tool design: building APIs and MCP servers that an agent can lean on without surprises.
• Sandboxing: keeping what the agent runs apart from your sensitive systems.
• Context management: deciding which information reaches the model, and at what moment.
• Evaluation: checking that the agent actually completed the task correctly.
• Observability: a trace of the agent's actions, the tools it used and the point where it went wrong.
• Concurrency: judging which work has to be ordered and which can happen side by side.
• Permission design: granting the minimum capabilities the job needs.

None of these is purely an AI skill. They're software engineering skills applied to autonomous systems.

The runtime becomes a product

What this announcement says about the field's maturity is the interesting part. First, AI APIs gave access to models. Then frameworks appeared to help build chains and agents. Now providers are shipping the surrounding machinery for autonomous agents as well. OpenAI describes the Agents API as built on the open-source Codex harness, with ongoing upkeep of that harness timed to its model releases. That frees teams from rebuilding the following:

context management
tool orchestration
subagent coordination
execution infrastructure
session handling

and lets them put more time into the product itself.

The trade-off of managed infrastructure

Managed infrastructure buys speed and may cost some control. If OpenAI runs the harness, you still need to understand what goes on between your request and the result:

Your request
    ↓
Agent
    ↓
Model
    ↓
Tools
    ↓
Environment

Production systems need strong observability and clear boundaries. Without them, an unexpected decision from an agent is much harder to debug than a normal API call, because the question stops being what the model answered and becomes what the agent did. Those are very different debugging problems.

From prompts to runtimes

The main takeaway is that the next generation of AI applications won't just be chat interfaces wired to LLMs. They'll be software systems where models reason, use tools, write and run code, delegate work, inspect results, recover from failures and keep going across long sessions. The model still counts, but the runtime around it may count just as much. The Agents API is an early sign of that move.

So the contest may move away from raw model quality and toward whoever builds the best machinery for converting that intelligence into work you can rely on. For engineers that's the more interesting problem. The valuable skill may no longer be calling an LLM but building the environment in which an AI can do useful work.