Three Ways to Connect Enterprise Data to AI Agents

Enterprise AI agents need access to business data, but “connect the agent to our data” is not a useful architecture specification.

The agent may need to:

• Retrieve a current customer record
• Check inventory
• Analyze revenue by region
• interpret an organizational policy
• Search a technical manual
• Update a purchase order
• Submit a claim
• Schedule an inspection

These are not variations of the same data-access problem.

Some requests need a live transactional record. Others require governed analytical data with shared business definitions. Others need knowledge retrieval across documents. Some require authority to change business state.

Each requirement calls for a different architecture.

Microsoft recently described three complementary patterns for connecting enterprise data to agents:

1. APIs or MCP capabilities for live operational data and business actions
2. OneLake and Fabric IQ for governed analytics and shared business semantics
3. Foundry IQ for document and organizational knowledge retrieval

For consequential actions, a fourth concern cuts across all three patterns:

4. Capability contracts plus deterministic authorization

The central architectural principle is straightforward:

RAG, Fabric and APIs are not interchangeable data-access strategies.

Choosing the correct pattern requires understanding what the agent needs, how current the information must be, which system is authoritative, what permissions apply and whether the agent is merely reading information or changing the business.

The Data Source Does Not Determine the Access Pattern

Organizations often select an integration pattern based on where the data happens to reside.

That is too simplistic.

The same SQL Server database might contain:

• Current customer account status
• Historical sales transactions
• Text notes entered by customer-service representatives
• Records that initiate regulated business actions

Those uses have different requirements.

A live account-status check may belong behind a controlled API. Historical sales analysis may belong in a governed semantic model. Text notes may need retrieval and citation. Changing the customer’s account status requires an authorized business capability.

Before selecting a technology, ask:

• Is this operational data, analytical data or organizational knowledge?
• Does the agent need the current record or an analytical representation?
• Is the source structured, unstructured or both?
• Must the response include citations?
• Does the organization already maintain a governed semantic model?
• Which identity should be used?
• What permissions apply to this user, agent and action?
• Is the agent reading information or changing business state?
• How much latency is acceptable?
• How stale can the data be?
• Which system remains the source of truth?
• What happens when sources disagree?

These questions determine the correct data-access strategy.

Architecture Decision Matrix

Requirement	Preferred Starting Pattern
Retrieve a current operational record	API or MCP capability
Execute a business operation	API or MCP capability
Analyze governed enterprise data	OneLake and Fabric IQ
Apply shared business definitions and semantic models	OneLake and Fabric IQ
Search documents and organizational knowledge	Foundry IQ
Produce grounded answers with citations	Foundry IQ
Perform a consequential action	Capability contract plus deterministic authorization
Combine operational, analytical and knowledge context	Use multiple patterns behind governed capabilities

This is a starting point—not a vendor-product selection checklist.

A production agent may use all three patterns during one workflow.

For example, a supply-chain agent might:

1. Use Fabric IQ to identify an abnormal trend.
2. Use Foundry IQ to retrieve the relevant operating policy.
3. Use an API capability to retrieve the current purchase order.
4. Submit a proposed change through a governed capability.
5. Apply deterministic authorization rules before updating the order.

The agent coordinates the work. Each data-access pattern retains a different responsibility.

Pattern 1: APIs or MCP Capabilities for Live Records and Business Operations

Use an API or Model Context Protocol capability when the agent needs:

• A current business record
• Real-time or near-real-time operational state
• A controlled query
• A calculation performed by an authoritative system
• A transaction
• A business operation
• A narrowly defined integration with an existing application

Examples include:

• Retrieve the current status of an order
• Check available inventory
• Calculate an account balance
• Validate insurance eligibility
• Create a support ticket
• Update a shipping address
• Schedule an appointment
• Cancel a purchase order

The agent should not connect directly to production tables merely because it can generate SQL.

The safer pattern is to place the operational behavior behind a governed capability.

A capability should define:

• Input contract
• Output contract
• Validation rules
• Identity requirements
• Required permissions
• Permitted operations
• Failure behavior
• Idempotency requirements
• Logging and tracing
• Rate and cost limits
• Escalation conditions
• Ownership and versioning

The underlying implementation might be an ASP.NET Core API, Azure Function, existing enterprise service, Dynamics 365 operation, Microsoft Graph endpoint or another business-system interface.

The agent invokes the capability. The capability owns the business behavior.

API Versus MCP

An API and an MCP server are not mutually exclusive alternatives.

An API defines how software accesses a service or operation. MCP provides a standardized way for AI clients and agents to discover and invoke tools.

An enterprise may already have a stable API that implements an approved business capability. An MCP server can expose that capability to compatible agents without moving the business logic into the MCP layer.

A useful architecture is:

Agent → MCP tool interface → governed API capability → system of record

MCP can improve tool discovery and interoperability, but it does not remove the need for:

• Authentication
• Authorization
• Input validation
• Business rules
• Transaction handling
• Audit logging
• Rate limits
• Version management
• Operational support

MCP is an interface protocol. It is not a replacement for production application architecture.

Use an API Gateway as a Control Layer

Microsoft recommends considering Azure API Management as a runtime governance layer when exposing APIs and MCP capabilities.

A gateway can help centralize:

• Authentication
• Token validation
• Request policies
• Rate limits
• Quotas
• Network restrictions
• Request and response transformation
• Observability
• API versioning
• Lifecycle management

The gateway should not become the location for every business rule. Its purpose is to govern access to capabilities, while application services retain responsibility for domain behavior.

When APIs or MCP Are the Wrong Starting Point

An operational API is not necessarily the best way to answer broad analytical questions.

If an executive asks:

Which product categories experienced declining margins across regions during the last six quarters?

Calling hundreds of transactional APIs and asking an agent to assemble the answer is usually inferior to querying a governed analytical model.

Operational systems optimize individual transactions. Analytical platforms optimize aggregation, comparison and shared business interpretation.

That leads to the second pattern.

Pattern 2: OneLake and Fabric IQ for Governed Analytics and Shared Semantics

Use OneLake and Fabric IQ when the agent needs to reason across governed analytical data using business definitions shared with the rest of the organization.

Typical requirements include:

• Revenue analysis
• Operational performance
• Trend detection
• Cross-department reporting
• Forecast comparisons
• Supply-chain analysis
• Capacity analysis
• KPI interpretation
• Business-entity relationships
• Reuse of Power BI semantic models

The important word is not merely data.

It is semantics.

A raw field named RevenueAmount does not tell the agent:

• Whether it represents booked or recognized revenue
• Whether taxes are included
• Which currency applies
• How returns are treated
• Which date determines the reporting period
• Whether internal transactions are excluded

Organizations already encode many of these definitions in data models, measures, relationships, ontologies and Power BI semantic models.

Fabric IQ helps expose that governed analytical context to agents.

Microsoft describes Fabric IQ as a semantic intelligence layer that allows agents to reason over enterprise analytics in OneLake and Power BI. Depending on the selected capability, agents can work with reports, semantic models, business entities, relationships and operational context.

What Fabric IQ Contributes

Fabric IQ can provide agents with:

• Governed analytical data
• Shared business measures
• Semantic-model metadata
• Entity relationships
• Business vocabulary
• Power BI context
• Existing row-level and object-level security
• Reusable analytical definitions

This helps prevent every agent team from inventing its own meaning for terms such as:

• Active customer
• Net revenue
• On-time delivery
• High-risk claim
• Available capacity
• Qualified opportunity

If finance, operations and sales use different definitions for the same metric, an agent cannot repair the underlying governance problem by generating a more confident answer.

Shared semantics must exist before agents can use them consistently.

Fabric IQ Is Not the Operational System of Record

Analytical data may not be current enough for a transactional decision.

Its freshness depends on how the data is ingested, transformed, modeled and refreshed. A Power BI semantic model may reflect the last successful refresh rather than the current state of the operational application.

Therefore, Fabric IQ may be appropriate for:

Which distribution centers had the highest average fulfillment delays last quarter?

It may not be sufficient for:

Does distribution center 14 have this item available right now?

The second question may require a live inventory capability exposed through an API or MCP tool.

The distinction is:

Fabric IQ explains the business through governed analytical context. Operational capabilities retrieve or change the current business state.

Fabric IQ MCP Does Not Automatically Grant Access

Microsoft’s Fabric IQ MCP tooling applies the signed-in user’s existing Fabric permissions. Connecting an agent through MCP does not grant the user access to reports, semantic models or data they could not otherwise access.

Existing controls such as Power BI row-level security and object-level security continue to restrict returned information.

That is the correct model: the agent should not become a permission bypass.

However, architecture teams must still test:

• Identity propagation
• Permission enforcement
• Row-level filtering
• Object-level filtering
• Query behavior
• Stale-data conditions
• Response limits
• Rate limits
• Failure behavior

A permission-aware service is only one part of a secure end-to-end design.

Pattern 3: Foundry IQ for Documents and Organizational Knowledge

Use Foundry IQ when the agent needs to retrieve information from documents, knowledge sources and unstructured or semi-structured enterprise content.

Typical sources include:

• SharePoint
• Azure Blob Storage
• OneLake
• Policy libraries
• Technical manuals
• Contracts
• Product documentation
• Operating procedures
• Knowledge bases
• Approved public websites

Typical questions include:

• What does the current travel policy allow?
• Which procedure applies to this equipment failure?
• What documentation is required for this claim?
• What does the contract say about termination?
• Which troubleshooting steps apply to this error?
• What evidence supports this answer?

Microsoft describes Foundry IQ as a managed knowledge layer for enterprise data. It can connect multiple knowledge sources, enforce supported permissions, perform agentic retrieval and return grounded information with citations.

Foundry IQ Is More Than a Vector Search Box

Basic retrieval-augmented generation often follows a relatively simple pattern:

1. Convert documents into chunks.
2. Create vector embeddings.
3. Retrieve similar chunks.
4. Place those chunks in the model prompt.
5. Generate an answer.

That pattern can work well for straightforward use cases, but complex enterprise questions may require:

• Query decomposition
• Multiple searches
• Keyword and vector retrieval
• Source selection
• Semantic reranking
• Permission enforcement
• Aggregation across sources
• Citation generation

Foundry IQ uses knowledge bases and agentic retrieval to coordinate these activities. Multiple agents can reuse the same managed knowledge base instead of creating separate retrieval pipelines for every assistant.

This supports centralized management of:

• Knowledge sources
• Retrieval behavior
• Indexing
• Refresh schedules
• Access controls
• Metadata
• Citations
• Reuse across agents

Retrieval Is Not Transaction Execution

Foundry IQ can help an agent answer:

What is our policy for canceling a purchase order?

It should not, by itself, authorize the agent to cancel one.

Retrieving a policy and executing a business operation are different capabilities.

The first requires grounded knowledge. The second requires validated authority to change business state.

A safe workflow might be:

1. Foundry IQ retrieves the applicable purchasing policy.
2. The agent explains the policy and cites the source.
3. An operational API retrieves the current purchase order.
4. Deterministic code validates the order state and cancellation rules.
5. Authorization logic evaluates the agent’s permitted threshold.
6. A human approves the action when required.
7. A governed API performs the cancellation.
8. The complete action is recorded for audit.

RAG retrieves information. It does not grant authority.

Consequential Actions Require Capability Contracts and Deterministic Authorization

The three data-access patterns answer different kinds of questions, but consequential actions require an additional control layer.

An agent should never infer its own authority from the information it retrieves.

If an agent finds a policy stating that purchase orders under $25,000 may be canceled by a department manager, that does not prove:

• The current user is a department manager
• The agent is authorized to act on the user’s behalf
• This purchase order falls under that policy
• The order is still in a cancelable state
• No legal hold or supplier restriction applies
• The transaction amount is below the current threshold
• Additional approval is unnecessary

Those conditions should be verified by deterministic controls.

A consequential capability contract should define:

• The specific action permitted
• Required inputs
• Authoritative data sources
• Caller identity
• Agent identity
• Delegated authority
• Approval thresholds
• Business-rule validation
• Transaction boundaries
• Idempotency behavior
• Evidence retained
• Audit requirements
• Failure and rollback behavior
• Human-approval conditions

The resulting architecture separates responsibilities:

The agent may recommend or request an action. Deterministic services decide whether the action is permitted. A governed capability performs the action.

This prevents probabilistic reasoning from becoming the final authorization mechanism.

RAG, Fabric and APIs Solve Different Problems

These terms are frequently treated as competing approaches:

• “Should we use RAG?”
• “Should we put the data in Fabric?”
• “Should we expose it through MCP?”
• “Should the agent call the API?”

The correct answer may be all of them—but for different responsibilities.

Pattern	Primary Purpose	Typical Source	Freshness	Common Output	Business-State Change
API or MCP capability	Operational retrieval or action	System of record	Current or near-real-time	Structured record or transaction result	Yes, when explicitly authorized
OneLake and Fabric IQ	Governed analytics and semantics	Analytical and semantic models	Depends on ingestion and refresh	Metrics, trends and business context	Generally not the starting point
Foundry IQ	Knowledge retrieval and grounding	Documents and knowledge sources	Depends on indexing or remote source	Evidence, passages and citations	No
Deterministic capability contract	Authorization and execution control	Policies, identity and business services	Current at execution	Approved, rejected or escalated action	Controls the action

Using the wrong pattern creates predictable failures.

Treating Every Data Problem as RAG

RAG is valuable for retrieving knowledge from documents. It is a poor substitute for a live transactional API.

Indexing yesterday’s exported inventory data does not answer whether an item is available now.

Treating Fabric as a Transactional Integration Layer

Fabric can provide governed analytical context, but an analytical model should not automatically become the interface for operational transactions.

Analytics and transaction processing have different consistency, latency and control requirements.

Exposing Raw APIs Without Business Semantics

An API may return accurate fields while leaving the agent to guess what those fields mean.

Operational interfaces need clear descriptions, schemas, units, enumerations and failure behavior. Analytical questions may still require governed semantic models.

Treating MCP as a Security Boundary

MCP standardizes how agents discover and call tools. It does not eliminate the need for identity, authorization, validation, rate limits and auditability.

Every MCP-exposed capability should be treated according to what it can access and do.

A Composite Microsoft Architecture

Consider an enterprise service agent that investigates delayed customer orders.

The agent may need to answer:

• Is the order currently delayed?
• What caused the delay?
• Is this part of a broader regional pattern?
• What does the customer-compensation policy permit?
• Can the shipment be upgraded?
• Does the upgrade require approval?

A composite architecture might use:

Operational API or MCP capabilities

• Retrieve the current order
• Check current inventory
• Retrieve shipment status
• Calculate upgrade cost
• Submit an approved shipment change

OneLake and Fabric IQ

• Compare regional fulfillment performance
• Identify recurring delay patterns
• Apply governed definitions for on-time delivery
• Analyze carrier performance
• Evaluate historical compensation outcomes

Foundry IQ

• Retrieve customer-service policy
• Find carrier-contract provisions
• Search operating procedures
• Return supporting citations

Deterministic authorization

• Verify caller and agent identity
• Enforce compensation limits
• Confirm that the order is eligible
• Require approval above defined thresholds
• Log the decision and resulting action

The agent coordinates these capabilities, but it does not own the data, business rules or authority.

That distinction makes the architecture replaceable and governable.

An assistant, workflow application or future agent can reuse the same capabilities without rebuilding the underlying business logic.

Build a Per-Source Data-Access Decision

Do not choose one data architecture for the entire agent.

Evaluate each source independently.

For every required source, document:

1. Business purpose
   What decision or task does this data support?
2. Data category
   Is it an operational record, analytical dataset or knowledge source?
3. Authoritative owner
   Which system and team own the data?
4. Freshness requirement
   Must it be current, near-real-time, periodically refreshed or historically consistent?
5. Access pattern
   Should the agent use an API, MCP capability, Fabric IQ or Foundry IQ?
6. Identity model
   Does access run under the user, agent, application or workload identity?
7. Permission model
   Which roles, rows, fields, documents or operations may be accessed?
8. Output contract
   Does the capability return a structured result, analytical measure, evidence passage or citation?
9. Action authority
   Can the capability change state? Under what limits?
10. Observability
    What queries, retrievals, tool calls, decisions and actions must be logged?
11. Failure behavior
    What happens when the source is unavailable, stale, incomplete or contradictory?
12. Lifecycle ownership
    Who updates the integration when schemas, policies, tools or models change?

This decision should be made per source and per use case—not once for the entire platform.

Measure Each Pattern Differently

Different access patterns require different operational measurements.

API and MCP capabilities

Measure:

• Availability
• Latency
• Error rate
• Authorization failures
• Schema-validation failures
• Transaction success
• Duplicate-action prevention
• Rate-limit events
• Cost per successful operation

OneLake and Fabric IQ

Measure:

• Data freshness
• Refresh success
• Semantic-model coverage
• Query latency
• Permission enforcement
• Measure consistency
• Query correctness
• Unresolved business terms

Foundry IQ

Measure:

• Retrieval relevance
• Citation correctness
• Source coverage
• Index freshness
• Permission filtering
• Unsupported-answer rate
• Conflicting-source handling
• Grounded-answer quality

Consequential actions

Measure:

• Approval rate
• Rejection and override rate
• Unauthorized-action attempts
• Policy-validation failures
• Human-review burden
• Reversal and correction rate
• Business and regulatory consequences

One generic “agent accuracy” score cannot adequately represent all of these responsibilities.

The Governed Capability Remains the Architectural Unit

Agents will change.

Models will change.

Tool protocols will change.

Microsoft services will continue to evolve.

The durable architecture should therefore be built around governed business capabilities rather than one agent implementation.

A capability such as RetrieveCurrentOrderStatus may use an operational API.

A capability such as AnalyzeRegionalDeliveryPerformance may use Fabric IQ.

A capability such as RetrieveCustomerCompensationPolicy may use Foundry IQ.

A capability such as AuthorizeShipmentUpgrade may combine deterministic business rules, workload identity and human approval.

The consuming agent should not need to know every implementation detail. It needs a clear contract describing:

• What the capability does
• What inputs it requires
• What it returns
• What authority it has
• How it can fail
• How much it costs
• When it should escalate

That is the larger architectural lesson:

The agent is a consumer and orchestrator of governed capabilities. It should not become an uncontrolled shortcut around enterprise data architecture.

Conclusion

There is no universal connector for enterprise data and AI agents.

Use:

• APIs or MCP capabilities for current operational records and controlled business actions
• OneLake and Fabric IQ for governed analytics, shared measures and business semantics
• Foundry IQ for document retrieval, organizational knowledge and grounded answers with citations
• Capability contracts and deterministic authorization whenever an agent can create a consequential business effect

These patterns can work together, but they should not be confused.

RAG does not replace an operational API.

Fabric does not automatically provide current transactional state.

MCP does not replace authorization.

A document stating a policy does not grant permission to execute it.

The correct architecture begins by asking what the agent needs to know, how current that information must be, which system is authoritative and what the agent is permitted to do.

Then connect each source through the pattern designed for that responsibility.

Sources

• Microsoft, “Data Meets Agents,” September 2026.
• Microsoft Learn, “What Is Foundry IQ?.”
• Microsoft Learn, “Get Started With the Fabric IQ MCP Server.”

Related AInDotNet Resources

• Capability Realization for Enterprise AI
• Interfaces: Pillar 5 of Enterprise AI Architecture
• Enterprise AI Agents: Pillar 6 of Enterprise AI Architecture
• Enterprise AI Architecture
• Microsoft AI and .NET Development

Frequently Asked Questions