Foundry IQ — knowledge bases and agentic retrieval

A knowledge base here is not just an index you search. It is a component that plans how to answer a question, goes to several sources at once, and returns one answer with citations.

How a knowledge base answers

Four steps, worth learning in order:

1. Decompose — break the question into subqueries.
2. Search in parallel — run those subqueries across the selected sources at the same time.
3. Rerank — score and order the combined results.
4. Unified answer — one grounded answer, with citations.

Step one is what makes this "agentic" rather than a lookup. A question that contains three separable asks becomes three searches, rather than one search that half-matches everything.

Two families of source

Indexed sources are ingested before query time: a search index, Azure Blob, Azure SQL, files, OneLake, and indexed SharePoint. They refresh on the indexer's schedule, and setting one up auto-generates the data source, skillset, index and indexer together. This family is best for very large corpora and for fast, relevant search.

Remote or real-time sources are queried on demand: remote SharePoint, web and Bing, an MCP server, Fabric, and Work IQ. They are always current and there is no index to maintain.

The trade is freshness against speed and scale. An indexed source is only as current as its last refresh; a remote source is current but you pay the query cost every time.

One specific mapping worth memorising: real-time SharePoint with Microsoft 365 governance means remote SharePoint, via the Copilot Retrieval API.

Permission-aware retrieval

This is the part with the most real-world weight.

Remote SharePoint passes the end user's access token through. Permissions and Purview sensitivity labels are enforced at query time, against that user. No permission configuration is needed at ingestion time.

Why it matters: the alternative — indexing everything and filtering later — is how organisations accidentally build systems that surface documents people were never allowed to see. Enforcing at query time with the user's own token means the retrieval simply cannot return what they could not already open.

Reasoning effort

Query planning — the subquery decomposition and source selection from step one — runs only at low or medium effort. Medium additionally enables iterative search, where results from one round inform the next.

You steer which sources get used through source descriptions and knowledge-base retrieval instructions. Descriptions doing the selection work again, as in cards 13 and 15.

Dependencies

• Azure AI Search is required.
• The Foundry Agent Service is not.
• A knowledge base is reusable across agents — build it once, point several agents at it.

The trap

Good agent instructions have to say three things: when to search, how to cite, and what to say when the answer is not found.

The third is the one people leave out, and it is the one the exam probes. A question describing an agent that invents answers when the index is empty is testing exactly this. The model has been told to answer and given nothing to answer from, so it produces something plausible. The fix is not a better model or a better index — it is an instruction covering the empty case.