OpenAI Releases Agents API: Build AI Agents With Sessions

OpenAI Releases Agents API as a production-ready layer that surfaces the same managed infrastructure the company runs internally for persistent, multi-turn AI agents. For most practitioners who have built agents on bare completions endpoints, the problems are familiar: manually serializing conversation history, replaying it on every request, writing an orchestration loop to handle sequential tool calls, and rebuilding context-overflow logic in every project. The Agents API moves all of that complexity server-side. You define what your agent does; the platform manages how it stays alive across turns, compacts its memory, and coordinates tool use. For teams that have spent real hours fighting state management and brittle history replay code, that shift in responsibility is the most concrete change this API delivers.

The structural change matters beyond convenience. Tools and sessions are first-class primitives in the Agents API, not afterthoughts layered onto a stateless endpoint. That design lets teams build agents that genuinely persist over time, reach live data through MCP servers, and run in either OpenAI-hosted compute or their own infrastructure, depending on what the application actually requires.

What Is the OpenAI Agents API?

The OpenAI Agents API is a developer interface that provides managed, server-side infrastructure for building software agents with durable sessions, automatic context compaction, and coordinated tool use across multi-turn conversations. Unlike the Chat Completions endpoint, which returns one response per request and leaves all state management to the caller, the Agents API maintains session state between turns and handles the execution loop between the model, its tools, and your application.

The two core primitives are agents and sessions. An agent is a configured instance with a role description, a set of permitted tools, and an assigned execution environment. A session is a persistent conversation thread tied to that agent. You create a session, receive a session_id, and send every subsequent message to that ID. The API appends each turn to the session’s server-side context, so your application transmits only the new input rather than re-sending the full history on each call.

This architecture directly resolves one of the most consistent problems in production agent development. Every team building on a stateless completions API ends up writing nearly identical boilerplate: a history array, a serialization layer, a context length check, and fallback logic when that check fails. The Agents API absorbs those responsibilities into the platform layer, leaving your code to focus on what the agent should accomplish. The Agents API reference documentation covers the full parameter surface for configuring agents and managing their tool sets.

How the Managed Codex Harness Runs Agent Orchestration

When OpenAI releases agents through this API, it opens the same managed execution harness it runs internally for coding agents and multi-step reasoning workflows. This infrastructure layer orchestrates the loop between the model, its tools, and session context. Before this API existed, developers building similar agents had to implement that loop themselves: call the model, parse the tool-use response, dispatch to the tool implementation, collect the result, re-inject it into the conversation, and repeat until the agent reached a terminal state.

The Codex harness performs this loop server-side. You supply the agent configuration and tool definitions; the harness manages invocation and continuation logic internally. Your application observes the loop through a streaming event interface that surfaces discrete events: tool invocations, tool results, intermediate model output, and agent completion signals. You can react to those events in real time without managing the underlying dispatch logic or building your own retry and error-handling layers around each tool call.

This becomes most valuable for agents that chain many tool calls in a single session. A coding agent that reads a file, runs a test suite, parses the failure output, applies a fix, and re-runs the tests executes five or more sequential tool calls in one agent run. Implementing that chain reliably in application code, with correct context management and error recovery at each step, is substantial engineering work. The managed harness handles that reliability by default, and the streaming event model lets you instrument the process without coupling your application to the execution internals. OpenAI’s Agents API announcement describes how the harness was adapted from internal tooling into the developer-facing API.

How Session Management Works in the Agents API

Session management in the Agents API keeps conversation context alive on the server across multiple turns, using a persistent session_id as the key. You create a session against a configured agent, store the returned ID in your data layer, and send follow-up messages to that ID whenever new input arrives. The API appends each message to the session’s server-side history, giving the model full conversational context without your application re-transmitting prior turns on each request.

Context compaction is the feature that makes long-running sessions practical in production. When accumulated history approaches the model’s context window limit, the API condenses earlier exchanges into a summary that preserves semantic content while freeing capacity for new messages. This process runs automatically, and the compaction behavior is configurable to match your use case. Interactive assistants often benefit from lighter compaction to retain conversational detail. Background agents executing many sequential tool calls can use more aggressive compaction without affecting output quality, since earlier conversational turns carry less weight than recent tool results.

Session continuity carries a product-level implication beyond raw infrastructure. A user who pauses a session and returns later resumes with the same agent state and full context, rather than a blank instance that has forgotten the work done so far. For coding assistants, research tools, or customer support agents, this is the difference between a stateful assistant and a chatbot that resets between page loads. The sessions guide and the session management reference cover session lifecycle events, expiration controls, and continuation patterns in detail.

Tool Coordination and MCP Integration for AI Agents

The Agents API treats tools as first-class session participants rather than optional extensions. At agent configuration time, you register the tools available to that agent: function-based tools that invoke your application logic, built-in capabilities the platform provides, and MCP servers that expose external data sources and operations through a standardized protocol. Once registered, the managed harness handles when the model requests a tool and how results flow back into session context, without requiring your code to manage those dispatches.

MCP (Model Context Protocol) integration reduces the connector code your team needs to write when agents must reach external systems. If your organization already runs MCP servers for internal knowledge bases, database access, or third-party API gateways, registering those servers with the agent configuration is more direct than rewriting each one as a custom function tool. The harness communicates with MCP servers using the protocol’s standard request-response format, injects tool results into the session, and continues the generation loop without exposing those protocol details to your application code.

Tool chains across a single session are where this coordination provides the clearest advantage. An agent that queries a knowledge base via one MCP server, extracts structured data through a function tool, and validates the result against a secondary MCP source executes that sequence inside the session’s managed loop. Your application observes each step through streaming events and can apply business rules at specific event types without writing the dispatch logic. The Agents API overview covers supported tool types, MCP configuration, and function tool schemas.

Hosted Sandboxes vs. Self-Managed Infrastructure

The Agents API ships with two deployment orientations for agent execution. OpenAI provides hosted sandboxes: isolated compute environments within OpenAI’s infrastructure where agents can run code, process files, and execute tasks requiring dedicated compute beyond model inference. OpenAI manages the sandbox lifecycle, so teams can run agents that need execution environments without provisioning servers or maintaining container infrastructure themselves.

The trade-off with hosted sandboxes is control over where data flows. Work processed inside a hosted sandbox travels through OpenAI’s environment. For applications with data residency requirements, regulated content such as healthcare records or certain financial data, or internal knowledge bases that must not traverse external networks, hosted sandboxes may not satisfy compliance obligations. This is a genuine architectural decision point, not a minor configuration choice.

The alternative is anchoring your agent’s tools and execution logic to your own infrastructure. In this configuration, model calls still route through OpenAI’s API, but your tools, MCP servers, and any code-execution environments run on servers you operate. Only the model interaction itself leaves your environment; the data your agent reads, processes, and writes stays within your own security perimeter. This suits agents embedded in enterprise workflows, those operating on proprietary data, or any scenario where your security team needs full visibility into what the agent accesses and produces.

Practical Application

Beginner: Use the Agents API overview documentation to create an agent with a role description and no custom tools. Call the session creation endpoint, store the returned session_id, and send a single message to confirm streaming works and your API key is configured correctly. This baseline confirms the connection before you add tools or expand the agent’s configuration.

Intermediate: Register one MCP server or function tool in your agent configuration and subscribe to the session’s event stream. Log each tool_call and tool_result event to verify the invocation chain before it reaches production. Persist session_id values in a database row keyed to your user or conversation ID so returning users resume their existing session rather than starting from a blank context.

Advanced: Configure context compaction thresholds to match your agent’s workload. For background agents running many tool-call cycles, apply more aggressive compaction and monitor session token consumption through the event stream to detect unusual context growth early. Trim tool output sizes where possible: verbose MCP server responses inflate session context faster than conversation turns and are a common source of unexpected compaction timing in complex multi-tool agents.

The Agents API marks a clear shift in where infrastructure complexity lives when building multi-turn agents. By absorbing session state, context compaction, and tool orchestration into a managed platform, it lets teams ship production agents without rebuilding the runtime layer in every project. The Agents API reflects what appears to be an emerging OpenAI pattern: surface internally proven infrastructure as a public API once it has been validated at scale. The choice between hosted sandboxes and self-managed infrastructure reduces to a data requirements question. Start with a minimal session, validate the loop, then layer in tools as your use case matures.

Chat Completions vs Agents API

feature	Chat Completions	Agents API
Session state	Manual, caller-owned	Server-side, durable
History replay	Required every request	Automatic via session_id
Context overflow	Custom trim logic	Auto compaction
Tool routing	Bespoke orchestration	Managed harness
Deployment	Stateless endpoint	Hosted sandbox or self-managed

Frequently Asked Questions