Hi everyone,
I’m working on a multi-turn conversational agent using the Responses API and the Prompt Library, and I’ve run into a strange behavior with how conversation history is handled when using prompt variables.
I wanted to ask if this is a feature or if I’ve stumbled onto a bug.
When calling a reusable prompt from the library, I’ve been passing the user’s message into a custom variable slot (like {{input}}) instead of passing standard message thread blocks.
For single-turn interactions, this works perfectly. The variable evaluates server-side, and the model responds exactly as expected.
Recently, I used this same pattern for an agent that handles a continuous, multi-round conversation. After about 10 turns, the agent’s context completely degraded—it started hallucinating earlier questions, looping, and losing track of the conversation entirely.
When I checked the Logs > Responses dashboard to see what payload was actually being generated, I noticed that the log thread contained absolutely zero user messages. It was just a continuous string of back-to-back Assistant replies and Reasoning steps.
From what I can tell, because the {{input}} variable is evaluated server-side after the API call is made, the raw developer log doesn’t append it as a formal role: "user" message in the conversation thread block. As a result, when the next turn happens, the model receives a context window where the assistant is essentially just talking to itself, causing the context to break.
Is this the intended design? Should we strictly avoid using Prompt Library variables to carry primary user input if we plan on running multi-turn chats?
Or is this a logging/payload sync issue where server-side variable injections should ideally be written back into the conversation history object?
I wanted to check if anyone else has navigated this or if there’s a nice way to handle state when abstracting prompts to the dashboard.
Thanks for any insights.