Foundry IQ Explained: Building Governed Knowledge for Enterprise AI Agents

An enterprise AI agent can only be as reliable as the knowledge it retrieves.

Connecting an agent to SharePoint, Azure Blob Storage, OneLake, or a search index may give it access to useful information. However, access alone does not tell the agent which source is authoritative, whether a policy is still current, how multiple documents should be combined, or whether the user is allowed to see the answer.

That is where Microsoft Foundry IQ becomes important.

Foundry IQ creates a managed knowledge layer between enterprise information and the agents that use it. Organizations can connect internal and external sources to reusable knowledge bases, apply permission-aware retrieval, improve search quality through agentic retrieval, and return source-backed information that agents can use to generate grounded answers.

Microsoft describes Foundry IQ as a managed knowledge layer for enterprise data. It connects structured and unstructured information across Azure, SharePoint, OneLake, and the web so agents can retrieve relevant knowledge while respecting user permissions.

The result is not simply a better chatbot. It is a reusable knowledge architecture that can support customer service agents, employee assistants, technical support tools, compliance workflows, research applications, and other enterprise AI experiences.

Quick Answer

Foundry IQ is Microsoft’s managed knowledge layer for enterprise AI agents.

It allows organizations to create knowledge bases that connect one or more enterprise sources, including SharePoint, Azure Blob Storage, OneLake, Azure AI Search indexes, and public web content. When an agent submits a question, Foundry IQ can break the request into focused subqueries, search multiple sources, apply semantic reranking, enforce permissions, and return relevant content with citations.

Because multiple agents can use the same knowledge base, organizations can build enterprise knowledge once and reuse it across different applications, teams, and agent experiences.

In This Blog

• What Is Microsoft Foundry IQ?

• Why Enterprise Agents Need a Knowledge Layer

• What Makes Enterprise Knowledge Governed?

• The Core Components of Foundry IQ

• How Agentic Retrieval Works

• Indexed and Remote Knowledge Sources

• How Foundry IQ Improves Traditional RAG

• Why Reusable Knowledge Bases Matter

• Security and Permission-Aware Retrieval

• Foundry IQ and Microsoft Foundry Agent Service

• Foundry IQ Compared with Other AI Knowledge Approaches

• A Practical Foundry IQ Example

• How to Build a Reliable Foundry IQ Knowledge Base

• How to Evaluate Retrieval and Answer Quality

• How Foundry IQ Fits into Microsoft IQ

• What Foundry IQ Means for the Enterprise

• Frequently Asked Questions

What Is Microsoft Foundry IQ?

Foundry IQ is the managed knowledge layer within Microsoft’s enterprise AI platform.

It allows organizations to connect enterprise information to AI agents without requiring each development team to build a separate indexing, retrieval, permission-filtering, and citation system.

A Foundry IQ implementation centers on a knowledge base. The knowledge base references one or more knowledge sources and defines how retrieval should operate. Multiple agents can then query that knowledge base instead of connecting independently to every underlying repository.

Microsoft explains that Foundry IQ knowledge bases can be used by Microsoft Foundry Agent Service, Microsoft Agent Framework, or custom applications that call the knowledge base APIs provided through Azure AI Search.

Foundry IQ can support capabilities such as:

• Connecting multiple internal and external knowledge sources

• Processing and indexing enterprise documents

• Generating vector embeddings

• Extracting useful metadata

• Running keyword, vector, or hybrid searches

• Decomposing complex questions into subqueries

• Selecting appropriate knowledge sources

• Semantically reranking search results

• Returning source content and citations

• Enforcing document-level permissions

• Reusing one knowledge base across multiple agents

Azure AI Search provides the indexing and retrieval infrastructure beneath Foundry IQ. An Azure AI Search resource is currently required to use Foundry IQ knowledge bases.

Microsoft announced Foundry IQ as generally available in June 2026. However, specific source types, APIs, SDKs, authentication patterns, and agent integrations may still have separate preview statuses or limitations. Organizations should review the current Microsoft Foundry IQ documentation for the exact architecture they intend to deploy.

Why Enterprise Agents Need a Knowledge Layer

Most organizations do not have one clean collection of enterprise knowledge.

Instead, information is distributed across:

• SharePoint sites

• OneDrive folders

• Azure storage accounts

• Knowledge management platforms

• Policy libraries

• Product documentation

• Support systems

• Engineering repositories

• OneLake

• Websites

• Databases

• Archived documents

• Department-specific applications

The challenge is not simply finding a document that contains relevant words. An agent must identify the best evidence for a specific question.

Consider an employee who asks:

Can I work remotely from another country for two months?

The organization may have:

• A current remote-work policy

• An older policy that has not been deleted

• A tax guidance document

• An information security policy

• Country-specific legal guidance

• A manager FAQ

• An informal SharePoint page

• A recent policy exception

A basic retrieval system may find several of these sources. However, a reliable enterprise agent must determine which information is current, authoritative, relevant to the employee’s location, and permitted for that user.

This is why enterprise knowledge requires architecture and governance. The agent needs more than content. It needs a retrieval system designed around authority, relevance, freshness, permissions, and traceability.

Foundry IQ provides the technical layer for assembling and retrieving that knowledge. The organization still has to decide which sources belong in the knowledge base and what makes those sources trustworthy.

What Makes Enterprise Knowledge Governed?

A knowledge base does not become governed simply because it is hosted on Azure.

Governed knowledge has clear controls around what information is included, who owns it, who can access it, how it is maintained, and how its quality is measured.

Authority

Users and agents need to know which sources represent approved organizational guidance.

For example, a signed policy in the corporate policy library should normally carry more authority than an informal document created by an individual employee.

Ownership

Every important knowledge domain should have a responsible owner.

The owner should be accountable for accuracy, review schedules, retention, and resolving conflicting information.

Freshness

Enterprise knowledge changes.

Policies are updated, product documentation evolves, laws change, and previous procedures become obsolete. A knowledge base must have a defined refresh strategy so outdated content does not continue influencing agent responses.

Access

Not every user should receive the same answer from the same collection of documents.

Permissions may depend on the person’s department, geography, employment status, customer account, security role, or project assignment.

Traceability

Users should be able to see where an answer came from.

Citations make it possible to validate the source, review the supporting language, and recognize when the evidence is incomplete.

Quality

The organization needs a repeatable way to determine whether retrieval and generated responses are accurate, relevant, complete, and grounded.

Foundry IQ provides capabilities that support these controls. However, effective governance still requires people, processes, source ownership, and testing.

The Core Components of Foundry IQ

Foundry IQ can be understood through three primary components: knowledge sources, knowledge bases, and agentic retrieval.

Knowledge Sources

A knowledge source represents a connection to enterprise content.

Microsoft currently identifies sources such as Azure Blob Storage, SharePoint, OneLake, Azure AI Search, and public web data as supported Foundry IQ scenarios. Depending on the source, content may be indexed into Azure AI Search or retrieved remotely when a question is asked. See Microsoft’s Foundry IQ overview for current source support.

A knowledge source should not be treated as a technical connection alone. Teams should also define:

• What the source contains

• Who owns it

• Which users should access it

• How frequently it changes

• Whether it contains authoritative or supplemental information

• How conflicting content should be handled

• Whether content should be indexed or queried remotely

Knowledge Bases

The knowledge base is the top-level retrieval resource.

It brings together one or more knowledge sources and contains settings that control retrieval behavior. Microsoft allows teams to configure the amount of reasoning used during retrieval, such as minimal, low, or medium retrieval reasoning effort.

A knowledge base should normally represent a coherent business domain or use case.

Examples include:

• Human resources policies

• Product support documentation

• Sales enablement content

• Legal and compliance guidance

• Engineering standards

• Customer onboarding resources

• Manufacturing procedures

• Healthcare administrative policies

Building one enormous knowledge base from every document in the organization may reduce relevance and make ownership difficult. A collection of well-defined domain knowledge bases is often easier to test, secure, and maintain.

Agentic Retrieval

Agentic retrieval is the process Foundry IQ uses to interpret a question and retrieve useful evidence.

Rather than sending one unchanged search query to one index, the retrieval engine can use an optional language model to understand the request, create subqueries, choose sources, run searches in parallel, rerank results, and combine the evidence into a structured response.

How Agentic Retrieval Works

Traditional retrieval often treats the user’s message as a single query.

That approach can work for direct questions such as:

What is the maximum expense allowed for a hotel?

It becomes less reliable when the request includes several concepts, implicit constraints, or conversational context.

For example:

I am traveling to London for a customer workshop next month. What can I book, which approvals do I need, and are there any security requirements for taking my company laptop?

This question spans several possible knowledge domains:

• Travel expenses

• International travel

• Manager approval

• Customer travel

• Information security

• Device handling

• Regional requirements

Foundry IQ’s agentic retrieval process can address this through several stages.

1. Query Understanding and Planning

The system interprets the request and determines what information is needed.

If an LLM is configured for retrieval planning, it can use the question and relevant conversation history to generate focused subqueries.

2. Query Decomposition

The original request may be separated into searches such as:

• London hotel and travel limits

• International travel approval requirements

• Customer workshop expense rules

• Company laptop international security policy

• United Kingdom device or data restrictions

3. Parallel Retrieval

The knowledge base sends these subqueries to the appropriate knowledge sources.

Searches can use keyword, vector, or hybrid retrieval. Hybrid retrieval combines traditional term matching with vector similarity, allowing the system to consider both exact language and semantic meaning.

4. Semantic Reranking

Each result set can be reranked using Microsoft’s semantic ranking capabilities.

Semantic ranking examines the meaning of the query and candidate results to improve the order in which evidence is returned. Microsoft includes semantic reranking within the agentic retrieval pipeline. Learn more in Microsoft’s semantic ranking documentation.

5. Result Synthesis

The knowledge base merges the retrieved information into a unified response for the agent.

Foundry IQ can return extractive source content, citations, and optional execution details. The agent then uses that information to formulate its final response.

This separation between retrieval and response generation matters. The knowledge base is responsible for finding and organizing evidence. The agent is responsible for using that evidence according to its instructions and task.

Indexed and Remote Knowledge Sources

Foundry IQ can work with both indexed and remote knowledge sources.

These approaches solve different enterprise requirements.

Indexed Sources

With an indexed source, content is processed into Azure AI Search.

Depending on the source and configuration, the indexing process may include:

• Document extraction

• Text chunking

• Metadata extraction

• Vector embedding generation

• Search field creation

• Incremental refreshes

• Access-control information

Microsoft says Foundry IQ can automate document chunking, embedding generation, metadata extraction, and recurring indexer runs for supported indexed knowledge sources.

Indexed retrieval is often useful when organizations need:

• Fast search across a large corpus

• Semantic or vector retrieval

• Customized indexing

• Metadata filtering

• Consistent retrieval performance

• Control over how documents are chunked and ranked

Remote Sources

Remote sources are queried at request time rather than fully copied into an Azure AI Search index.

For example, a remote SharePoint knowledge source can use the Copilot Retrieval API to retrieve relevant information while applying existing SharePoint permissions and Microsoft Purview sensitivity labels. Microsoft provides additional detail in the Foundry IQ FAQ.

Remote retrieval may be useful when:

• Content changes frequently

• Information should remain in its existing system

• Existing permission models should be evaluated directly

• The organization wants to reduce duplicated content

• Real-time source access is more important than custom indexing

Choosing the Right Approach

The decision should be based on more than performance.

Teams should consider:

• Data residency

• Update frequency

• Permission requirements

• Search relevance

• Indexing cost

• Query latency

• Source availability

• Metadata quality

• Content volume

• Compliance requirements

A single knowledge base may reference more than one source, allowing organizations to combine indexed and remote retrieval where appropriate.

How Foundry IQ Improves Traditional RAG

Retrieval-augmented generation, or RAG, grounds a language model in external information.

A typical RAG application includes:

1. A collection of source documents

2. A process for extracting and chunking content

3. An embedding model

4. A vector or search index

5. Retrieval logic

6. A prompt that provides retrieved content to a model

7. A generated response

This pattern can produce useful results, but developing an enterprise-ready implementation often requires significant custom work.

Teams may need to build and maintain:

• Ingestion pipelines

• Chunking strategies

• Embedding workflows

• Search indexes

• Keyword and vector retrieval

• Query rewriting

• Security filters

• Document-level permissions

• Citations

• Refresh schedules

• Monitoring

• Evaluation systems

• Agent integrations

Foundry IQ packages many of these capabilities into a managed knowledge layer built on Azure AI Search.

More importantly, agentic retrieval advances beyond the basic single-query RAG pattern. Azure AI Search can use an LLM to decompose complex questions, issue several searches in parallel, apply semantic ranking, and return structured grounding content with citations and execution metadata. Learn more in Microsoft’s agentic retrieval overview.

This does not mean every organization should abandon its existing RAG architecture.

Custom RAG may still be appropriate when teams need:

• Complete control over the retrieval pipeline

• Specialized ranking algorithms

• A non-Azure search platform

• Proprietary chunking and enrichment

• Unique latency or infrastructure requirements

• Highly specialized data formats

• Custom embedding or knowledge graph architectures

Foundry IQ is most valuable when organizations want a Microsoft-managed, permission-aware retrieval layer that can be reused across multiple agents and integrated with the broader Microsoft agent platform.

Why Reusable Knowledge Bases Matter

Without a shared knowledge layer, every agent team may build its own version of enterprise retrieval.

The HR team may create one index of employee policies. The internal support team may index many of the same documents again. A manager assistant may build another retrieval pipeline over overlapping SharePoint sites.

Over time, these implementations can drift.

They may use different:

• Source documents

• Refresh schedules

• Chunking configurations

• Embedding models

• Security rules

• Ranking strategies

• Prompts

• Citations

• Definitions of authoritative content

As a result, two agents may provide different answers to the same organizational question.

Foundry IQ allows multiple agents to reference the same knowledge base. Microsoft explicitly identifies knowledge-base reuse across agents as a core capability.

This creates several advantages.

Consistency

Agents use the same governed sources and retrieval configuration.

Efficiency

Teams do not need to rebuild ingestion, indexing, and retrieval for every use case.

Centralized Maintenance

When a source changes or a retrieval configuration is improved, every connected agent can benefit.

Clearer Ownership

A business team can own the knowledge domain while multiple development teams build experiences on top of it.

Better Evaluation

The organization can test the knowledge base independently from each agent’s user interface or workflow.

This separation creates an important architectural boundary:

• The knowledge team governs the evidence.

• The agent team governs the behavior.

• The application team governs the user experience.

• Security teams govern identity, access, and monitoring.

Security and Permission-Aware Retrieval

An enterprise knowledge base must not return the same content to every user.

Foundry IQ supports permission enforcement that varies by knowledge source.

For indexed sources, document-level security may be implemented through access control lists, Azure role-based access control, or a combination of the two. At query time, results can be filtered according to the user’s identity.

For remote SharePoint sources, permissions can be enforced through the Copilot Retrieval API, including support for SharePoint ACLs and Microsoft Purview sensitivity labels. See Microsoft’s Foundry IQ security guidance.

Foundry IQ can also run queries under the caller’s Microsoft Entra identity, supporting end-to-end permission enforcement when the selected integration and source support that identity flow.

Managed Identities and Role-Based Access

Microsoft recommends managed identities with Microsoft Entra ID for service-to-service access in production environments.

For example, a Microsoft Foundry project can use a system-assigned managed identity to connect securely to Azure AI Search. That identity can receive the Search Index Data Reader role for read-only retrieval access. Microsoft explains this setup in its Foundry IQ connection documentation.

Permissions Do Not Replace Knowledge Governance

Permission enforcement answers the question:

Is this user allowed to retrieve this document?

It does not answer:

Is this the correct document for the agent to use?

An outdated policy may be fully secured and still produce the wrong answer. A duplicate document may have the proper ACL but conflict with the approved version.

Organizations still need to address:

• Obsolete content

• Duplicate policies

• Missing owners

• Overly broad access

• Incorrect metadata

• Conflicting instructions

• Documents without review dates

• Sensitive content stored in the wrong location

Security and knowledge quality must be managed together.

Foundry IQ and Microsoft Foundry Agent Service

Foundry IQ and Microsoft Foundry Agent Service are related, but they serve different purposes.

Foundry Agent Service is a managed platform for creating and operating agents. It supports prompt agents managed by Microsoft and hosted agents built with frameworks such as Microsoft Agent Framework, LangGraph, the OpenAI Agents SDK, and custom code.

A Foundry agent can connect to a Foundry IQ knowledge base through Model Context Protocol.

When the agent invokes the knowledge-base tool, Foundry IQ handles query planning, decomposition, retrieval, reranking, and result synthesis. The resulting evidence is then returned to the agent with source references. Microsoft explains the integration process in its Foundry IQ connection guide.

Microsoft currently exposes the knowledge_base_retrieve MCP tool for this integration.

Agent instructions still matter. Microsoft recommends explicitly telling the agent to use the knowledge base, include citations, and say that it does not know when the knowledge base does not contain sufficient information.

That last instruction is especially important. A governed agent should be able to abstain rather than filling gaps with unsupported model knowledge.

Foundry IQ Compared with Other AI Knowledge Approaches

Foundry IQ is one way to provide agents with enterprise knowledge, but it is not the only option.

Foundry IQ Is Not Fine-Tuning

Fine-tuning can help a model follow a particular format or perform a specialized task. It does not provide a reliable way to keep enterprise facts current.

A policy update should not require retraining a model. It should be updated in the authoritative source and made available through the knowledge layer.

Foundry IQ Is Not a Transactional API

A knowledge base is well suited for policies, manuals, guidance, documentation, and other information-oriented content.

For a question such as “What is the current inventory level for item 421?” a direct business data tool or Fabric IQ may be more appropriate.

Foundry IQ Is Not Just Search

Search returns documents or passages.

Foundry IQ coordinates retrieval for an agent. It can plan a complex question, search multiple sources, rerank results, preserve references, and produce a unified set of grounding evidence.

A Practical Foundry IQ Example

Consider a manufacturing company that wants to create a technical support agent for maintenance teams.

The company’s knowledge is spread across:

• Equipment manuals in Azure Blob Storage

• Standard operating procedures in SharePoint

• Safety policies

• Historical troubleshooting guides

• Product bulletins

• Engineering specifications

• Warranty documentation

• Public manufacturer websites

• OneLake maintenance data

A technician asks:

The Model X packaging machine is showing error 218 after a belt replacement. What should I check before restarting the line?

Without a Governed Knowledge Layer

A basic agent may find several passages containing “error 218” or “belt replacement.”

However, it may retrieve:

• A manual for an older machine revision

• An unofficial troubleshooting note

• A procedure that applies to a different production facility

• A repair step that conflicts with the current safety policy

• A public forum post that should not override internal guidance

The answer may sound confident while combining incompatible sources.

With Foundry IQ

The organization can create a maintenance knowledge base containing approved sources.

The knowledge base may include:

• Current machine manuals

• Facility-specific operating procedures

• Approved safety requirements

• Engineering bulletins

• Troubleshooting guides

• Public manufacturer information as a supplemental source

When the technician submits the question, agentic retrieval can divide the request into several parts:

1. Identify error 218 for the correct machine model and revision.

2. Retrieve the approved belt replacement procedure.

3. Retrieve restart and lockout safety requirements.

4. Check for engineering bulletins related to the error.

5. Identify facility-specific restrictions.

The knowledge base can search those sources in parallel, rerank the results, and return relevant passages with citations.

The agent can then produce a response such as:

• Verify the belt alignment using the current Model X procedure.

• Inspect the tension sensor associated with error 218.

• Complete the documented safety checklist before restart.

• Do not restart if the sensor remains outside the approved range.

• Escalate to the maintenance supervisor under the listed conditions.

The technician can review the cited manual, safety policy, and engineering bulletin before acting.

If Fabric IQ is also connected, the agent could incorporate real-time maintenance history, sensor readings, asset relationships, or parts availability. Foundry IQ supplies the approved institutional knowledge, while Fabric IQ supplies the current business and operational data.

How to Build a Reliable Foundry IQ Knowledge Base

The quality of a Foundry IQ implementation depends heavily on decisions made before the first agent connects to it.

1. Start with a Knowledge Domain

Choose a focused area with clear users and business value.

Examples include:

• Human resources policy

• IT support

• Legal intake

• Product documentation

• Sales enablement

• Customer onboarding

• Safety procedures

• Engineering standards

Avoid beginning with “all company knowledge.”

2. Define the Questions the Knowledge Base Should Answer

Collect representative questions from actual users.

Include:

• Common questions

• Complex multistep questions

• Questions involving exceptions

• Questions that should return “I don’t know”

• Questions that require restricted content

• Questions that are frequently misunderstood

These questions will later become part of the evaluation dataset.

3. Identify Authoritative Sources

For each question type, identify the source that should control the answer.

Document:

• Source owner

• Review date

• Update frequency

• Intended audience

• Geographic scope

• Business unit

• Sensitivity

• Retention requirements

• Authority relative to other sources

4. Remove or Isolate Obsolete Content

Do not assume the retrieval system will always recognize the newest document.

Archive old versions, mark superseded content clearly, or exclude it from the knowledge base.

5. Choose Indexed or Remote Retrieval

Use indexed sources when semantic search, customized metadata, large-scale retrieval, or controlled enrichment is important.

Use remote retrieval when information should stay in its system, changes rapidly, or depends heavily on source-native permissions.

6. Improve Metadata

Metadata can help the retrieval system distinguish between otherwise similar documents.

Useful fields may include:

• Document type

• Product

• Region

• Department

• Effective date

• Expiration date

• Policy owner

• Version

• Audience

• Facility

• Security classification

7. Design Permission Enforcement

Determine whether access should be based on:

• Source ACLs

• Azure RBAC

• Microsoft Entra groups

• SharePoint permissions

• Document security fields

• User identity passthrough

• Microsoft Purview labels

Test both permitted and prohibited access scenarios.

8. Configure Retrieval Deliberately

Retrieval decisions may include:

• Keyword, vector, or hybrid search

• Semantic ranking

• Retrieval reasoning effort

• Search filters

• Source selection

• Chunk size

• Overlap

• Embedding model

• Number of returned passages

• Citation format

There is no universal configuration that works equally well for every domain.

9. Write Clear Agent Instructions

Tell the agent:

• When to use the knowledge base

• Which types of questions it covers

• Whether it may use general model knowledge

• How to cite sources

• How to handle conflicting information

• When to abstain

• When to escalate to a person

Microsoft specifically recommends instructing Foundry agents to invoke the knowledge base, include citations, and respond with “I don’t know” when the required information is not present. See Microsoft’s Foundry IQ agent connection guidance.

10. Establish an Ongoing Review Process

A production knowledge base needs regular maintenance.

Track:

• New sources

• Retired documents

• Failed searches

• User feedback

• Low-confidence answers

• Permission errors

• Citation quality

• Retrieval latency

• Content freshness

• Changes in user questions

Foundry IQ is a managed technical layer, not a substitute for knowledge management.

How to Evaluate Retrieval and Answer Quality

A successful demonstration is not enough to establish that a knowledge base is production-ready.

Teams should evaluate both the retrieval process and the agent’s final response.

Microsoft Foundry provides evaluators for RAG and agent scenarios, including measures for groundedness, relevance, response completeness, and retrieval quality. See Microsoft’s RAG evaluation documentation.

Retrieval Quality

Retrieval evaluation asks whether the system found the right evidence.

Questions include:

• Were the most relevant passages retrieved?

• Was the authoritative source included?

• Were irrelevant documents ranked too highly?

• Did the retrieval process miss a critical policy?

• Did source filtering work correctly?

• Did complex questions produce appropriate subqueries?

Microsoft’s retrieval evaluators can assess the relevance of retrieved chunks and compare retrieved documents with labeled ground-truth results.

Groundedness

Groundedness measures whether the response stays within the retrieved evidence.

A response may be well written and still fail groundedness if it introduces unsupported claims.

Relevance

Relevance measures whether the response directly addresses the user’s actual question.

A long answer that summarizes several documents without resolving the request may still be low quality.

Response Completeness

Completeness evaluates whether the response includes the critical information expected in the answer.

Microsoft distinguishes groundedness from completeness: groundedness focuses on avoiding unsupported content, while completeness focuses on whether the answer omitted essential information.

Citation Quality

Citations should support the specific claims made in the answer.

Teams should test whether:

• The cited document contains the supporting information

• Links open for the user

• The cited version is current

• Restricted sources remain protected

• Citations are specific enough to validate the answer

Business Outcomes

Technical scores should connect to business performance.

Depending on the use case, outcomes may include:

• Reduced time searching for information

• Faster case resolution

• Fewer policy interpretation errors

• More consistent customer responses

• Reduced escalation volume

• Faster employee onboarding

• Improved first-contact resolution

• Greater use of approved documentation

How Foundry IQ Fits into Microsoft IQ

Foundry IQ is one part of Microsoft’s broader enterprise intelligence architecture.

Microsoft describes Microsoft IQ through four interconnected capabilities.

Consider a procurement agent evaluating a vendor exception.

Work IQ Could Provide

• Recent emails with the vendor

• Internal Teams discussions

• Meeting notes

• The employees responsible for the decision

• Previous approvals and commitments

Fabric IQ Could Provide

• Vendor spending

• Contract values

• Delivery performance

• Risk scores

• Supplier relationships

• Open purchase orders

Foundry IQ Could Provide

• Procurement policies

• Security review requirements

• Contract templates

• Legal guidance

• Approval procedures

• Vendor onboarding documentation

Web IQ Could Provide

• Current company news

• Regulatory developments

• Public security incidents

• Market changes

Foundry IQ is the institutional knowledge layer in that architecture. It helps the agent determine what the organization’s approved guidance says, while the other IQ capabilities provide workplace, business, and external context.

What Foundry IQ Means for the Enterprise

Many early AI projects focus on selecting a model.

Enterprise deployments quickly discover that the model is only one part of the system.

An agent also needs reliable answers to questions such as:

• Which sources should I search?

• Which document is authoritative?

• Is the information current?

• Does this source apply to this user?

• Am I allowed to retrieve it?

• Which passages support the answer?

• What should I do when the evidence is incomplete?

• How can another agent reuse the same knowledge?

• How will the organization measure whether retrieval is working?

Foundry IQ addresses these questions by creating a managed, reusable knowledge layer for agents.

Azure AI Search provides the retrieval infrastructure. Knowledge sources connect enterprise information. Knowledge bases organize that information into governed domains. Agentic retrieval plans and executes more sophisticated searches. Microsoft Entra ID, ACLs, RBAC, and Microsoft Purview can help preserve access controls. Microsoft Foundry evaluation provides tools for measuring groundedness, relevance, retrieval quality, completeness, and other dimensions.

The larger opportunity is not to connect every agent to every document.

It is to create trusted knowledge products that agents can use consistently.

A well-designed HR knowledge base can support an employee assistant, manager agent, onboarding experience, and service desk application. A governed product knowledge base can support customer service, sales engineering, implementation teams, and external self-service experiences.

This is how enterprise knowledge becomes reusable infrastructure instead of a collection of isolated files and custom retrieval projects.

Emergent Software helps organizations design, build, evaluate, and govern enterprise AI agents across Microsoft Foundry, Microsoft 365, Copilot Studio, Microsoft Fabric, Azure AI Search, and custom applications.

Explore Emergent Software’s Copilot and custom AI agent development services or contact our team to discuss how Foundry IQ can support secure, grounded, and scalable enterprise AI.

Frequently Asked Questions

What is Microsoft Foundry IQ?

Foundry IQ is Microsoft’s managed knowledge layer for enterprise AI agents. It connects structured and unstructured information to reusable knowledge bases that support permission-aware retrieval, agentic search, citations, and grounded AI responses.

Is Foundry IQ the same as Microsoft Foundry?

No. Microsoft Foundry is the broader platform for building, deploying, evaluating, and operating AI applications and agents. Foundry IQ is the knowledge layer within that ecosystem, while Foundry Agent Service is used to build and run the agents themselves.

Is Foundry IQ the same as Azure AI Search?

No, although the two are closely connected. Azure AI Search provides the indexing, ranking, and retrieval infrastructure that powers Foundry IQ knowledge bases, and an Azure AI Search resource is currently required to use them.

What is a Foundry IQ knowledge base?

A knowledge base is a reusable retrieval resource that references one or more knowledge sources and controls how searches are performed. Multiple agents and applications can query the same knowledge base, allowing the organization to centralize retrieval logic and source governance.

What knowledge sources can Foundry IQ use?

Microsoft documents support for sources that include Azure Blob Storage, SharePoint, OneLake, Azure AI Search, and public web content. Supported source types and capabilities may vary depending on whether the source is indexed or queried remotely.

What is agentic retrieval?

Agentic retrieval uses a language model and search technologies to plan a question, divide it into subqueries, search relevant sources in parallel, semantically rerank the results, and return combined evidence with source references. It is designed to improve retrieval for complex or conversational questions.

Is Foundry IQ a RAG solution?

Yes. Foundry IQ provides a managed, enterprise-oriented retrieval layer for RAG and agent scenarios. It expands on basic RAG through reusable knowledge bases, agentic query planning, hybrid retrieval, semantic ranking, permission enforcement, and citation-backed results.

Does Foundry IQ replace fine-tuning?

No. Fine-tuning changes how a model behaves or performs a task, while Foundry IQ retrieves current enterprise information at query time. Organizations may use both, but fine-tuning is not a reliable replacement for current, cited organizational knowledge.

How does Foundry IQ enforce permissions?

Permission enforcement depends on the knowledge source. Foundry IQ can support document-level ACLs, Azure RBAC, SharePoint permissions, Microsoft Purview sensitivity labels, managed identities, and user identity-based filtering where supported.

Can multiple agents use the same Foundry IQ knowledge base?

Yes. Microsoft designed Foundry IQ knowledge bases to be reusable across multiple agents and applications. This can improve consistency, reduce duplicated retrieval infrastructure, and centralize maintenance of enterprise knowledge.

How is Foundry IQ different from Work IQ?

Work IQ provides context about people, meetings, communication, collaboration, and how work gets done. Foundry IQ provides curated institutional knowledge from authoritative documents, policies, enterprise repositories, and reusable knowledge bases.

How is Foundry IQ different from Fabric IQ?

Fabric IQ provides semantic and operational context about business data, metrics, entities, relationships, rules, and actions. Foundry IQ primarily provides governed institutional knowledge and document-centered retrieval, although knowledge bases can also connect to structured sources.

Is Foundry IQ generally available?

Microsoft announced Foundry IQ as generally available in June 2026. However, individual source types, SDKs, MCP integrations, APIs, authentication methods, and related capabilities may have separate preview statuses, so organizations should review current Microsoft documentation before production deployment.

Where should an organization start with Foundry IQ?

Start with one clearly owned knowledge domain and a defined set of user questions. Identify authoritative sources, remove obsolete information, configure permissions and retrieval, connect one or more agents, and evaluate both retrieval quality and final answer quality before expanding.