2.4.1. Generative Answers with Azure AI Search and Foundry
💡 First Principle: Plain Azure-AI-Search knowledge upgrades where retrieval happens; this integration upgrades the whole answering stack — your data connected to Azure OpenAI models (configured through Microsoft Foundry at ai.azure.com), working with Azure AI Search indexing, surfaced through the generative answers node. You control retrieval and generation.
Mechanically: in Foundry, you connect your data to Azure OpenAI — establishing the search-index-plus-model pairing on the Azure side. In Copilot Studio, a topic's generative answers node is pointed at that connection through its data source configuration (the "classic data" path), after which answers in that topic are grounded and generated by the Azure-side stack. Deploying from the Azure OpenAI side can even scaffold the Copilot Studio agent for you, wiring a Conversation Boosting system topic automatically.
The behavioral rule that outranks the setup details: node-level data sources take priority over agent-level knowledge — agent-level sources act only as fallback for a topic whose generative answers node defines its own. That is the mechanism behind topic-scoped grounding designs ("the claims topic answers only from the claims index") and behind a classic debugging surprise ("why does this topic ignore our SharePoint knowledge?").
⚠️ Exam Trap: Distinguish the two Azure AI Search patterns by what generates. Knowledge-source Azure AI Search (2.1.3): your index, Copilot Studio's managed answering. This integration: your index and your Azure OpenAI model doing the answering. Requirements naming the model ("answers must use our fine-tuned GPT deployment") force the second pattern.
Reflection Question: A compliance requirement says every generated answer in the claims topic must come from the claims index and be produced by the firm's approved Azure OpenAI deployment. Which node do you configure, and why does attaching the index as agent-level knowledge fail both halves of the requirement?
