OpenAI Agents API vs Agents SDK vs Responses API: What Should You Build On in 2026?

OpenAI's agent stack changed materially in September 2026. The new Agents API introduced a managed Codex harness for durable cloud agents, while the older Agents SDK moved into a feature-complete maintenance phase. The Responses API remains the lower-level surface for applications that want direct model calls or to own the agent loop themselves. These are not three interchangeable wrappers around the same thing: they place the runtime boundary in different places.

The architecture changed: choose a runtime boundary, not a library

The important decision is no longer simply “Which SDK should I install?” It is who owns the harness, the agent loop, durable session state, context compaction, recovery, execution environment, and application lifecycle.

OpenAI's current Agents overview makes this boundary explicit. The Agents API runs a hosted Codex harness and manages orchestration plus durable session state. The Responses API provides model responses and hosted capabilities while your application owns the surrounding agent loop. The Agents SDK runs the loop in your application and is now feature complete rather than the forward path for major new agent features.

The short comparison

1. Agents API: managed harness, durable cloud agent

The Agents API exposes the Codex harness through an OpenAI-managed service. OpenAI manages sessions, orchestration, context compaction, and recovery. Your application still provides tools and chooses the execution environment.

That last distinction matters. “Managed agent” does not necessarily mean “all compute runs inside OpenAI.” The Agents API architecture supports no environment, an OpenAI-hosted environment, or a self-hosted environment connected to the hosted harness. With a self-hosted environment, your application owns provisioning, reconnection, shutdown, and persistent files while the harness remains managed.

The Agents API is therefore a runtime service, not merely a request format. Sessions can persist, stream progress, receive additional tasks, use tools, work with files, and recover across long-running work.

What you gain with the Agents API

• A managed Codex harness instead of building and operating the main agent loop yourself.
• Durable sessions for work that spans turns and long-running tasks.
• Managed orchestration, context compaction, and recovery.
• OpenAI-hosted or self-hosted execution environments, depending on workload requirements.
• Streaming and webhooks for progress and lifecycle events.
• A platform direction that OpenAI explicitly recommends for new agent applications.

What you still own

• Your product and application server.
• Function-tool implementations and business logic.
• Authorization and policy decisions around your own systems.
• The execution environment lifecycle when you choose self-hosted compute.
• Evaluation, acceptance criteria, domain-specific guardrails, and the decision of what the agent is allowed to do.

2. Responses API: own the loop, use the platform primitives

The Responses API is the lower-level choice when you want OpenAI model and tool capabilities without delegating the overall agent runtime. OpenAI describes Responses as the recommended API primitive for new projects and as an evolution of Chat Completions with built-in tools, multi-turn state options, multimodal input, and agentic tool use.

A Responses request can itself invoke tools, but your application remains responsible for the larger workflow when you build an agent around it. That means your code decides how to persist application state, when to continue, how to recover, how to coordinate specialists, how to compact long histories, and how to represent resumable work.

This is not inherently inferior. It is the right boundary when agent behaviour must be deeply embedded in existing application logic, when you need a custom state model, or when a managed harness would hide control you actually need.

3. Agents SDK: supported, but no longer the default forward path

The Agents SDK remains an open-source framework for running agent workflows in your application. It provides agent definitions, tools, handoffs, guardrails, tracing, sessions, and the runner loop in TypeScript and Python.

But its strategic status changed. OpenAI now labels the Agents SDK feature complete: maintenance, security fixes, critical bug fixes, and compatibility work continue, but major new features are not planned. OpenAI recommends the Agents API for new applications.

That does not mean an existing SDK application should be rewritten immediately. It means the architecture should stop assuming that the SDK is where the next major agent-runtime capabilities will land.

Where the Codex SDK fits

The current choice is not a simple three-way fork. OpenAI's runtime overview includes the Codex SDK as the option for running the Codex harness in infrastructure you operate. That is architecturally different from both the hosted Agents API and the Agents SDK.

If your real requirement is “I want the Codex harness, but I need to operate it myself,” the Codex SDK is the surface to evaluate. If your requirement is “I want to own the loop around model calls,” evaluate Responses. If your requirement is “I already have a working Agents SDK application,” the existing SDK can remain valid while you plan against its maintenance status.

The Runtime Ownership Test

A useful architecture decision starts by deciding what your team must own. Score each requirement as either must control, prefer to control, or prefer managed.

A decision tree for new systems

What should not drive the decision

Migration is an architectural change, not an import rename

Moving from the Agents SDK to the Agents API changes ownership. In the SDK, the loop runs in your application. In the Agents API, OpenAI runs the harness and session while your application integrates through tasks, events, tools, and environment boundaries.

A real migration plan therefore needs to map session state, custom orchestration, handoffs, tool execution, approvals, storage, tracing, retries, failure recovery, environment lifecycle, and any provider-specific abstractions. Code volume may fall while operational assumptions change.

The migration inventory

• Agent definitions and instruction ownership.
• Tool definitions and where each tool executes.
• Handoffs, manager/specialist patterns, and subagent behaviour.
• Session identifiers, conversation state, resumability, and history retention.
• Human approvals and interruption semantics.
• Custom context trimming or compaction logic.
• Tracing, evals, observability, and production debugging.
• Self-hosted files, containers, private-network access, or other execution dependencies.
• Provider abstraction or non-OpenAI model dependencies.
• Retry, timeout, idempotency, recovery, and lifecycle assumptions.

Public beta changes the risk model

The Agents API is the recommended direction for new agent applications, but it is also in public beta. Those facts are not contradictory. Strategic direction answers “where is the platform going?” Beta status answers “how much interface and operational change should I budget for?”

For production systems, isolate the integration behind an application boundary. Keep domain state, permissions, audit data, and business rules outside vendor-specific session objects where possible. This makes it easier to absorb API evolution without turning the agent runtime into the source of truth for your entire product.

A practical default architecture

For many new OpenAI-native applications, a reasonable 2026 default is: Agents API for the managed harness and durable session, application-owned domain services and authorization, explicit function tools for business actions, and either OpenAI-hosted or self-hosted execution depending on data and compute requirements.

That keeps the agent runtime powerful without making it the owner of business truth. The application still decides what a user may do, which data is authoritative, which actions require approval, and how results are validated.

What would change this answer?

The recommendation changes if the Agents API adds or removes capabilities, exits beta with different contracts, changes environment or pricing boundaries, or introduces migration tooling that reduces ownership differences. It also changes if your application depends on provider portability, custom orchestration semantics, local-only execution, or a capability the hosted harness cannot support.

For an existing Agents SDK application, the answer also changes with migration cost. If the system is stable, well evaluated, and not blocked by the SDK's feature-complete status, immediate migration may create more risk than value. If the product roadmap depends on capabilities landing only in the Agents API, delaying migration can create a different kind of debt.

Limitations

This comparison focuses on runtime ownership and OpenAI's stated platform direction. It does not benchmark latency, quality, or total cost for a specific workload. Those properties depend on model choice, tool usage, environment, task length, caching, sandbox usage, and application architecture.

The Agents API is also new enough that production experience is still accumulating. A design should therefore be validated with representative workloads rather than chosen solely from product positioning.

Conclusion

The 2026 OpenAI agent decision is fundamentally about runtime ownership. Agents API means OpenAI owns more of the harness and durable-session machinery. Responses means your application owns the loop around platform primitives. The Agents SDK remains valid for existing systems but is no longer the default destination for major new agent-runtime features.

For a new application, follow the platform direction unless a real requirement pushes you lower in the stack. Start with the Agents API, move to Responses when you need to own the loop, evaluate Codex SDK when you need the harness in your infrastructure, and keep the Agents SDK where existing investments or temporary capability gaps justify it.

FAQ

Glossary

Primary sources and further reading