Implement generative AI and agentic solutions 2.2 Build agents by using Foundry

In Microsoft Foundry Agent Service, a support agent must answer follow-up questions in…

Study guide skill: Define agent roles, goals, conversation-tracking approach, and tool schemas

Question B1-024

In Microsoft Foundry Agent Service, a support agent must answer follow-up questions in the context of earlier turns, and the conversation history must be kept server-side so the app doesn't resend it each time. What should the application do?

Select one answer.

  • A Append the conversation history to the agent's instructions and create a new agent version after each turn
  • B Raise max_output_tokens so the agent remembers earlier turns
  • C Create a conversation once, add each user turn to it, and generate each response against that same conversation ✓ Correct answer
  • D Start a new conversation for every user message so each response gets a clean context

Answer: C

In Foundry Agent Service a conversation persists history across turns: it supplies its stored input and output items to each response, so the next response that uses the same conversation can answer a follow-up in context. Conversations and responses replace the threads and runs of the deprecated classic Agent Service. Agent instructions hold reusable behavior, not chat history; a token limit stores nothing; and a new conversation per message loses the context.

Deep dive

How it works

Foundry Agent Service runs on three runtime components:

  • An agent supplies a reusable model, instructions and tools.
  • A conversation persists history across turns. It supplies its stored input and output items to responses, and the docs say to use it when later turns need server-side history.
  • A response is one unit of execution: it runs a model or agent against input and produces output items.

The docs walk through the exact scenario in the question, a support assistant answering a follow-up:

  1. The app selects an agent that defines the support instructions and tools.
  2. It creates a conversation and adds the customer's first question as an input item.
  3. A response runs the agent against the conversation and appends output items.
  4. The next response uses the same conversation, so the agent can answer the follow-up in context.

Because the history lives in the conversation on the service side, the app doesn't resend earlier turns. (Without a conversation, an app can carry context forward by referencing a previous stored response or by resending earlier items.) If you're coming from the classic service, the migration guide maps the old concepts: threads become conversations and runs become responses.

The other options, and when you'd use them

  • Append history to the agent's instructions and create a new agent version each turn: An agent is a reusable, versioned definition of behavior: model, instructions and tools. It isn't meant to hold chat history.
  • Raise max_output_tokens: That only limits how much a response can generate. It doesn't store anything between turns.
  • Start a new conversation for every message: A new conversation has no stored items from earlier turns, so follow-up questions lose their context.

Exam tip

Remember the split: agent = reusable behavior, conversation = server-side history, response = one execution. "Follow-ups without resending history" means reusing one conversation.

References

Last reviewed:

Ready to test yourself? The quiz asks this and every other AI-103 question, with instant feedback. Practice this in a quiz →

All Generative AI & agents questions · AI-103 study guide

Thanks for your feedback!