What does the new Agents API mean for the apps you use, and how does it fit alongside OpenAI’s other products? Wrote up a quick guide with easy to understand examples. https://t.co/fapVqhrwVw

ChatGPT, Codex, APIs, and agents: how it all fits together

You don’t have to open ChatGPT or the Codex app to use something powered by @OpenAI. Here’s what each option is for, from the apps you use to the tools developers build with.

That could show up in the apps you already use: an expense tool that sorts your receipts, a travel app that plans your weekend, or an engineering tool that traces a production failure across services, reproduces the bug, and opens a pull request with a tested fix.

Builders can connect OpenAI’s models and agents to those products’ own interfaces, data, and tools.

We just introduced the Agents API on September 10, adding a way to build with an agent that OpenAI operates. As of this writing, Agents API is in public beta.

Using an OpenAI product surface and building with OpenAI are different choices:

An API is an interface one program calls. An SDK is a library that helps developers work with software.

• The OpenAI SDK helps developers call APIs

• The Agents SDK provides an agent framework

These aren’t extra apps everyone needs to install.

First, what keeps an agent working?

An agent can search, inspect a result, and decide what to do next. That repeated sequence is the agent loop: call the model, use a tool when requested, return the result, and continue until it finishes or needs input.

The harness is the software managing that process, including tools, context, and rules. The model supplies reasoning; the harness connects it to work. OpenAI’s Codex agent-loop walkthrough explains the mechanics.

OpenAI, “Unrolling the Codex agent loop.” Tool results feed back into subsequent model calls.

OpenAI, “Unrolling the Codex agent loop.” Tool results feed back into subsequent model calls.

Let’s break this down simply: The same trip planner, built different ways

Note these are hypothetical app designs, with the required tools connected, not travel products included with an API or SDK.

Responses API: add model capabilities to a process

You paste a flight confirmation. The model extracts dates and flight numbers; the app’s existing code adds them to an itinerary.

The Responses API connects applications to models and tools. It can keep context across interactions, use built-in tools such as web search, and request actions through developer-provided functions.

It also supports multiple hosted tool calls within one request, so it can do more than extract a few fields. The developer controls the application workflow and handles application-side tool calls.

Responses API example

Responses API example

Agents SDK: the developer runs the planner’s workflow

Give the planner dates, a budget, and interests. It searches for options, asks questions, and revises the itinerary.

The Agents SDK supplies an agent loop and components for tools, checks, recording activity, and passing work between agents. One agent may be enough.

The developer connects travel search and calendar tools, defines the workflow, runs the software, and chooses how state is stored. This suits teams wanting deployment and storage control or other model providers.

Running the agent software does not mean hosting the model or keeping all data locally.

OpenAI also uses Codex and reusable skills to maintain the Agents SDK, including testing, release preparation, and pull-request review.

Agents SDK example

Agents SDK example

Agents API: OpenAI runs the agent behind the planner

The planner could offer a similar experience using Agents API.

The application starts a session with instructions and access to its tools. OpenAI runs the Codex harness, maintaining session state, managing context, and recovering from interruptions.

The developer still builds the app, connects its data, and decides what requires approval. OpenAI operates the service that keeps the agent running, useful for tasks with many steps or interruptions.

Agents API example

Agents API example

Remember: A custom app doesn’t require a custom agent harness. Its interface can look entirely different from ChatGPT or Codex.

For the traveller, all three designs could produce an itinerary to review. Whether the app reads your calendar, suggests flights, or allows bookings depends on what the developer connects and permits. The product name alone doesn’t tell you that.

Another example: turn receipts into a spreadsheet

With readable receipts and the required file tools, another hypothetical app could work like this:

• Responses API: the model extracts dates, amounts, and merchants; the app writes spreadsheet rows.

• Agents SDK: the developer runs a workflow that reads receipts, asks about missing details, and prepares a draft spreadsheet for review.

• Agents API: the app submits the processing task to a managed agent and lets users return to the session as work progresses.

Where Codex App Server and SDK fit

The Codex app is an interface where the Codex agent does the work. I recently co-wrote Codex as a platform about integrating that harness into other products.

App Server provides the protocol for custom Codex clients, including conversations, progress, and approvals.

Codex SDK is an option for coding automation, such as investigating a website bug and proposing a patch for review.

Your team runs Codex when using either. Neither is required for a general agent app.

Codex app server example

Codex app server example

The workspace is a separate choice

When an agent needs command execution or workspace files, it needs an execution environment, often a sandbox.

Even when OpenAI runs the agent, the workspace doesn’t have to be hosted by OpenAI. Agents API supports OpenAI-hosted, customer, or partner environments, and no environment when configured tools suffice.

Providing the workspace is separate from running the harness. With Agents API, OpenAI still operates the harness. The developer sets access and approval requirements.

OpenAI’s Agents API overview. This shows the OpenAI-hosted sandbox configuration. With your own environment, the sandbox sits on your side instead.

OpenAI’s Agents API overview. This shows the OpenAI-hosted sandbox configuration. With your own environment, the sandbox sits on your side instead.

What companies are already doing with Agents API

Nash offers a concrete example in delivery logistics. In the launch announcement, the company describes production agents whose work can span hours or days.

Agents API manages the session, context, coordination, and recovery; Nash supplies the tools and execution environment connected to delivery operations.

Other customers highlight different benefits:

• Long Lake uses its Nexus platform to deploy agents across fields such as residential services and architecture, retaining its own environment and interface

• WithCoverage says Agents API helps it avoid building custom infrastructure for some complex workflows

• SafetyKit reports 60% lower cost per case after migrating its case-review workflow, while maintaining its existing performance

What connects these examples is that the agent works inside the customer’s product or operations. The customer connects it to the business task while OpenAI runs the harness.

If you’re building, start with these questions

This decision tree starts with using an existing app versus building an experience into your own software:

Decision guide

Decision guide

Responses’ hosted tool loops are not the full managed Agents API harness. OpenAI’s practical guide recommends starting with the simplest approach that works.

What makes a good AI application?

You don’t need to build software to benefit. Next time you see an AI feature in an app, ask what information it can read, what actions it can take, and what you get to review: organized expenses, a weekend itinerary, or a proposed code fix with tests showing it addresses the bug.

Those answers help you understand how much work it can take on and where your judgment is still needed.