Agent First: A Hands-On Workshop on Grounding Foundry Agents with Foundry IQ

You can get a knowledge base returning beautiful cited answers and still not have an agent worth shipping. The hard part isn't retrieval quality. It's the wiring: how the agent reaches your knowledge, when it decides to search, and what proof you have that the answer came from your documents.

This two-hour hands-on workshop builds that wiring twice. We start with a Foundry IQ knowledge base over an Azure AI Search index, so you know what the agent is standing on. Then we expose it as an MCP endpoint and write our own agent that mounts it as a tool, letting the agent choose when to search. Then we do the same job the managed way: an agent created in Microsoft Foundry with the knowledge base already attached, called from code and traced, so you can watch retrieval fire without orchestrating it yourself.

With both patterns running you can see the trade-offs directly, on the points you'll be defending in a design review later: control over retrieval, portability, auth and governance, and how much code you're left maintaining. We'll also tune retrieval reasoning effort, because an agent that already plans its own queries shouldn't pay for that planning twice.

To follow along you'll need a laptop with Python or .NET and an Azure subscription you can create resources in, since we'll be standing up a Microsoft Foundry project and an Azure AI Search service. Setup instructions go out ahead of time. Samples are in Python, with .NET equivalents sh