AI-103 Practice Question 55: Stateful Agent Conversations
Microsoft Azure AI Apps and Agents Developer Associate (AI-103) · Test 6 · question 5 of 10
A multi-turn support app calls the Chat Completions API directly. On every new user turn, the app reloads the entire prior transcript from its own database and resends it as the messages array. A bug in that reload logic once dropped the earliest turns, and the model answered as if the conversation had just started. The team wants the platform itself to own conversation history across turns, instead of the app reassembling it on every call.
What should they do?
Show answer and explanation
Answer:
Foundry Agent Service is built around conversations, which Microsoft describes as persisting "history across turns": the app creates a conversation, adds each turn's input, and "the next response uses the same conversation, so the agent can answer a follow-up question in context"; the service, not the application, is now the one responsible for retaining and supplying that history. Chat Completions, by contrast, is stateless by design: "Without a conversation, the application can instead carry context forward by ... resending earlier items," which is precisely the fragile pattern that caused the bug.
- A is wrong because the Chat Completions API has no session_id parameter or server-side history feature; it's stateless, and every call must supply the full context it needs. - B is wrong because a bigger context window changes how much history *can* fit in a request, not who is responsible for correctly assembling and resending it; the same reload bug could still drop turns before the request is built. - D is wrong because it's the same architecture with a sturdier data store underneath. The app still owns reassembling and resending the transcript on every call; it has only made that responsibility less likely to fail, not removed it.
Reference: Build with runtime components in Foundry Agent Service