In this article
A useful OpenAI integration is not automatically an agent. A feature might classify a document, interpret an image, or generate a detailed answer with one model request. None of those capabilities, by itself, establishes an agent workflow.
The more useful distinction is about responsibility. A direct integration invokes a model and handles its response. An agent integration also coordinates work across steps through tools, state, loops, handoffs, or managed execution. This is a documentation-grounded boundary, not a formal test of autonomy: OpenAI’s documentation does not specify a universal threshold that every agent must cross.
The responsibility map
| Area | Documented responsibility | What it does not determine |
|---|---|---|
| Basic request | Authenticate with an API key and make a request through an API or supported SDK | Whether the surrounding application is an agent |
| Model selection | Choose according to documented capabilities, modalities, costs, and workload characteristics | Whether the workflow uses agent orchestration |
| Agent workflow | Allocate responsibility for orchestration, tools, cross-step state, loops, handoffs, or managed progress | A universal autonomy level or guaranteed outcome |
| Production operation | Secure credentials, control access and spending, plan for traffic, and consider latency and compliance | Whether the integration is an agent |
These concerns can overlap without becoming interchangeable. A direct request can require serious production controls. An agent still needs model access and production operations.
Start with the basic request
The OpenAI API quickstart begins with creating an API key and making an API call through a supported SDK or direct HTTP interface. It also documents inputs beyond text, including image URLs, uploaded files, and PDF documents.
At this level, the application works directly with a model response. A single request can still perform substantial work. For example, an application might submit a document and ask the model to classify it. Complexity in the prompt or input does not, on its own, create an agent.
The OpenAI Agents guide reinforces that point by presenting the Responses API both as a way to call models directly and as a starting point for building an agent from scratch. Consequently, the endpoint alone cannot classify the integration.
What the agent layer adds
OpenAI describes agents as able to plan and complete tasks using tools, work with other agents, and maintain context across steps. The guide frames runtime selection around where orchestration should run and who should manage state between tasks. (OpenAI Agents guide)
That description introduces responsibilities beyond an isolated model invocation:
- Orchestration: coordinating work across multiple steps.
- State: maintaining context, turns, or progress between tasks.
- Tool execution: connecting the workflow to hosted tools, application functions, services, or sandboxes.
- Agent loops: using application logic or a runner to continue the workflow.
- Handoffs: passing work through documented handoff mechanisms.
- Execution: deciding where the workflow and any sandbox run.
- Resource management: handling storage, sessions, conversations, state, and cleanup.
Imagine extending the document classifier so it can search files, invoke an application function, preserve progress, and hand work to another specialized component. The important change is not that the model became smarter. The integration acquired responsibilities for coordinating a multi-step process.
This list is not a mandatory checklist. The documentation does not say every agent must use multiple agents, tools, and persistent state simultaneously, nor does it define an agent by a minimum number of steps.
Runtime choice divides the work
The Agents guide documents three starting points with different responsibility boundaries. (OpenAI Agents guide)
| Starting point | Documented responsibility boundary |
|---|---|
| Responses API | The application works directly with model responses. It can make direct calls or build an agent from scratch, managing history, response chaining, tools, and its execution environment. |
| Agents SDK | The SDK runs inside the application. The application controls deployment, storage, approvals, and runtime integration; the runner handles the agent loop and handoffs. |
| Agents API | OpenAI runs a managed Codex harness and manages underlying agent infrastructure. The guide positions it for long-running tasks where OpenAI manages the agent and saves its progress. |
These are different allocations of responsibility, not a ranking. The documentation provides no general durability, completion, performance, or reliability guarantee for any of them.
It also distinguishes an Agents API session, an SDK session, a Responses conversation, and a sandbox as separate resources. Each has runtime-specific state and cleanup instructions, so builders should not collapse them into one vague concept of “memory.” (OpenAI Agents guide)
Model choice is a separate decision
The OpenAI model catalog organizes models according to characteristics such as capability, cost, workload, supported inputs, output limits, and tools. The Agents guide instead organizes runtime choices around orchestration and state.
Treating model selection and workflow architecture as separate decisions is therefore a synthesis of the two documentation structures, not a formal rule stated by either page. Still, it prevents a common category error: selecting a more capable model does not itself require an agent workflow.
Model names, prices, limits, and capabilities are time-sensitive. Check the current catalog when implementing or revisiting an integration.
Production work applies to both
Whether the design uses one request or an agent runtime, deployed applications have operational responsibilities.
The production best-practices guide recommends keeping API keys out of source code and public repositories, exposing them through environment variables or secret-management services, setting expiration dates, and establishing a rotation process.
The guide also discusses optionally separating staging and production projects, restricting production access, setting project-specific rate and spend limits, and planning for traffic growth. If horizontal scaling is used, the application must account for multiple nodes and load balancing. It also identifies caching, cost, token usage, security, and compliance as production considerations. (OpenAI production best practices)
Latency does not determine whether a workflow is an agent either. The production guide identifies model choice and generated-token count as major influences on completion latency. Streaming can reduce time to the first token, but it does not reduce the time required to receive the complete generation. (OpenAI production best practices)
A compact scoping checklist
When deciding how to describe and scope an integration, ask:
- Does it make a request and return the response, or coordinate subsequent steps?
- Does it choose or invoke tools as part of the workflow?
- Must it preserve context or progress between steps?
- Does a runner repeatedly decide what happens next?
- Can work pass through handoffs?
- Who owns history, storage, approvals, execution, and cleanup?
- Does the application manage progress, or is some of that responsibility delegated to a managed runtime?
“Yes” to one question is not an official agent test. Together, however, the answers reveal where orchestration responsibility resides—and whether “agent” is a useful description rather than a fashionable label.
This comparison is based only on the cited documentation; no hands-on test or performance comparison was performed.
No comments yet