That changes how this API should be read. Responses is not simply a more feature-rich text-generation endpoint. It is OpenAI’s successor path for applications that need a model to decide whether it requires current public information, material from a controlled document collection, a calculation, or a call into a business system—and then return structured tool activity alongside a final answer.
OpenAI described that direction at launch, while TechCrunch’s contemporaneous reporting made the limitation clear: agent demonstrations are easy; repeatable, safe deployment is the work. Windows administrators and software teams should treat Responses as an orchestration API, not as permission to hand a language model unrestricted access to production systems.
The “new” feature list actually spans two 2025 releases
The submitted feature list is broadly accurate, but its timeline is compressed in a way that obscures what changed and why. OpenAI’s March 2025 announcement introduced Responses as a replacement-oriented API primitive that combined the familiar prompt-and-response model with built-in web search, file retrieval, and computer-use tooling. The company positioned it between the simpler Chat Completions API and the more stateful Assistants API.
Then, in May 2025, OpenAI added several pieces that made the platform more useful for actual agent workflows. Remote MCP support allowed the model to discover and invoke tools exposed by compatible external services. Code Interpreter became available inside Responses for sandboxed Python-based analysis, while file search gained support for reasoning models, multiple vector stores, and filtering. OpenAI also introduced background mode for long-running work, reasoning summaries, and encrypted reasoning items for eligible Zero Data Retention customers.
Those dates matter because the API surface is now mature enough that a new project should not begin on Assistants. OpenAI’s current Help Center guidance says the Assistants API is deprecated and will be removed in August 2026, directing new work to Responses instead. Existing applications using Assistants objects, Threads, Runs, vector stores, and Code Interpreter need a migration plan now, particularly where a line-of-business app quietly depends on persistent thread behavior.
Chat Completions is not being retired. OpenAI has said developers who do not need hosted tools or multi-step model work can continue using it. That is a sensible choice for a Windows desktop utility that summarizes selected text, drafts a response, classifies support tickets, or produces structured JSON from a known prompt. Responses earns its extra implementation complexity when the model must select and use tools in a controlled workflow.
Tools provide capability, not authority
Web search is the clearest example of what Responses changes. The model can retrieve fresh public material before answering, which is useful for an IT operations dashboard that needs current Microsoft advisories, an asset-management assistant checking product lifecycle information, or an internal research tool gathering market data. OpenAI launched the capability with source-aware answers, but the presence of search results does not turn the output into a verified record.
TechCrunch noted during the 2025 launch that OpenAI’s own web-search benchmark results still left factual failures, while short navigational requests and citations remained practical weak points. The consequence is straightforward: a workflow may use web search to find a Microsoft security advisory or vendor release note, but the application should extract and validate identifiers such as CVE numbers, KB articles, build numbers, and product versions against the primary publisher before opening a ticket, changing a configuration baseline, or alerting users.
File search has a different boundary. It retrieves relevant chunks from documents stored in OpenAI vector stores; it does not automatically establish that the retrieved policy, runbook, contract, or installation guide is current, approved, or applicable to the machine in question. A Windows support assistant can search troubleshooting guides and historical incident reports far faster than an operator browsing SharePoint folders, but document ingestion and metadata become part of the security model. If the collection mixes retired Windows 10 procedures with Windows 11 25H2 guidance, the model can retrieve either unless the application separates collections or applies reliable attributes and filters.
Code Interpreter is useful when the task genuinely needs computation. It can analyze a CSV export of Intune device compliance, calculate patching rates by department, identify trends in Defender detections, or generate a chart from a PowerShell-collected inventory file. It runs code in an OpenAI-hosted sandbox rather than on the administrator’s workstation or endpoint fleet. That distinction prevents a common mistake: Code Interpreter is data analysis infrastructure, not a replacement for PowerShell remoting, Microsoft Graph permissions, Configuration Manager, Intune, or an endpoint-management agent.
Computer use needs the same caution. It allows a model to propose mouse and keyboard actions in a computer environment, a useful capability for controlled web workflows and certain legacy interfaces. It is not a dependable Windows desktop automation platform for unattended administrative changes. OpenAI warned at launch that its computer-using model was not highly reliable for operating-system automation and could make inadvertent mistakes; TechCrunch reported the same limitation. Where an action has an API, a Graph endpoint, a PowerShell cmdlet, or a narrowly scoped custom function, that deterministic interface remains the better choice.
MCP moves the trust boundary outside OpenAI
Remote MCP support is the feature with the largest operational consequence because it can connect a model to systems that hold or change real business data. OpenAI’s examples have included services such as Shopify, Stripe, Twilio, and other external platforms; a Windows-focused organization might instead expose carefully designed tools for ServiceNow, an internal CMDB, a deployment platform, a knowledge base, or a read-only security reporting service.
MCP does not make those integrations safe by itself. It standardizes how tools and context are exposed to a model, but the model still interprets untrusted instructions and decides which tools to call. OpenAI’s own guidance warns that untrusted MCP servers can introduce prompt-injection risk, and says organizations are responsible for vetting custom and third-party connectors. OpenAI also states that information sent to an MCP server is governed by that third party’s data-retention policies.
That means an enterprise should divide tools by consequence rather than build one broad “IT admin” connector. A read-only tool that returns a device’s BitLocker escrow status, last check-in time, and compliance state can be exposed much more widely than a tool that rotates credentials, disables a user, removes a device from management, or deploys a script. Write actions should require narrow scopes, server-side validation, idempotency where possible, complete logging, and explicit human confirmation. The model should never be the final enforcement point for an authorization decision.
Custom functions remain important for precisely this reason. They allow the developer to define a compact, schema-validated action such as
get_device_compliance,
search_approved_kb, or
create_draft_service_ticketinstead of giving an agent generic shell access or broad API credentials. The tool’s backend should independently check the caller’s identity, role, tenant, target device, and requested operation. A model can suggest an action; only deterministic policy code should approve it.
Multi-turn context has a retention and cost consequence
The submitted report correctly identifies multi-turn work as central to Responses. A model can inspect the result of a search, file lookup, Code Interpreter session, custom function, or MCP call, then decide what should happen next. This makes it practical to build a support workflow that parses an uploaded diagnostic archive, retrieves the relevant approved runbook, calls a read-only asset tool, and writes a concise operator-facing recommendation.
But “context” should not be mistaken for an indefinitely persistent memory store. OpenAI’s current data-controls documentation says Responses API application state is retained for at least 30 days by default, or when the
storeoption is enabled. Organizations using Zero Data Retention have different behavior, while background mode writes response data to disk for roughly 10 minutes so an application can poll for completion. Hosted Code Interpreter containers may keep temporary working files only while their container remains active.
Those details turn architecture into a compliance decision. A company handling incident artifacts, customer documents, credential-adjacent logs, or regulated material needs to decide which data is sent to Responses, which stays in its own system, how files expire, and whether conversation state should be stored at all. OpenAI says it does not train its models on business data by default, but that promise does not eliminate retention controls, access reviews, data-classification rules, or the separate exposure created by external MCP servers.
The most practical first deployment is therefore narrow: a read-only internal assistant that searches a curated documentation set, analyzes sanitized exports, and produces a cited draft for a human operator. Let it recommend a remediation step, collect the evidence, or prepare a ServiceNow ticket—but do not let it make the change.
For teams still running the Assistants API, August 2026 is no longer a distant migration target. Inventory the applications using Assistants, identify their thread and file-search dependencies, port low-risk workflows to Responses first, and keep every privileged operation behind ordinary Windows, identity, and API authorization controls.