OpenAI’s developer platform is changing at a faster rate than its endpoint names suggest. Responses is not merely Chat Completions with a different JSON shape. It is where OpenAI is collecting the state, tools, orchestration, context management, approvals, and governance features required by agents.
The architectural shift is straightforward: application teams still define the job and its authority, but more of the generic agent loop is becoming a managed platform primitive.
That can remove undifferentiated plumbing. It can also hide consequential defaults. A production design needs to know exactly which responsibilities moved into OpenAI’s runtime and which remain in the application.
Responses is the center of gravity
OpenAI recommends the Responses API for new projects. The API combines:
- typed output items for messages, reasoning, and tool calls;
- stateful continuation across turns;
- text and image inputs;
- built-in web search, file search, computer use, code interpreter, image generation, and MCP;
- custom function calls;
- an agentic loop that can invoke multiple tools inside one request.
Chat Completions remains supported. That distinction matters: “recommended for new work” is not “immediately migrate every stable integration.” A migration is valuable when an application needs reasoning continuity, hosted tools, richer typed items, or longer agent loops—not merely because a newer endpoint exists.
Responses are stored by default unless storage is disabled. Data-retention requirements, Zero Data Retention eligibility, third-party MCP services, and hosted tools must be reviewed together. store: false changes request storage behavior; it does not grant ZDR status by itself.
The agent loop now has three orchestration modes
Direct tool calls
The model chooses and invokes a tool, the application or hosted platform returns the result, and the model decides what to do next. This remains the clearest route when results require judgment, calls can have side effects, or approvals must be visible.
Programmatic Tool Calling
Programmatic Tool Calling lets GPT-5.6 write JavaScript that coordinates eligible tools inside a fresh isolated V8 runtime. It can run independent calls in parallel, loop over results, validate shapes, and compress large intermediate outputs before returning control to the model.
The application’s tool definitions decide whether each tool may be called directly, programmatically, or both. MCP approvals can still pause a generated program. The runtime has no general filesystem, Node.js, package install, subprocess, or direct network access.
Use this mode for deterministic coordination and reduction. Do not use it to bury an approval-sensitive write inside generated control flow.
Multi-agent orchestration
The Multi-agent beta allows a GPT-5.6 root agent to spawn concurrent subagents, exchange messages, wait for results, and synthesize a final answer. It is designed for independent workstreams whose contexts benefit from isolation.
This is hosted orchestration, not a deterministic workflow engine. The root model decides when and how to delegate within the application’s instructions and concurrency limit. Use a fixed workflow when order, retries, ownership, and state transitions must be predictable. Use model-directed subagents when the decomposition itself benefits from judgment.
A boundary map for choosing the mode
| Work shape | Best starting mode | Reason |
|---|---|---|
| One lookup or action | Direct tool call | Minimal moving parts and clearest trace |
| Several independent reads with structured results | Programmatic Tool Calling | Code can parallelize, filter, and aggregate efficiently |
| Search where each result changes the next query | Direct tool calls | The model needs fresh semantic judgment |
| Independent research or review lenses | Multi-agent beta | Separate context and parallel exploration add value |
| Ordered business process with writes | Application workflow plus direct tools | State, approval, idempotency, and rollback should be explicit |
| High-volume extraction with a validator | Programmatic tools or one bounded model call | Predictable control flow matters more than open-ended autonomy |
The pattern is to spend model judgment only where judgment adds value. Code should coordinate predictable stages. A workflow engine should own durable business state. The model should handle ambiguity and synthesis.
MCP moved from connectivity feature to enterprise boundary
The Responses API supports remote MCP servers and OpenAI-maintained connectors. A connector packages access to a supported service; a remote MCP server exposes its own tools over the protocol. Each can require explicit approval.
The official guide carries a direct security warning: a malicious MCP server can exfiltrate data available in model context. That is why “supports MCP” is not a sufficient production decision. A team still needs:
- a trusted server and dependency inventory;
- narrow OAuth scopes and workload identity;
- schema and description review;
- per-tool approval policy;
- outbound data controls;
- immutable call and result records;
- timeouts, idempotency, and safe retry behavior;
- a revocation and incident process.
OpenAI added a Secure MCP Tunnel in May 2026 so ChatGPT, Codex, Responses, and AgentKit can reach private or on-premises MCP servers through a customer-hosted client without publishing those servers to the internet. The tunnel changes network exposure. It does not make the tools, credentials, or returned content trustworthy by default.
The control plane is filling in
The platform changes around Responses are as important as the model features. The official API changelog records:
- workload identity federation for exchanging external identity tokens for short-lived OpenAI access tokens;
- organization and project spend limits that can stop requests at a monthly cap;
- model allowlists, retention settings, hosted-tool permissions, and billing detail in Admin APIs;
- multiple project- or organization-level IP allowlists;
- a Safety Usage Dashboard keyed by privacy-preserving safety identifiers;
- an official Terraform provider for projects, users, roles, service accounts, certificates, limits, and access assignments.
These features say something about the target customer. OpenAI is not only optimizing the model call; it is building the administrative surface required to operate many agent workloads across an enterprise.
The Agents SDK has a different job
The Responses API is the model-and-tool protocol. The Agents SDK is an application toolkit for agent definitions, handoffs, guardrails, sessions, and tracing. OpenAI’s May changelog notes a TypeScript SDK update with sandbox-agent support and an open-source harness.
The SDK can accelerate application structure, but it does not replace a durable workflow engine, policy service, domain database, or incident system. Framework abstractions are helpful only while their state transitions remain observable and testable.
A minimum production architecture
For a consequential agent, put these components around Responses:
- Intent and risk classifier — decides which workflow and authority tier apply.
- Context compiler — selects instructions, evidence, memory, tools, and budgets for this run.
- Policy gate — evaluates identity, tenant, data class, action risk, and approval requirements outside the prompt.
- Responses runtime — handles model reasoning, direct tools, programmatic coordination, or bounded subagents.
- Tool gateway — enforces schemas, scopes, idempotency, timeouts, network policy, and result provenance.
- Decision record — captures the inputs, route, tool calls, approvals, outputs, and policy decisions needed for replay.
- Evaluation loop — scores utility and policy adherence before and after deployment.
OpenAI can host more of step 4 and parts of step 5. The enterprise still owns the semantics of steps 1–3 and the accountability of steps 6–7.
The durable takeaway
OpenAI’s agent platform is becoming a managed harness: Responses supplies the loop, programmatic tools supply bounded code orchestration, Multi-agent supplies parallel model-directed delegation, MCP supplies connectivity, and the admin platform supplies identity and spend controls.
The design question is no longer whether the platform can call a tool. It is where judgment, authority, state, and evidence live. Keep those boundaries explicit and the platform can remove substantial plumbing. Blur them, and a convenient agent loop becomes an unreviewable business process.