Implement generative AI and agentic solutions 2.2 Build agents by using Foundry
A compliance rule says model responses must not be persisted server-side, but users still…
Study guide skill: Define agent roles, goals, conversation-tracking approach, and tool schemas
Question B2-016
A compliance rule says model responses must not be persisted server-side, but users still need multi-turn context with a Foundry agent. Which approach meets both requirements?
Select one answer.
Answer: A
By default the service stores response history server-side so you can reference previous_response_id. If you set store to false, the response isn't persisted, and you carry the context forward yourself by passing earlier output items as input to the next request. Conversations, stored responses, and memory stores all persist data in the service, which the rule forbids.
Deep dive
How it works
By default, the service stores response history server-side, so you can chain turns with previous_response_id. The compliance rule forbids that, but the API has a documented alternative:
- Send each request with store set to false. The service doesn't persist the response.
- Carry the conversation forward yourself by passing the previous output items as input to the next request.
The runtime components page calls this out as useful when you need full control over conversation state, want to minimize stored data, or work in a zero-data-retention environment. The trade-off is that your app now owns the history: it keeps the items, decides how much context to resend, and handles growth over long chats.
Everything else that gives "memory" in Foundry persists data in the service, which is exactly what the rule prohibits.
The other options, and when you'd use them
- Default store with previous_response_id: That works only because the service stores response history server-side by default, which breaks the rule.
- A memory store: Memory is a managed, long-term solution: the service extracts information from conversations and consolidates it into durable knowledge. That's persistence by design.
- A conversation with each turn added: Conversations are durable objects that store items such as messages, tool calls and tool outputs, and you can reuse them across sessions. Also persistence.
Exam tip
"No server-side persistence but multi-turn" = store false + resend previous output items. previous_response_id, conversations and memory all keep data in the service.
References
Last reviewed: