What OpenAI's Agents API actually gives you

OpenAI’s Agents API gives an application access to the managed harness behind Codex. OpenAI runs the agent infrastructure; your team still defines the question, connects the permitted tools and decides which results or actions need review[1]. The architecture choice is how much of that runtime you want to operate yourself.

An agent is a controlled loop around a model. The model proposes the next step. The surrounding runtime decides what it is allowed to do, runs a tool, returns the result and continues until the task reaches a defined stopping point. A swarm of sub-agents is one possible arrangement inside that loop. It is not the definition of an agent.

That distinction matters because the interesting work is usually outside the sentence the model writes. It is in the evidence it can inspect, the actions it can take, the state it carries, the permissions around those actions and the checks that decide whether the result is ready for a person.

Three choices, with different runtime owners

Managed Agents API

OpenAI operates the Codex harness, including sessions, orchestration, context compaction and recovery. Your application provides tools and chooses the execution environment[15]. This is a distinct API, with agent sessions, rather than a loose name for the products below.

Responses API

The lower-level model-and-tool interface. A team calling it directly owns more of the application’s loop and control flow[2]. It is useful when you need to assemble those choices yourself.

Agents SDK

An application-side toolkit for defining agents and running turns, tools, handoffs, guardrails and tracing[3]. Its Runner coordinates the loop in your application[5]; using it does not turn that application into the managed Agents API.

ChatGPT Workspace Agents are another product, for shared team workflows inside ChatGPT. Similar concepts do not give an API application the same identity, setup or permissions[4]. Choose the product before borrowing its configuration advice.

A paid-search investigation, with a boundary

Imagine a request: “Investigate the fall in paid-search enquiries last week and prepare a report for the performance meeting.” The following is a proposed architecture, not a deployed Meeno system and not a result from real data.

1. Define the contract.

   Record the site, channel, local-time window, enquiry event, comparison period, source systems and the decision the report will support.

2. Give the lead agent read-only tools.

   It can query approved analytics, retrieve the release log and read the measurement runbook. It cannot edit tags, publish a campaign or change a dashboard.

3. Let code reduce the evidence.

   A programmatic call groups events by day, checks the event definition and writes a small evidence file with filters and freshness attached.

4. Delegate only when the evidence requires it.

   A telemetry specialist can inspect a release change or a data-quality specialist can reconcile a missing day. Each returns a structured finding, uncertainty and source reference.

5. Assemble a report.

   The lead agent separates observed change, possible explanations, evidence still missing and suggested next checks. It does not call a correlation a cause.

6. Pause for the meeting owner.

   A human accepts the scope and decides what action to take. The run ends with a shareable report and its evidence bundle.

The interesting part is the contract and the stop condition. The agent is allowed to investigate, not to turn an uncertain explanation into a production change. That boundary makes the result easier to review and the next run easier to improve.

Untangle the names before you design the system

Model

The language model proposes text, a tool call or a next decision from the instructions and information it can see. It is the reasoning component, not the whole application.

Agent

In the Agents SDK, an agent is an LLM configured with instructions, tools and optional runtime behaviour such as handoffs, guardrails and structured output[3]. In plain language, it is a goal-directed participant inside a run.

Harness

The software layer that runs the session around the model. It turns a proposed tool call into an actual call, carries state between turns, applies permissions and decides how the run continues. “Harness” is a useful architecture term; it is not a synonym for the model.

Application

The product and business process that own the agent. It defines who may start a run, which data and tools are available, what needs approval and where the final artifact goes.

Orchestration

The control flow between turns, tools and agents. It can be ordinary program logic, a manager calling specialists as tools, or a handoff that transfers the conversation to another agent.

A helpful test is to ask which layer would change if the model changed. If the answer is “the reasoning quality”, you are talking about the model. If the answer is “what can run, what can be recorded or who must approve it”, you are talking about the harness or application.

The loop is the product

A normal chat has a simple shape: input, model response, end. An agent run can repeat the middle. The model receives a goal and the available tools, proposes an action, waits for the result and uses that result to decide what to do next. The managed Agents API carries that run across turns in a durable session[15]. In an SDK application, Runner coordinates the turns; with direct Responses calls, your application supplies more of that control flow.

What the surrounding layers do

Several layers are easy to collapse into one vague word. They are related, but they solve different problems.

Tools

Tools are the actions and observations an agent may request: search, read a record, run code, call a function or edit a file. A tool description tells the model how to ask; the application still owns the implementation and permission. The SDK supports custom function tools as one application-side option[11].

Model Context Protocol (MCP)

MCP is a protocol for exposing tools and context from another application. It is a connector surface, similar to a standard port. It does not make a model intelligent, turn a server into an agent or remove the need to trust the server and limit its credentials[6].

Skill

A skill is reusable procedure and supporting material that an agent can load when it needs a capability. It can explain a runbook, a file format or a house method. It is an instruction bundle, not another model and not a permission grant[7].

Sandbox

A sandbox is an execution boundary for files, commands and packages. The managed API can use an OpenAI-hosted sandbox, provisioned and managed by OpenAI[16]. Separately, the Agents SDK describes a SandboxAgent, a manifest and a live sandbox session, with capabilities such as filesystem access, shell, skills, memory and compaction[8]. It can reduce blast radius when configured well; the word alone is not a complete security review.

State and sessions

State is the information needed to continue a run. Managed agent sessions can be continued or resumed[15]. SDK sessions can retain conversation history across runs, while server-managed continuation is a separate mechanism[9]. Neither should be treated as a governed source of truth. Keep important evidence in explicit records or artifacts.

Artifacts

An artifact is a durable output such as a filtered data file, an investigation record or a report. It gives the next step something inspectable to receive instead of forcing every intermediate detail through the model's conversation.

Tracing and guardrails

In the SDK, tracing records generations, tool calls, handoffs and guardrails. Input, output and tool guardrails can block or reshape a run at defined points[10]. These controls improve visibility and stop conditions; they do not prove that the underlying answer is correct.