main fun part - since responses are stored for free by default now, how can we abuse the Responses API as a database :)
other fun qtns that a HN crew might enjoy:
- hparams for websearch - depth/breadth of search for making your own DIY Deep Research
- now that OAI is offering RAG/reranking out of the box as part of the Responses API, when should you build your own RAG? (i basically think somebody needs to benchmark the RAG capabilities of the Files API now, because the community impression has not really updated from back when Assistants API was first launched)
- whats the diff between Agents SDK and OAI Swarm? (basically types, tracing, pluggable LLMs)
- will the `search-preview` and `computer-use-preview` finetunes be merged into GPT5?
one of the main reasons i build these ai search tools from scratch is that i can fully control the depth and breadth (and also customize loader to whatever data/sites).
and currently the web search isn't very transparent on what sites they do not have full text or just use snippets.
having computer use + websearch is definitely something very powerful (openai's deep research essentially)
Does it encode everything as json object, so special characters are getting escaped?
I’ve noticed that with longer responses (particularly involving latex), models are a lot less accurate when the results need to be additionally encoded into JSON.
I like structured, but my preference is yaml/markdown, as it is a lot more readable (and the only thing that works with longer responses, latex or code generation).
this is why I don't like NSA (non-standard acronyms). It saves half a second for the typer, but causes hours if not days of confusion when summed over all the readers.
I think Anthropic's definition makes the most sense.
- Workflows are systems where LLMs and tools are orchestrated through predefined code paths. (imo this is what most people are referring to as "agents")
- Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
The problem with this definition is that modern workflow systems are not through predefined code paths, they do dynamically direct their own processes and tool usage.
Agents are just regular LLM chat bots that are prompted to parse user input into instructions about what functions to call in your back-end, with what data, etc. Basically it's a way to take random user input and turn it into pseudo-logic you can write code against.
As an example, I can provide a system prompt that mentions a function like get_weather() being available to call. Then, I can pass whatever my user's prompt text is and the LLM will determine what code I need to call on the back-end.
So if a user types "What is the weather in Nashville?" the LLM would infer that the user is asking about weather and reply to me with a string like "call function get_weather with location Nashville" or if you prompted it, some JSON like { function_to_call: 'get_weather', location: 'Nashville' }. From there, I'd just call that function with any the data I asked the LLM to provide.
Relative to that scale, L2 is how I've come to understand it. It's kind of soft-sold as L3 but that will require quite a bit of work on the vendor side (e.g., implementing an AWS Lambda style setup for authoring functions the LLM can call).
There is already a definition in agent oriented programning. It has something to do with own sensors of environment and react autonomously. I find that definition fits agentic AI too. My rudimentary interpretation is anything with its own inner (event) loop.
a program can be unixy: taking inputs and producing output, and does not listen and react to any event. It can also be an UI program that are "event-driven" but all events are from user actions, hence no autonomy.
It is not only an Anthropic thing, and it works with any model that supports function calling, which DeepSeek did not when it first launched. That probably has changed since, but I haven't looked!
I don't like it. I don't like the OpenAI API all that much either but at least it's lightweight. I think MCP would fit better on mcp.anthropic.com to go along with their email address mcp-support@anthropic.com at the bottom of https://modelcontextprotocol.io/
I wish they'd done a smaller launch of it and gather feedback rather than announcing a supposed new standard which feels a lot like a wrapper.
This here is atrocious https://github.com/modelcontextprotocol/quickstart-resources... It includes this mcp PyPI package which pulls in a bunch of other PyPI dependencies. And for some reason they say "we recommend uv". How is that related to just setting up a tool for an AI to use?
That example code on DeepSeek doesn't actually include the logic to call a weather API? It just puts a fake answer back in, and you've got to handle the process manually.
The pyproject.toml in the Model Context Protocol example is just showing the new, "best" way to distribute and install Python projects and dependencies. If you haven't used uv before, it makes working with Python projects substantially better.
The Model Context Protocol server lets the model autonomously use the tool and incorporate its result. It's a much cleaner (imo obviously) separation of tool definition and execution.
MCP is a protocol, and Anthropic has provided SDKs for implementing that protocol. In practice, I find the MCP protocol to be pretty great, but it leaves basically everything except the model parts out. I.e. MCP really only addresses how "agentic" systems interact with one another, nothing else.
This SDK is trying to provide a bunch of code for implementing specific agent codebases. There are a bunch of open source ones already, so this is OpenAI throwing their hat in the ring.
IMO this OpenAI release is kind of ecosystem-hostile in that they are directly competing with their users, in the same way that the GPT apps were.
[edit] worth mentioning [langfuse](https://github.com/langfuse/langfuse), which is more like a platform that addresses the observability/evals/prompt management piece of the puzzle as opposed to a full-on "agent framework". In practice I have not yet run into a case where I needed something like what OpenAI just released, nor crewAI etc (despite it feeling like those cases may be coming)
People are using the word "agentic" to mean this, I think. But yeah it's a dumb, overloaded primarily marketing word. I keep going back and forth on whether I should use the word "agentic"/"agent" at all
I have been using Windsurf+Sonnet for a couple months, and recently adding Supabase MCP was a total game changer for velocity. I can't believe I waited so long to configure that.
Querying schema from prompt is great, but also being able to say "I cannot see the Create Project button on the projects list screen. Use MCP to see if user with email me@domain.com has the appropriate permissions" is just amazing.
100% but this is not the same thing, nor is this going to replace the agent SDK (or visa versa). Agents will always need some form of communication protocol, if we look at the world and agentic frameworks its a sea of logos and without some forms of open standards this would be hard.
I'm currently at Comet and I have personally worked on MCP implementations AND have made some contributions to Agent SDK in the form of a native integration and improvement to test suite.
I think the key to what OpenAI is pushing towards is simplicity for developers through very easy to use components. I won't comment on the strategy or pricing etc, but on first glance as a developer the simple modular approach and lack of bloat in their SDK is refreshing.
Kudos to the team and people working on the edge to innovate and think differently in an already crowded and shifting landscape.
They did not announce the price(s) in the presentation. Likely because they know it is going to be very expensive:
Web Search [0]
* $30 and $25 per 1K queries for GPT‑4o search and 4o-mini search.
File search [1]
* $2.50 per 1K queries and file storage at $0.10/GB/day
* First 1GB is free.
Computer use tool (computer-use-preview model) [2]
* $3 per 1M input tokens and $12/1M output tokens.
So they're basically pivoting from selling text by the ounce to selling web searches and cloud storage? I like it, it's a bold move. When the slow people at Google finally catch up it might be too late for Google?
Google AI Studios "Grounding" basically web search is priced similarly. (Very expensive for either, although Google gives you your first 1500 queries free).
It seems completely upside down, they always said traditional search was cheaper/less intensive, I guess a lot of tokens must go into the actual LLM searching and retrieving.
Nice to finally see one of the labs throwing weight behind a much needed simple abstraction. It's clear they learned from the incumbents (langchain et al)-- don't sell complexity.
Also very nice of them to include extensible tracing. The AgentOps integration is a nice touch to getting behind the scenes to understand how handoffs and tool calls are triggered
The OpenAI dash is great but is clearly missing a lot of features (i.e. data export, alerts, non-oai model compatibility). Believe it or not, but they don't even report response API costs on spans
This is one of the few agent abstractions I've seen that actually seems intuitive. Props to the OpenAI team, seems like it'll kill a lot of bad startups.
Which could be combined with the query_kb tool from the mr_kb plugin (in my mr_kb repo) which is actually probably better than File Search because it allows searching multiple KBs.
Anyway, if anyone wants to help with my program, create a plugin on PR, or anything, feel free to connect on GitHub, email or Discord/Telegram (runvnc).
Thank you for your detailed Readme. A relief / joy to read compared to many other libraries/etc. that provide one basic (if that) example and otherwise leave to your own trial/error.
> “we plan to formally announce the deprecation of the Assistants API with a target sunset date in mid-2026.”
The new Responses API is a step in the right direction, especially with the built-in “handoff” functionality.
For agentic use cases, the new API still feels a bit limited, as there’s a lack of formal “guardrails”/state machine logic built in.
> “Our goal is to give developers a seamless platform experience for building agents”
It will be interesting to see how they move towards this platform, my guess is that we’ll see a graph-based control flow in the coming months.
Now there are countless open-source solutions for this, but most of them fall short and/or add unnecessary obfuscation/complexity.
We’ve been able to build our agentic flows using a combination of tool calling and JSON responses, but there’s still a missing higher order component that no one seems to have cracked yet.
Hey there! This is Steve here from the OpenAI team–I worked on the Responses API. We have not removed this! It should still work just like before! Here's an example:
(Shameless plug) I worked on something for anyone else wanting to get structured outputs from LLMs in a model agnostic way (Including Open AI models): https://github.com/inferablehq/l1m
I'm a bit surprised at the approach to RAG. It will be great to see how well it handles complex PDFs. The max size is far larger than the Anthropic API permits (though that's obviously very different - no RAG).
The chunking strategy is... pretty basic, but I guess we'll see if it works well enough for enough people.
We handle over 1M requests per month using the Assistant API on https://rispose.com which apparently will get depreciated mid 2026. Should we move to the new API?
Eventually, yes. The addressed Assistant API near the end of the the video: They say there will be a transition path, once they built all Assistant features into the new API, and ample time to take action.
there's no rush to do this - in the coming weeks, we will add support for:
- assistant-like and thread-like objects to the responses api
- async responses
- code interpreter in responses
once we do this, we'll share a migration guide that allows you to move over without any loss of features or data. we'll also give you a full 12 months to do your migration. feel free to reach out at nikunj[at]openai.com if you have any questions about any of this, and thank you so much for building on the assistants api beta! I think you'll really like responses api too!
Is it just me, or is what OpenAI is really lacking is a billing API/platform?
As an engineer, I have to manage the cost/service ratio manually, making sure I charge enough to handle my traffic, while enforcing/managing/policing the usage.
Additionally, there are customers who already pay for OpenAI, so the value add for them is less, since they are paying twice for the underlying capabilities.
If OpenAPI had a billing API/platform ala AppStore/PlayStore, I have multiple price points matched to OpenAI usage limits (and maybe configurable profit margins).
For customers that don't have an existing relationship with me, OpenAI could support a Netflix/YouTube-style profit-sharing system, where OpenAI customers can try out and use products integrated with the billing platform/API, and my products would receive payment in accordance with customer usage...
One, if you charge above API costs, you should never police usage (so long as you're transparent with customers). Why would you need to cap usage if you're pricing correctly? (Rate limits aside)
Two, yes, many people will pay $20/mo for ChatGPT and then also pay for a product that under the hood uses OpenAI API. If you're worried about your product's value not being differentiated from ChatGPT, I'd say you have a product problem moreso than OpenAI has a billing model problem.
I'm impressed by the advances in Computer Use mentioned here and this got me wondering - is this already mature enough to be utilized for usability testing? Would I be right to assume that in general, a UI that is more difficult for AI to navigate is likely to also be relatively difficult for humans, and that it's a signal that it should be simplified/improved in some way?
Oh, I had assumed that it was trained on human interaction data and should be generally similar, and from the examples I saw - it generally was (although still not as good as us). In what sense do you expect it to be drastically different?
LLM engages with UI in a pragmatic way. It doesn't care about aesthetics or structural complexity, it doesn't care about latency or tactility. It doesnt have anywhere close to similar preferences and reasons for why it Vs a human being would and wouldn't click on or engage with something on a UI.
Do you really see no difference in the way a hollow algorithm interacts with UI vs how a person would go about interacting with UI?
It would have been nice if the Completions use of the internal web-search tool wasn't always mandatory and could be set to 'auto'. Would save a lot of reworking just to go the new Responses API format just for that use case.
Does the SDK allow executing Python code generated in some sort of sandbox? If not are there any open source library which does this for us?
I would ideally like the state of the code executed, including return values, available for the entire chat session, like IPython, so that subsequent LLM generated code can use them.
Feels like OpenAI really want to compete with its own ecosystem. I guess they are doing this to try to position themselves as the standard web index that everyone uses, and the standard RAG service, etc.
But they could just make great services and live in the infra layer instead of trying to squeeze everyone out at the application layer. Seems unnecessarily ecosystem-hostile
164 comments
[ 3.1 ms ] story [ 207 ms ] threadhttps://latent.space/p/openai-agents-platform
main fun part - since responses are stored for free by default now, how can we abuse the Responses API as a database :)
other fun qtns that a HN crew might enjoy:
- hparams for websearch - depth/breadth of search for making your own DIY Deep Research
- now that OAI is offering RAG/reranking out of the box as part of the Responses API, when should you build your own RAG? (i basically think somebody needs to benchmark the RAG capabilities of the Files API now, because the community impression has not really updated from back when Assistants API was first launched)
- whats the diff between Agents SDK and OAI Swarm? (basically types, tracing, pluggable LLMs)
- will the `search-preview` and `computer-use-preview` finetunes be merged into GPT5?
one of the main reasons i build these ai search tools from scratch is that i can fully control the depth and breadth (and also customize loader to whatever data/sites). and currently the web search isn't very transparent on what sites they do not have full text or just use snippets.
having computer use + websearch is definitely something very powerful (openai's deep research essentially)
0 - https://ai.pydantic.dev/
> Notably, our SDK is compatible with any model providers that support the OpenAI Chat Completions API format.
so you can use with everything, not only OpenAI?
1 - https://github.com/huggingface/smolagents
I’ve noticed that with longer responses (particularly involving latex), models are a lot less accurate when the results need to be additionally encoded into JSON.
I like structured, but my preference is yaml/markdown, as it is a lot more readable (and the only thing that works with longer responses, latex or code generation).
Ok I’ll start: an agent is a computer program that utilized LLMs heutiger for decision making.
I personally strongly prefer the term "bots" for what most of these frameworks call "agents"
- Workflows are systems where LLMs and tools are orchestrated through predefined code paths. (imo this is what most people are referring to as "agents")
- Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.
https://www.anthropic.com/engineering/building-effective-age...
If they are driven by LLMs interpretation then there is no explicit code written and it's figured out at runtime
As an example, I can provide a system prompt that mentions a function like get_weather() being available to call. Then, I can pass whatever my user's prompt text is and the LLM will determine what code I need to call on the back-end.
So if a user types "What is the weather in Nashville?" the LLM would infer that the user is asking about weather and reply to me with a string like "call function get_weather with location Nashville" or if you prompted it, some JSON like { function_to_call: 'get_weather', location: 'Nashville' }. From there, I'd just call that function with any the data I asked the LLM to provide.
but yes, it's the strongest anti-developer move to not directly support MCP. not surprised given OpenAI generally. but would be a very nice addition!
I wish they'd done a smaller launch of it and gather feedback rather than announcing a supposed new standard which feels a lot like a wrapper.
This here is atrocious https://github.com/modelcontextprotocol/quickstart-resources... It includes this mcp PyPI package which pulls in a bunch of other PyPI dependencies. And for some reason they say "we recommend uv". How is that related to just setting up a tool for an AI to use?
Compare that to this get weather example: https://api-docs.deepseek.com/guides/function_calling/
It makes me not want to use Claude/Anthropic.
The pyproject.toml in the Model Context Protocol example is just showing the new, "best" way to distribute and install Python projects and dependencies. If you haven't used uv before, it makes working with Python projects substantially better.
The Model Context Protocol server lets the model autonomously use the tool and incorporate its result. It's a much cleaner (imo obviously) separation of tool definition and execution.
This SDK is trying to provide a bunch of code for implementing specific agent codebases. There are a bunch of open source ones already, so this is OpenAI throwing their hat in the ring.
IMO this OpenAI release is kind of ecosystem-hostile in that they are directly competing with their users, in the same way that the GPT apps were.
https://github.com/slavakurilyak/awesome-ai-agents
CrewAI is a popular VC-backed one, but two that I think are kind of interesting in the open source space are:
https://github.com/i-am-bee/beeai-framework
https://github.com/lastmile-ai/mcp-agent
... However I think the vast majority of "AI Agent" use-cases in practice right now are actually just workflows, and imo dify is great for those:
https://github.com/langgenius/dify
[edit] worth mentioning [langfuse](https://github.com/langfuse/langfuse), which is more like a platform that addresses the observability/evals/prompt management piece of the puzzle as opposed to a full-on "agent framework". In practice I have not yet run into a case where I needed something like what OpenAI just released, nor crewAI etc (despite it feeling like those cases may be coming)
I just realized BeeAI is IBM's project: https://www.ibm.com/think/news/beeai-open-source-multiagent
I also see there's https://ai.pydantic.dev/ but it lacks MCP support. Finally, the MCP site maintains a nice client list:
https://modelcontextprotocol.io/clients#feature-support-matr...
It does not specify how “agentic” systems interact with each other. Depending on what you mean there.
https://github.com/SecretiveShell/MCP-Bridge
Querying schema from prompt is great, but also being able to say "I cannot see the Create Project button on the projects list screen. Use MCP to see if user with email me@domain.com has the appropriate permissions" is just amazing.
> [Q] Does the Agents SDK support MCP connections? So can we easily give certain agents tools via MCP client server connections?
> [A] You're able to define any tools you want, so you could implement MCP tools via function calling
in short, we need to do some plumbing work.
relevant issue in the repo: https://github.com/openai/openai-agents-python/issues/23
I'm currently at Comet and I have personally worked on MCP implementations AND have made some contributions to Agent SDK in the form of a native integration and improvement to test suite.
- https://github.com/comet-ml/opik-mcp
- https://github.com/openai/openai-agents-python/pull/91
Our recent integration shipped on day 1:
- https://www.comet.com/docs/opik/tracing/integrations/openai_...
I think the key to what OpenAI is pushing towards is simplicity for developers through very easy to use components. I won't comment on the strategy or pricing etc, but on first glance as a developer the simple modular approach and lack of bloat in their SDK is refreshing.
Kudos to the team and people working on the edge to innovate and think differently in an already crowded and shifting landscape.
[1] https://platform.openai.com/docs/pricing#built-in-tools
[2] https://platform.openai.com/docs/pricing#latest-models
It seems completely upside down, they always said traditional search was cheaper/less intensive, I guess a lot of tokens must go into the actual LLM searching and retrieving.
I have a hard time seeing how this API is better than https://www.anthropic.com/news/model-context-protocol.
It seems like the motivation was "how can we make more money", rather than "how can we be more useful for our users".
I also wrote a script that searches the web and works pretty well (using the vercel ai sdk)[1]
[0] - https://brave.com/search/api/
[1] - https://gist.github.com/bramses/41e90b27d156590154bcefd4119f...
Also very nice of them to include extensible tracing. The AgentOps integration is a nice touch to getting behind the scenes to understand how handoffs and tool calls are triggered
BTW I have something somewhat similar to some of this like Responses and File Search in MindRoot by using the task API: https://github.com/runvnc/mindroot/blob/main/api.md
Which could be combined with the query_kb tool from the mr_kb plugin (in my mr_kb repo) which is actually probably better than File Search because it allows searching multiple KBs.
Anyway, if anyone wants to help with my program, create a plugin on PR, or anything, feel free to connect on GitHub, email or Discord/Telegram (runvnc).
https://github.com/Anilturaga/aiide
The new Responses API is a step in the right direction, especially with the built-in “handoff” functionality.
For agentic use cases, the new API still feels a bit limited, as there’s a lack of formal “guardrails”/state machine logic built in.
> “Our goal is to give developers a seamless platform experience for building agents”
It will be interesting to see how they move towards this platform, my guess is that we’ll see a graph-based control flow in the coming months.
Now there are countless open-source solutions for this, but most of them fall short and/or add unnecessary obfuscation/complexity.
We’ve been able to build our agentic flows using a combination of tool calling and JSON responses, but there’s still a missing higher order component that no one seems to have cracked yet.
https://github.com/openai/openai-python/blob/main/examples/r...
I based my assumption on the examples in the documentation[^1]. It is great that we can still use that.
1. https://platform.openai.com/docs/guides/structured-outputs?a...
The chunking strategy is... pretty basic, but I guess we'll see if it works well enough for enough people.
- assistant-like and thread-like objects to the responses api
- async responses
- code interpreter in responses
once we do this, we'll share a migration guide that allows you to move over without any loss of features or data. we'll also give you a full 12 months to do your migration. feel free to reach out at nikunj[at]openai.com if you have any questions about any of this, and thank you so much for building on the assistants api beta! I think you'll really like responses api too!
https://github.com/openai/openai-assistants-quickstart
As an engineer, I have to manage the cost/service ratio manually, making sure I charge enough to handle my traffic, while enforcing/managing/policing the usage.
Additionally, there are customers who already pay for OpenAI, so the value add for them is less, since they are paying twice for the underlying capabilities.
If OpenAPI had a billing API/platform ala AppStore/PlayStore, I have multiple price points matched to OpenAI usage limits (and maybe configurable profit margins).
For customers that don't have an existing relationship with me, OpenAI could support a Netflix/YouTube-style profit-sharing system, where OpenAI customers can try out and use products integrated with the billing platform/API, and my products would receive payment in accordance with customer usage...
Two, yes, many people will pay $20/mo for ChatGPT and then also pay for a product that under the hood uses OpenAI API. If you're worried about your product's value not being differentiated from ChatGPT, I'd say you have a product problem moreso than OpenAI has a billing model problem.
Do you really see no difference in the way a hollow algorithm interacts with UI vs how a person would go about interacting with UI?
I wrote a wrapper around it that works in a web browser (you'll need an OpenAI API key): https://github.com/uhsealevelcenter/IDEA
Here's the alternative link for people who aren't signed in to Twitter: https://nitter.net/athyuttamre/status/1899541471532867821
But they could just make great services and live in the infra layer instead of trying to squeeze everyone out at the application layer. Seems unnecessarily ecosystem-hostile
otoh, they've dropped prices for everything else a ton previously so maybe they will for this as well