Microsoft Foundry IQ: enterprise retrieval availability is mixed, so design to the exact API and integration

Quick answer

Microsoft Foundry IQ is Microsoft’s knowledge layer for grounding agents in organizational data. Microsoft documents knowledge bases that combine sources, Azure AI Search agentic retrieval, optional model-assisted query planning, and permission-aware access patterns. That can be a useful architectural direction for teams that need an agent to retrieve from more than one enterprise source without wiring every agent directly to every system.

The availability claim needs precision. Microsoft’s current Foundry IQ documentation says some capabilities are generally available while others remain preview, depending on the Search Service REST API version. Microsoft’s Foundry general-availability overview calls Foundry IQ “Partial GA”: API-level GA while portal access remains preview. The Foundry IQ hosted-agent quickstart also marks its preview items as unsupported for production workloads. A team should not treat a broad Foundry milestone or a product page as proof that every Foundry IQ source, portal path, connector, integration, or retrieval behavior has GA support.

This article uses Microsoft’s June 2, 2026 Foundry IQ launch announcement as its News event date. That announcement describes generally available knowledge bases alongside preview serverless, source, pipeline, and security capabilities; the technical and availability record was checked again on August 2, 2026. No local tenant, Azure AI Search service, knowledge base, connector, or agent was configured or tested for this brief.

What Foundry IQ is documented to do

Microsoft describes a Foundry IQ knowledge base as a top-level resource that groups knowledge sources and controls retrieval behavior. Azure AI Search provides the underlying indexing and retrieval infrastructure. The documented workflow is to create knowledge sources, create a knowledge base that references them, connect an agent or application, and retrieve information through the knowledge base. Microsoft says knowledge bases can be called from Foundry Agent Service, Microsoft Agent Framework, or applications that use the Azure AI Search knowledge-base APIs.

The retrieval system has several layers. Microsoft documents indexed and remote knowledge sources, keyword, vector, and hybrid retrieval paths, and an agentic retrieval engine that can plan queries, select sources, run parallel searches, and aggregate results. It also documents extractive content and citations as a way to let an agent reason over returned evidence. Optional LLM processing affects certain reasoning modes; it is not a universal prerequisite for basic retrieval. These descriptions are architecture and product-interface statements, not independent evidence that a given corpus will produce accurate or complete answers.

Microsoft’s product page presents the intended enterprise story: reusable knowledge bases, connections to sources such as Azure Blob Storage, SharePoint, OneLake, web data, and MCP servers, incremental indexing, document-level permissions, and serverless usage. The page is useful for locating the product’s stated scope. It must be read together with the more specific Learn availability notes and connector documentation, because the product page does not turn every listed path into a GA production commitment.

The GA-versus-preview boundary

The most important confirmed fact is Microsoft’s own qualification: some Foundry IQ capabilities are generally available and others remain preview. The concept page says availability depends on the Azure AI Search REST API version and that Microsoft Foundry portal and Azure portal access continue to provide preview-only access to all agentic retrieval features. The Foundry GA overview separately labels Knowledge (Foundry IQ) as partial GA: API-level GA with portal access remaining preview.

That distinction becomes concrete in Azure AI Search migration guidance. Microsoft identifies 2026-04-01 as the first stable API version for agentic retrieval. In that version, searchIndex, azureBlob, indexedOneLake, and web knowledge-source types are generally available. The same guidance says indexed and remote SharePoint knowledge sources remain preview and are not available in 2026-04-01. It also explains that the stable API deliberately narrows the request contract compared with preview-era model-assisted planning and answer synthesis features.

The Foundry connection guide is another explicit preview boundary. It lists a preview SDK and 2026-05-01-preview REST API version for the documented agent connection path. The hosted-agent quickstart has a prominent warning that items marked preview are provided without a service-level agreement and are not recommended for production workloads. Those sources do not make Foundry IQ unusable; they tell teams to choose a supported path deliberately. A design whose critical connector or agent integration needs a preview endpoint should be governed as a preview dependency, with a different risk and support posture from an API-only stable retrieval implementation.

Permission-aware retrieval is a system design, not a label

Microsoft documents knowledge-source ACL synchronization, Microsoft Purview sensitivity-label handling, query-time permission trimming, and calls under a user’s Microsoft Entra identity. These capabilities address a real enterprise problem: an agent should not receive, cite, cache, or summarize content the requesting user cannot access. The documentation is an important prerequisite for a permission-aware design, but it is not evidence that a customer’s sources, identities, labels, connector setup, and application path are configured correctly.

Validate the authorization chain end to end. Identify the human or workload identity that initiates a request; the identity used by the agent; the identity used by Azure AI Search and each source connector; the ACL or label data that is synchronized; the policy used at retrieval time; and the places citations, activities, prompts, traces, caches, and outputs are stored. Test two representative users with deliberately different permissions against the same question. A protected document must remain absent from the retrieved evidence as well as the final answer, citation list, logs, and cache.

Microsoft’s June Technical Community post discusses governance updates around sensitivity labels, permission synchronization, audit trails, private connectivity, and identity-based access for Foundry IQ scenarios. It is Microsoft-authored evidence of product direction and documented capabilities. It does not replace a customer’s own security architecture, connector validation, network review, retention analysis, or incident exercise.

Implications for enterprise retrieval choices

Foundry IQ changes the architectural unit from “an agent talks to a document store” to “multiple agents can call a shared knowledge base.” That can reduce duplicated source integrations and centralize retrieval configuration. It can also centralize risk: a knowledge-base definition, retrieval policy, source connector, identity choice, or preview dependency can affect many downstream agents. Assign an owner for each of those components and require a versioned change record.

The managed versus open-source RAG stack guide is useful here because the decision is not only whether retrieval quality looks promising. Teams must choose where indexing, source synchronization, embeddings, ranking, access checks, networking, monitoring, and incident response are owned. A managed service can reduce infrastructure work, but it does not eliminate the need to define data boundaries or evaluate the outcomes returned for a particular corpus.

Start the evaluation with an acceptance packet. Name the chosen API version; the exact source types; whether every required component is GA or preview; the Azure AI Search tier and regional constraints; identities and roles; network requirements; expected citations; latency and cost bounds; deletion, update, and index-refresh behavior; and a safe fallback. A generic “Foundry IQ pilot” has too many moving parts to produce a decision-quality result.

For the application layer, define what counts as a useful answer. Measure supported facts, citation correctness, permission preservation, retrieval completeness for representative questions, latency, empty-result behavior, stale-content behavior, and human correction burden. Include adversarial and operational cases: a document that changes permissions, a source synchronization failure, a malformed or empty file, conflicting documents, a source connector outage, an expired identity, a query that should return no evidence, and an untrusted instruction embedded in retrieved content. The RAG quality checklist supplies a structure for separating retrieval evidence from fluent but unsupported answers. The agent evaluation stack guide adds a useful discipline: preserve the test set, record retrieval evidence and reviewer decisions, and rerun it when the API, model, connector, or source configuration changes.

A rollout sequence that respects availability status

First, choose the narrowest documented GA path that fulfills the task. If the workflow requires a preview-only portal or integration, record that decision explicitly and do not describe the system as fully GA. Second, use a small approved corpus with known permissions and expected answers. Third, test under real Entra identities and inspect the retrieved references, not just the final chat response. Fourth, set monitoring, trace, and error-handling expectations before scaling data sources or users.

Then add a second source only after the first has reliable evidence for ingestion, refresh, access control, query-time behavior, and recovery. This sequencing matters because a multi-source knowledge base can hide which source introduced a permission or relevance regression. Preserve an exportable record of the source configuration, API version, model deployment where applicable, retrieval reasoning level, test set, output references, and evaluator decision. When a preview dependency evolves, rerun the same cases before accepting a change.

The internal knowledge assistant guide can help frame the human-facing operating model: who owns content freshness, what the assistant must cite, when a user sees an uncertainty or no-answer state, and how staff correct an answer or report a permissions issue. Those product controls remain necessary even where the retrieval platform supplies a documented permission-aware mechanism.

Sources and verification note

The eight first-party sources listed in frontmatter were checked August 2, 2026. Microsoft’s dated June 2 launch announcement establishes the News event; Microsoft Learn concept, FAQ, GA overview, connection guide, and quickstart material establish the knowledge-base architecture and the GA/preview distinctions. The Azure product page establishes Microsoft’s product positioning. The Technical Community post establishes Microsoft’s account of governance-related updates. The sources are not an independent quality, privacy, security, or performance evaluation.

The editorial conclusion is deliberately limited: Foundry IQ is worth evaluating as a shared, enterprise-retrieval layer only after the exact API, source type, portal or code path, identity chain, and availability status are known. Do not claim universal Foundry IQ GA. Recheck the linked sources before procurement or production rollout, because REST API versions, source support, preview designations, regional availability, pricing, and service terms can change.