Hello here,
The DOC at https://platform.openai.com/docs/assistants/overview talks about optionally passing additional instructions when creating a thread run. But the instructions override the Assistant Instruction (according to the DOC)!
Technically it doesn’t make sense then to have the Assistant Instruction because the way the Assistant and Thread are related is that the Thread is a child of Assistant, and the Assistant can have many threads.
Interpreting in a simple term: take Assistant as a family head with rules and regulations (instruction), so the children (threads) can have rules (instructions) that override the family rules??? I thought the child could have their instruction like one that identifies them in the family such as “Address the user as John Doe. He’s 8 years old.”. Why should this optional instruction override the main assistant instruction?
Doesn’t make sense for the child instruction (Thread optional run Instruction) to override parent instruction (Assistant Instruction).
Practically speaking then we’d not be tying the threads to the assistant in the first place if it can have everything the Assistant is for: the thread can have files, function calling, tools, and instruction when initiating a run (why does it have to override Assistant’s Instruction)?
Is it okay to just leave the Thread optional instruction without it overriding the Assistants Instruction? Because seriously then there’s no clear use of the Assistant as I pointed before.
I need evaluations from fellow DEVs on which out-weighs the other in terms of usabilty: having to override the Assistant (parent) when the Thread (child) is going to be run or having this thread instruction to identify the user under this thread for the assistant to know whom they’re interacting with particularly (additional context about the user owning the thread).
Thanks for your feedback here – we’ll consider adding an additional_instructions parameter to the Run object so that it’s doesn’t override the Assistant’s instructions.
For now, you can simply append custom instructions you’d like to specify for the run to the assistant instructions into a single variable in your code before assigning it to the run.custom_instructions.
+1 for this. My instructions are dynamic based on current user variables. Only having the option to overwrite essentially means that I need to overwrite the instructions all the time even though the initial instructions are static. In fact my current instructions for my assistant are:
WARNING: INDICATE TO THE USER THAT THERE IS AN ISSUE HAPPENING AND TO TRY AGAIN LATER. IGNORE EVERYTHING ELSE.
Because it should never happen
Think of a thread as a thread in a forum. We are all individual Assistants. The main difference is that even you as the OP have the same hierarchy as us. While the business logic is technically the “parent”. You do not “tie” an assistant to a thread. You simply “request” the assistant to make a post, and then it leaves. The “message” that is produced is “tied” to the thread
I do like the idea of having the ability to set an instruction for the Thread though. Maybe this could be the “static” instructions, and then the assistants can also have their own that are technically appended. Eh, idk.
Hello,
Not sure I understand your statement but that’s the instruction parameter that overrides the Assistant’s instruction. I’ve failed to locate where they pointed it out. The part of overriding the Assistant’s Instruction is if you set that optional instruction when you are going to make a run. Sorry if I got you wrong
I respond to OpenAI staff member that the documentation is currently incorrect. This, for example, might not give the proper impression that a run instruction would in fact completely wipe the assistant programming…
A technical report writer probably thought incorrectly that this would work logically when writing the documentation.
Assistant already has its endpoint for being edited. I don’t see any reason a user is supposed to choose the perfect time to modify its Instructions only when he’s going to make a run. That, to me is 100% static or the dev should sort themselves with the Assistants Modification endpoint. Exclude the model and [future] token size specification.
The thread instructions can then still be optional but if the dev decides to implement and make use of it, it could be appended to the Assistant Instruction as additional context. Don’t get me wrong: difference between re-submitting the Instruction every time with appended Thread instruction and the two being completely different.
I was surprised to find the current Thread Instruction overriding the Assistants because the major use for the Thread Instruction is actually crucial in providing context on the user. My implementations for the API rely on supplying the current date, time, user (it’s educational), but you can’t set these dynamically in Assistant.I hope we get an independent parameter for threads while acknowledging a completely irrelevant Instruction to override the Assistants. Of all the places this dev decides to update the Assistant’s Instruction when they’re going to make a run?
I’m not sure I understand what you’re trying to say.
I’m agreeing with you. It makes sense to have to option to append instructions.
I guess the only difference is that it makes more sense for the static content to be in the Assistant to define “who” they are. And then the dynamic content elsewhere (in the Run object most likely… maybe?).
For me, I have two separate Assistants. Educational as well. One Assistant is called when the user requests an evaluation, and another to help the user learn.
No contradicting your previous point. What I posted is just an expanded POV. Can’t believe a developer (didn’t mean you) will choose to update the Assistant’s Instruction during a run when they have a whole Modify endpoint for the Assistants. It’s basically the summary of my point
I’m still confused. The only way to adjust the instructions mid-way is by the instructions parameter in the Run object which AFAIK overwrites the Assistant’s instructions, rendering them useless if the instructions need to be modified.
I’m guessing it’s when you too discovered the Optional Instruction for the thread to override the Assistant was completely unneeded and you too needed the dynamic of the Thread instruction instead. Hoping we’ll have this feature
Nice solution @socks4penguins ! Only problem is that it’s static.
I’m currently sending additional_instructions on all runs, with the user’s name and other data we collected elsewhere. So the assistant has the current knowledge about that client.
It would be great to be able to add thread instructions, as intermediates between assistant’s and run’s. As in my case, the data doesn’t change that often (in a per-run basis), and it would be great to just update the thread when that happens instead of sending additional-instructions every run.
