Just wanted to see if anyone else realized that there is one somewhat significant gap between plugins and GPTs; the ability to work with multiple plugins by different authors in a single interaction.
I.e. “Book me a flight when the weather is going to be nicest to fly from NYC to Miami.” That request could then be fulfilled with a weather plugin and a travel plugin like Kayak for example.
YEP, I’m very confused as to why we cant add multiple actions to one GPT. Right now it seems as though they all have to be on one domain and in the same schema.
I expect/hope eventually you’ll be able to add multiple GPTs to a conversation, like any chat with multiple users. Working out which should answer when is the primary difficulty there…
That is by design, a good design decision.
Sharing the data among various plugins was not a good idea in the first place. The security hole is as big as a black hole, and there is no easy way to deal with that. Even if there is a way technically, that would confuse an average user, who would share the sensitive data inadvertently. Take a look at the security risk I presented earlier.
Now, the GPTs have addressed all sorts of plugin problems (security, context, multimodality, code execution, external resources, etc.)
The only missing feature is that I haven’t got any time to jump for joy, because I have been glued to my computer screen to read/watch everything since the dev conference.
I think this is within the domain of a booking GPT. Let say we have a hypothetical GPT, FlyMeGPT. Its capabilities would include booking flights, recommending hotels, and suggesting itineraries based on a given location. It could also propose suitable dates for travel based on the desired activities, season, or weather conditions at the destination.
Now, if you ask it questions about the stock market, naturally it is out of the scope of its domain and I think it is fine not to be able to answer it.
Well Actions are supposed to be connected to an abstraction/interface API tailored to your GPT where your API action(s) do what you want it to do in one call instead of multiple action calls - it would increase latency massively because of the processing overhead of transforming inputs from previous results, then waiting for the task result, and then transforming that result again into output
I believe this might be what the Add Actions button is for
Does it seem like “add actions” allows you to choose from actions from other installed GPTs?
My understanding is that GPT actions exist within the walled garden of each GPT but would be great if that wasn’t true.
I couldnt disagree more. The entire POINT of plugins and functions is to combine multiple external sources of data into one experience. If it was actually for security purposes, then they wouldn’t let you call multiple functions with the API.
You do realize that “Sharing data among various plugins” is literally happening with any GPT having access to the web right? lol.
Again, there is no way this is the case. Plugins did exactly this before and worked.
The only difference between plugins and GPTs is that OpenAI hosts your Openapi Spec, and can now handle retrieval and browsing. THATS IT.
Every other aspect of GPTs is just custom instructions with a coat of paint. Its just essentially the UX merger of the Playground and ChatGPT.
Adding actions is just connecting the GPT to a personal or public API…which is why you can just port your current plugins over.
The only argument that makes sense to me is that they are still sticking with a “3 plugin” similar type rule, and counting Browser, Retrieval, and Code Interpreter as those additional actions.
Yes, your use case is legit, and the GPT supports that dearly. Take your FlyMeGPT as an example. It could use Weather1, Weather2, Weather3, …, Weather100. The obsolete plugin architecture could route your prompts according to its “best” judgment, say, Weather2 against your will (Weather3). Now, the GPT architecture delegates that decision to you (the GPT publisher.) That is a very good decision.
The users of your FlyMeGPT establish the explicit trust relationship with you and implicit trust relationship with the Weather3.
Even if the AGI is here now, you would still probably not want to use its free will to override your free will. The logic of that explicit/implicit trust relationship will remain until the end of the world, with or without AGI.
Don’t be misled by some conceptually wrong arguments here. “Sharing data” and “having access to the web” are two different concepts. Misunderstanding their distinction will be harmful for your design. Both “sharing” and “access to the web” are essential, but how to do them properly is the question. The GPT is the answer.
The plugin architecture isn’t obsolete. OpenAPI specs aren’t deprecated lol. Plus the background function calling is the still the exact same framework with the same response and input format.
Can you explain what you mean by “Against your will”? Any user that signs up for a plugin/action server is consenting to use the services offered.
Guys… no. ChatGPT has ALWAYS made the decision on what endpoints to call based on our manifests and endpoint descriptions. The GPT framework is no different, they simply host the OpenAPI spec. Plugins and actions have been and are just an external API that interfaces with ChatGPT’s API.
No one in this thread has conflated those terms. Again…GPTs haven’t ultimately changed much about the relationship between our back-ends and ChatGPT. This is mostly a coat of paint.
Back to that actual issue being discussed here: You actually cannot add multiple API servers into a OpenAPI Spec unless you handle all the routing on your back-end and change your spec. Previously we could have 3 different plugins at the same time, and didnt need to manage the routing at all.
So this appears to be one little step forward and one major step back for the plugin community. Sure they host the spec…but they took away the one-convo, multimodal plugin UX for third-party actions.
This is spot on! The issue is you no longer have that ability to use all of your separate “tools” together in a specific workflow. You depend on GPT developers to include all of the potential actions within a GPT that you might need for your use-case (which is going to result in a lot of bloated GPTs that don’t do any one thing well or try to do too much).
That said, I’m still pretty bullish on GPTs. I just wish they would keep plugins around or rebrand them as actions and integrate them by allowing you to create metaGPTs or something.
And agree the whole privacy argument is off. You explicitly consent to your data being used by the fact that you installed / enabled different plugins and use them together. Also there are now controls in place that specifically ask you if you are okay sending specific data.
All security problems can be solved in future, but user’s better expeirence is more important than securtiy, so plugin is better solution than GPTs.
This aged well actually. Its clear in my opinion that this is all to shift the token heavy utilities chatgpt was doing over to us. We get more control but end up paying for it.
In todays world, you converse with a single GPT. We are moving towards a world where you can talk to multiple or just have your main GPT go and talk to the other GPTs when it needs to.
I hear the feedback on this being less than ideal for some use cases where multiple plugins was useful in the past. I think we are pushing towards getting parity.
You are able to add multiple actions to a single GPT, the difference is that end users cannot enable multiple GPTs right now like you could with plugins.
This is more so about the product experience and building the right thing for people in the right order. We will get to this hopefully soon, but had a lot of other stuff to build and this use case just didn’t make the initial cut as we were focused on all the other GPT related stuff. Doesn’t really save many tokens to do this so not the primary consideration.
Yes! When I first posted this I don’t believe multiple API domains were enabled. This was a concern over not being able to combine external APIs without building our own back-end router. This isn’t really any different than what we’re doing with plug-ins. However it seemed the point of GPTs was to simplify that process, and it seemed fairly easy to just multiple domains. I’m glad this was updated!
That makes sense, and I see the value in pushing out a version that works and allows for a stateful experience. On the surface it looks like OpenAI has said “Let’s make this easy, we’ll handle all the conversation logic, you just need to retrieve the thread after a run.” However now that’s all a black box!
Right after dev day, I had views in my OpenAI platform for viewing Threads and Messages. This made sense…then they disappeared! Without the ability to view threads and messages, and zero information on TOKEN USE, guess what we have to do?
Yep, we have to log and track every thread and message and run externally if we want to be able to view conversations without using 600,000 tokens back and forth every time because we have no idea how you’re computing and compounding our usage. What THAT all equates to is almost the exact same as if I build using Chat Completions… except now we have less control over and knowledge of usage and costs.
I think I’ve found some value in the Assistant’s API in regards to the streamlining of certain processes, but it’s really hard to advocate for such an opaque system at the moment.
You can actually call one GPT from another GTP session by using the @ symbol and then typing the GPT’s name. It might have to be one of your GPTs or one you have saved.