Agentic AI at Scale — Why Data Foundations Are the Real Bottleneck

Here's a statistic that should stop every AI initiative in its tracks: eight in ten companies cite data limitations as a roadblock to scaling agentic AI. Not model quality. Not compute availability. Not budget. Data.

McKinsey's April 2026 article, Building the foundations for agentic AI at scale, makes the case clearly: nearly two-thirds of enterprises worldwide have experimented with agents, but fewer than 10 percent have scaled them to deliver tangible value. The gap between experimentation and production isn't about the AI — it's about the data infrastructure the AI needs to operate autonomously.

If you're planning agent deployments for your enterprise — whether it's Microsoft Copilot Studio, Azure AI Foundry, custom multi-agent pipelines, or any combination — the data readiness question needs to come before the agent architecture question. This article walks through why, and gives you a concrete four-step approach with working Azure examples.

The Scale Gap: Why Pilots Fail

The pattern is consistent across organizations I've worked with:

1. The pilot works beautifully. A single agent on a well-defined dataset delivers impressive results. Everyone is excited.
2. Scaling breaks things. When the agent needs to access data across multiple systems, departments, or formats — the quality drops, the latency increases, and the governance gap becomes visible.
3. Trust erodes. Inconsistent results from the agent — because it's pulling from fragmented data sources — make stakeholders pull back.
4. The initiative stalls. Not because the AI failed, but because the data foundation couldn't support the scale.

McKinsey puts it bluntly: while companies have often muscled through fragmented, siloed data in the past, those issues are impossible to manage at scale — and inconsistent governance only increases the challenge of preserving data context while enforcing access control, lineage, and auditability. Shaky data leads to agent breakdowns, inconsistent decisions, and lost coordination.

The analogy the article opens with is the right one: a house is only as strong as its foundation. An agent is only as reliable as the data it can access.

What Agent-Ready Data Actually Requires

Traditional data architecture was designed for human-driven analytics — batch ETL, data warehousing, BI dashboards. Agent-driven systems have fundamentally different data requirements:

Real-Time Access, Not Batch Processing

Agents make decisions in seconds or milliseconds. They can't wait for a nightly ETL refresh. They need access to current data across all relevant sources, with latency in the hundreds of milliseconds range.

Semantic Consistency, Not Just Data Access

An agent that reads "revenue" from a sales system and "revenue" from a finance system needs to know they mean the same thing — or at least understand the transformation between them. Without a shared semantic layer, agents make decisions on inconsistent interpretations. McKinsey is explicit: without this shared semantic foundation, agents may act on incomplete or conflicting interpretations of the same data, increasing error rates and operational risk as scale grows.

Governed Access, Not Open Access

Agents need to access data autonomously, but that access must be governed. Row-level security, column-level masking, purpose-based access controls — these need to apply to agent data access the same way they apply to human access.

Quality at Source, Not Quality After the Fact

Traditional data quality processes clean data after ingestion. Agent systems need quality checks at the point of consumption, because agents can't distinguish high-quality data from low-quality data without explicit signals.

McKinsey's Seven Principles for Agent-Ready Data

The article distills seven architectural principles that distinguish agent-ready data platforms from traditional ones:

1. Treat data ingestion like a product. All data — batch, real-time, structured, or unstructured — enters once and is usable by everyone.
2. Share meaning, not just data. Common definitions through ontologies and knowledge graphs so analytics, AI models, and agents interpret data the same way.
3. Use one data foundation for analytics and AI. Build data once and use it everywhere — reports, machine learning, gen AI — rather than running separate pipelines and platforms.
4. Build trust into the platform by default. Security, access controls, privacy, and AI governance should be automatic, not added later or managed manually.
5. Expose capabilities through stable interfaces. Clear APIs and model access points so teams can build without rework.
6. Make behavior visible and measurable. Continuously track data quality, model performance, speed, and cost.
7. Provide a controlled way to run AI agents. A shared execution layer that enforces enterprise rules and guardrails.

These principles aren't theoretical. They map directly to architectural decisions you can make today.

The Four-Step Approach

McKinsey's prescription is four coordinated steps that link strategy, technology, and people.

Step 1: Identify High-Impact Workflows to Agentify

Don't try to agentify everything. Start with a few high-value, end-to-end workflows where agent autonomy can unlock significant impact, prioritized by value potential, feasibility, and strategic fit.

Practical starting points for Malaysian enterprises:

• Invoice processing — agent reads incoming invoices, extracts data, matches to POs, routes for approval
• Customer inquiry routing — agent classifies incoming queries, routes to the right team, provides context
• Compliance monitoring — agent monitors regulatory changes, maps them to existing policies, flags gaps
• Report generation — agent pulls data from multiple sources, generates structured reports with narrative

For each workflow, map the data sources the agent needs to access. If the agent needs data from 3+ systems with different formats, different access controls, and different update frequencies — that's your data readiness signal.

Step 2: Modernize Each Layer of the Data Architecture

The article walks through the layers of the data stack that need modernization — and importantly, it says to modernize existing platforms rather than rebuild from scratch, building modular, evolutionary architectures:

• Data Source Layer: automate ingestion, quality checks, security, and lineage tracking directly into pipelines — not as one-time reviews.
• Data Platform Layer: connect systems and orchestrate access, synchronization, and real-time interaction. Include vector stores and embedding services for unstructured data, plus agent interoperability standards — MCP for structured context sharing, A2A for agent-to-agent coordination, and AP2 for trusted transactional interactions.
• Semantic Layer: codify business meaning through ontologies and knowledge graphs. This is the layer that prevents agents from acting on conflicting interpretations of the same term.
• Data Products: package curated data as reusable, business-ready assets with clear ownership, quality standards, semantics, and interfaces. Agents consume data products, not raw tables.
• Data Consumption Layer: deliver intelligence into workflows via data APIs, retrieval interfaces, and agentic orchestration services that dynamically assemble context rather than relying on predefined queries.
• Governance & Access Controls: use a medallion architecture that progressively curates data from raw to agent-ready form while preserving lineage and auditability, and an AI gateway that governs model access to unstructured data, enforces usage policies, and records how data is retrieved and used.

Practical foundation in Azure: Fabric OneLake gives you the unified storage layer, with workspace-level isolation and RBAC you can deploy as code:

// Fabric workspace for the agent-ready data foundation
resource fabricWorkspace 'Microsoft.Fabric/workspaces@2023-11-01' = {
  name: 'ws-agent-data-foundation'
  location: 'southeastasia'
  properties: {}
}

// OneLake capacity assignment
resource capacityAssignment 'Microsoft.Fabric/capacityAssignments@2023-11-01' existing = {
  name: 'ca-agent-foundation'
}

# Verify workspace capacity and permissions after deploy
az fabric list workspaces --query "[?name=='ws-agent-data-foundation']" -o table

# Grant the agent service principal read access to curated lakehouse schemas
az role assignment create \
  --assignee <agent-sp-object-id> \
  --role "Reader" \
  --scope /subscriptions/<sub>/resourceGroups/rg-data-foundation

Step 3: Ensure Data Quality Is in Place

Data quality for agent systems is different from data quality for BI. McKinsey calls for a move from periodic cleanup to continuous, real-time quality management, covering structured data, unstructured data, and agent-generated outputs alike.

Unstructured data — documents, emails, tickets — must be held to the same standards: tagging, classification, vector embeddings, and graph-based structuring. And when agents generate data, the same quality, lineage, and reconciliation standards apply to their outputs.

A minimal automated quality gate in Python that an ingestion pipeline can run before data reaches the agent-ready layer:

from datetime import datetime, timedelta, timezone
import pandas as pd

def quality_gate(df: pd.DataFrame) -> dict:
    """Continuous quality checks before data reaches agent consumption."""
    now = datetime.now(timezone.utc)
    checks = {
        "completeness": df["order_id"].notna().mean(),
        "freshness_hours": (now - df["updated_at"].max()).total_seconds() / 3600,
        "duplicate_rate": df.duplicated(subset=["order_id"]).mean(),
    }
    checks["pass"] = (
        checks["completeness"] >= 0.99
        and checks["freshness_hours"] <= 1.0
        and checks["duplicate_rate"] <= 0.001
    )
    return checks

# Fail closed: block the pipeline if the gate fails
result = quality_gate(df)
if not result["pass"]:
    raise RuntimeError(f"Quality gate failed: {result}")

Step 4: Build an Operating and Governance Model for Agentic AI

This is the most underappreciated step. McKinsey is clear that scaling requires an organizational reboot, not just a technology one: human roles shift from execution to supervision and orchestration of agent-driven workflows. In a hybrid human-agent work environment, clear governance is essential for agents to operate transparently and safely at scale.

What this means practically:

• Define what agents can do, which data they can access, and when human approval is required
• Implement audit trails for every agent data access
• Create escalation paths for agent decisions above a defined risk threshold
• Monitor agent behavior for drift — are agents accessing data they shouldn't?

Governance architecture:

Agent Decision
     │
     ▼
┌──────────────┐     ┌──────────────────┐
│ Policy Engine │────▶│ Human Approval   │
│ (risk check)  │     │ (if needed)      │
└──────┬───────┘     └──────────────────┘
       │
       ▼
┌──────────────┐
│ Audit Log    │
│ (every       │
│  access)     │
└──────────────┘

For enterprises running agents through Azure, the audit trail piece is configuration, not custom code — route agent identity access through managed identities and capture sign-in logs:

# Verify agent service principal sign-in activity (audit trail)
az rest --method get --url \
  "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=appId eq '<agent-app-id>'&\$top=50" \
  --query "value[].{time:createdDateTime,ip:ipAddress,status:status.errorCode}" -o table

Connecting This to Malaysian Enterprise Reality

Most Malaysian enterprises I work with have data scattered across:

• On-premises SQL Server databases (often running legacy LOB applications)
• SaaS applications (Salesforce, Dynamics 365, local banking systems)
• Cloud storage (Azure Blob, SharePoint, OneDrive)
• Spreadsheets (the universal data store that nobody wants to admit exists)

The gap between this reality and agent-ready data is significant. But it's not insurmountable — it requires prioritized investment in data infrastructure before agent deployment.

Recommended approach:

1. Start with data inventory — map all data sources, formats, access controls, and update frequencies
2. Build the semantic layer — even a simple business glossary shared across systems dramatically improves agent reliability
3. Pilot with controlled data scope — start agents with access to 1-2 well-governed data sources, expand gradually
4. Invest in Fabric OneLake — as the unified data foundation, it reduces the integration complexity that makes agent deployment brittle
5. Implement governance before scaling — the pilot-to-production gap is almost always a governance gap

Pitfalls to Avoid

From the research and from deployments I've watched closely:

1. Skipping the semantic layer. Teams jump straight to RAG pipelines over raw tables. The agents work in demos, then make contradictory decisions in production because "revenue" means different things in different systems. Build the shared definitions first — even a minimal ontology pays for itself.

1. Treating agent access like service account access. Reusing a shared credential for all agents destroys auditability. Every agent workload needs its own managed identity with scoped permissions, so you can trace which agent accessed what and when.

1. Bolting governance on after the pilot. Retrofitting row-level security, lineage, and audit logging onto a working pilot is 5-10x more expensive than designing it in from day one. The pilot that "just works" with open access becomes the production blocker.

1. Ignoring agent-generated data. Agents that write data back — updating records, creating tickets, generating reports — produce data that must flow through the same governed interfaces as human-generated data. Uncontrolled agent writes are a silent corruption path.

1. Rebuilding instead of modernizing. McKinsey warns against the temptation to rebuild everything from scratch. The strongest organizations build modular, evolutionary architectures where components can be replaced as new technologies emerge. Your existing SQL Server estate is not the enemy — ungoverned access to it is.

Key Takeaways

1. Data is the bottleneck, not AI capability. Eight in ten companies cite data limitations as a roadblock to scaling agentic AI, and fewer than 10 percent of enterprises have scaled agents to deliver tangible value. Fix your data foundations before investing in agent architecture.

1. Agent-ready data has different requirements than BI-ready data. Real-time access, semantic consistency, governed autonomous access, and quality at source are non-negotiable for agent systems.

1. Follow the four steps in order: identify high-impact workflows, modernize the data architecture layers, enforce continuous data quality, and build the operating and governance model.

1. Govern before you scale. The pilot-to-production gap is a governance gap. Every agent needs its own identity, audit trail, and escalation path before you expand data access beyond a controlled pilot scope.

1. Modernize, don't rebuild. Modular, evolutionary architectures beat greenfield rewrites — especially for Malaysian enterprises with significant on-prem and SaaS estates.

Source: McKinsey, "Building the foundations for agentic AI at scale," April 2, 2026. Related reading: Microsoft Fabric Data Agents — Building Agentic AI on Your Enterprise Data, AI Agent Governance in Enterprise, and FinOps for AI Agents.