OpenAI’s Agents Platform: From Tool Calls to Observable Workflows

Tool access without managing six objects

Getting an assistant to use a tool could mean managing six different objects. The [Responses API](https://platform.openai.com/docs/quickstart?api-mode=responses) simplified that integration to one request while preserving convenient tool access from Assistants. In the March 2025 launch conversation, the larger problem was workflow length: Chat Completions originated around a text prompt and response, while tasks such as operating a computer require repeated actions across multiple turns.

The launch brought three built-in tools—web search, improved file search, and Computer Use—for accessing public information, searching uploaded data, and acting on a computer. It also introduced the Agents SDK, a software development kit for coordinating agents, evolved from the experimental Swarm project and equipped with tracing in the OpenAI dashboard.

The first concern was migration. The launch guidance distinguished three situations: - Existing Chat Completions applications could stay. OpenAI committed to maintaining the interface for years with new models and features. - New applications and built-in tool users should start with Responses. It was described as supporting Chat Completions functionality at launch. - Assistants migration depended on further work. Planned additions included assistant-like and thread-like objects, Code Interpreter, asynchronous mode, and webhooks. Code Interpreter was unavailable at launch.

A host mentioned a target Assistants sunset in the first half of 2026. OpenAI separately promised a full year to migrate once the transition capabilities were ready, with functionality and data preserved. These were launch plans, not confirmation of a completed transition.

Optional stored state makes failures inspectable. Responses state storage was described as free, with 30-day retention; passing store=false enabled stateless use. Dashboard inspection could reveal a faulty prompt, a missing tool call, or a misconfigured tool. Responses objects also supported metadata, prompting a recollection of Stripe users stuffing data into object metadata: developers often repurpose convenient storage.

Search as a tool, or search as a model

The [Web Search Tool](https://platform.openai.com/docs/guides/tools-web-search) arrived through two interfaces with different composition rules: - Responses: enable search as a tool. It can work alongside other tools and platform features. - Chat Completions: switch to a search-capable model. This exposes the search fine-tune used by ChatGPT Search. It does not let an arbitrary model call built-in search; the discussion explicitly rules out attaching it to o1 there.

A host reported roughly 30% accuracy for a base model versus 90% for its search variant on a benchmark transcribed as “simple QA.” That comparison motivated the argument that tools can substantially affect performance. The exact model identifiers and evaluation conditions were not established, so the figures do not imply a general threefold improvement across application tasks.

The search system’s stated goal was to select relevant material, answer from it, and cite it accurately. Gathering information was only the beginning; the fine-tune was described as particularly strong at grounding answers in retrieved material. Synthetic data and distillation were mentioned, without enough detail to reconstruct the training method.

Live information can become application-shaped data. Combining web search, function calling, and structured outputs was proposed as a way to return web information in the JSON schema an application needs. That makes search useful beyond conversational answers: the retrieved information can fit a defined output contract.

Citations make the information’s origin inspectable. Hebbia was cited as using web search for public information with live sources and citations in credit-firm or law-firm workflows. Those applications need to distinguish information drawn from a model’s internal knowledge from material whose source a user can examine.

Deeper search needs orchestration and a budget

Search breadth and depth were not built-in parameters at launch. The suggested workaround was a planning step followed by successive searches, each investigating another layer. Deeper research therefore required application logic to decide what to investigate next.

A participant proposed selecting retrieved material by relevance rather than a fixed count: - Top-k retrieval returns a chosen number of results, such as ten or twenty. - A similarity cutoff keeps results above a matching threshold, whether five documents qualify or 500. The cutoff was a proposed policy, not an announced API feature. It could adapt retrieval to the query, while making the amount of work and its cost less predictable.

The exchange cited an approximate search price of $30 per thousand queries, without billing conditions. A context budget offered another proposed control: search deeply, select the best material, and fit it into a fixed token allowance. This limits the material passed onward; it was not demonstrated to cap search expenditure or produce savings.

Retrieve private context, then search the web

The [File Search Tool](https://platform.openai.com/docs/guides/tools-file-search) parses uploaded data, splits it into chunks, embeds it, and indexes it in a searchable vector store. It was presented as managed retrieval-augmented generation (RAG): retrieving relevant material to inform an answer, with the retrieval infrastructure supplied by the service.

A question about caching web results in files led to a different, reported use: personalization through private preferences and live search. The workflow was: 1. Store user preferences or memories in a vector store. 2. Retrieve relevant reading or fashion preferences with File Search. 3. Search the web for matching information or products and present recommendations. This sequence was described as possible within one Responses call. The proposed caching workflow and its economics remained unconfirmed.

The broader architecture combines model knowledge, live web information, and private company documents. Each supplies a different part of the context an application may need. Navan provided a concrete private-document example: putting FAQs and travel policies into File Search so an assistant could answer with awareness of those policies, without rebuilding embedding and chunking infrastructure in-house.

Metadata filtering was described as a heavily requested addition that was coming to File Search. One participant considered it especially important above roughly 5,000–10,000 records—an opinion about practical needs, not a measured capacity limit.

For teams deciding whether to own retrieval, the recommendation was conditional: - Start managed if the supplied controls meet the need. Try File Search and assess it against the application’s requirements. - Build a custom stack when precise control is essential. Highly specific chunking and retrieval strategies are harder to implement through managed tools. More customization was planned, without a delivery schedule.

Computer Use turns screenshots into actions

The [Computer Use Tool](https://platform.openai.com/docs/guides/tools-computer-use) exposes the capability behind Operator to developers. Its separate model takes screenshots of the target computer and returns action requests, almost always as tool calls. Screenshots go in; clicks, scrolls, and typing requests come out, allowing an agent to act through an interface and report back.

This makes the need for multiple turns concrete: a task can require repeated observation and action before completion. The conversation illustrated that duration with a task of roughly 20 steps taking a couple of minutes. It was an example of an extended workflow, not a benchmark.

The capability was characterized as extremely early—analogous to the GPT-1 or GPT-2 stage of computer use. A playful detour proposed Pokémon as an agent benchmark, but offered no gameplay result; one participant did not think it had been tried.

Specialized previews also raised the question of model fragmentation. The stated direction was to fold stable capabilities into core models as developer needs became clearer. Vision supplied the precedent: a GPT-4-based vision preview preceded vision built into GPT-4o. Audio, search, and computer use were framed as following a similar direction, with no promised consolidation date.

Handoffs make work separable; traces make it inspectable

The [Agents SDK](https://github.com/openai/openai-agents-python) grew out of production orchestration problems that had motivated Swarm. Apparently simple ideas—routing a request or checking a guardrail—became complex when assembled into working systems. The SDK kept handoffs, transfers of work between agents, as its central concept while adding type support, guardrails, and tracing.

The proposed architecture separates responsibilities: - Triage routes by intent. An initial agent sends a request to an appropriate specialist. - Specialists separate application logic. Dividing responsibilities avoids concentrating every tool in one agent that is difficult to monitor. - Traces expose the execution path. Developers inspect handoffs and tool calls to troubleshoot what happened. The case for multiple agents here rests partly on making the system easier to understand and debug.

The guardrail example used optimistic generation: a check runs alongside generation and can block execution. The SDK also allowed choices at two integration points: - Model access: Responses by default, with support for other providers implementing the Chat Completions API format. - Tracing: the OpenAI dashboard by default, with support for other tracing providers.

The closing technical question connected observability to improvement. The proposed path was traces → evaluations → reinforcement fine-tuning: use execution traces to develop evaluations, then use good evaluations, graders, and tasks to support further training. This remained a longer-term vision with unresolved details, extending inspection of agent behavior into a possible improvement loop.