Yep.
I built an entire application around this - so that during a call, the LLM would produce data → that data updates documents (whether on-disk/server or “ephemeral in database only”) → that data then included in the next internal re-prompting of the LLM (if desired) → also that data (the output of run #1) can be purposefully parsed and filtered based on parameters of run #2 (not all data that was saved in file needs to be provided necessarily - can be filtered before including in run #2 context window) → continues indefinitely until results pass inspection → return to user facing
I’m not sure how useful or not the agents/assistants SDK has been for folks - but I tell you what - if you do it yourself you can get it all to work beautifully… and it’s awesome. And there’s no limitations on how you route/store the data…
But of course, you’ve got to switch approaches a bit to handle everything yourself in terms of data storage and retrieval - I don’t know if the SDKs or endpoints can “work partially in-house and partially in OAS’s backend” - I’m guessing no - but hey - take all those dev hours and just put them into your own backend and use the much-faster completions endpoint, and control all processing, retrieval, storage, tools, threads, flows, etc, on your own end…
So just my two cents and nudge to say “use the LLM as a tool within your desired system, and the build the system yourself” - as opposed to using a system that doesn’t have the functionality, flexibility, or modifiability that’s necessary to achieve your goals.