From OneLake to Agents: Building Modern Data & AI Solutions on Azure

Most enterprises don't have an AI problem. They have a *data* problem wearing an AI costume. The model is rarely the bottleneck — the bottleneck is getting clean, governed, well-connected data to that model and then operating the result responsibly in production. Azure's recent direction tackles exactly this seam, unifying the analytics estate under **Microsoft Fabric** and the AI estate under **Microsoft Foundry** (the platform formerly known as Azure AI Foundry). This post walks through how the two halves fit together and how to reason about an end-to-end architecture.

## The two pillars: a unified data plane and a unified AI plane

For years, a typical analytics stack meant stitching together separate services for ingestion, storage, transformation, warehousing, real-time streaming, and BI — each with its own copies of data and its own governance story. Fabric collapses that into a single SaaS platform built on one logical data lake, and Foundry does the equivalent consolidation for building, deploying, and governing AI agents and models. If you understand these two pillars and the boundary between them, the rest of the Azure Data & AI landscape becomes much easier to navigate.

## OneLake: one copy of data for the whole organization

The center of gravity in Fabric is **OneLake** — a single, logical data lake that is provisioned automatically with every Fabric tenant. The mental model Microsoft uses is "the OneDrive for data": you don't create multiple lakes or manage extra storage accounts, and you can't delete it. It's just *there*, organized into workspaces and data items the same way OneDrive holds Word and Excel files.

A few properties make OneLake more than just another lake:

- **One copy, many engines.** OneLake is built on Azure Data Lake Storage (ADLS) Gen2 and stores all tabular data in open **Delta Parquet** format. A data engineer can load data with Apache Spark, and a SQL developer can then query the *same* data with T-SQL — no copying, no export. Power BI can read it directly through **Direct Lake** mode, giving import-level speed without duplicating data.
- **Shortcuts for zero-copy access.** OneLake shortcuts are embedded references that point to data living in external systems — ADLS, Amazon S3, Google Cloud Storage — or in other Fabric workspaces and tenants. Referenced data appears as part of your local namespace with no ETL and no migration.
- **Governed by default.** Anything that lands in OneLake inherits tenant-level security and compliance policies, with Microsoft Purview built in for sensitivity labels, access policies, and auditing. The OneLake Catalog gives you a single place to discover, secure, and govern items.
- **Built-in protection.** Soft delete retains deleted files for seven days, and zone-redundant storage plus optional BCDR replication guard against data center and regional failures.

## Choosing the right Fabric workload

OneLake is the storage substrate; on top of it, Fabric exposes purpose-built workloads. Picking the right one is mostly a question of data shape and access pattern:

- **Lakehouse** — a unified, scalable home for structured, semi-structured, and unstructured data. Organize it with the **medallion architecture**: Bronze (raw), Silver (validated), Gold (business-ready). Ideal when analytics, ML, and reporting all need to share the same foundation.
- **Data Warehouse** — a fully managed, high-performance SQL engine with full T-SQL support (stored procedures, views, joins) for structured and semi-structured data.
- **Eventhouse / Real-Time Intelligence** — for high-volume event and telemetry data that needs near-real-time ingestion and analysis. Data is automatically indexed and partitioned by ingestion time.
- **SQL database in Fabric** — runs on the same engine as Azure SQL Database and unifies transactional and analytical workloads within the Fabric ecosystem.

Data Factory handles ingestion and orchestration across hundreds of sources, on a schedule or event-driven, and Copilot is embedded across these workloads to assist with authoring and exploration while respecting permission boundaries.

The six-stage lifecycle Fabric is organized around is worth memorizing because it maps cleanly onto how teams actually work: **get data → store → prepare and transform → analyze and train → track and visualize → integrate externally.** Because every stage reads and writes to OneLake, a dataset ingested through a pipeline, refined in a notebook, and visualized in Power BI never moves between engines.

## Microsoft Foundry: the unified AI plane

Once your data is governed and reachable, the AI side belongs to **Microsoft Foundry**, a unified Azure platform-as-a-service for enterprise AI. Foundry consolidates **agents, models, and tools** under one resource provider namespace, with unified role-based access control, networking, policy, tracing, monitoring, and evaluations. If you're coming from Azure OpenAI, you can upgrade an existing resource to a Foundry resource while preserving your endpoint, API keys, and state.

Foundry serves three audiences: application developers building AI products, ML engineers and data scientists who fine-tune and evaluate models, and IT administrators who govern AI resources across teams. Its headline capabilities include:

- **Multi-agent orchestration** — build collaborative agent behavior and multi-step workflows using C# and Python SDKs.
- **A large tool catalog** — connect over 1,400 tools through public and private catalogs, with full authentication support for MCP and A2A protocols.
- **Memory** — agents retain and recall context across interactions without repeated input.
- **Foundry IQ knowledge integration** — ground agent responses in enterprise or web content with citation-backed answers (a turnkey approach to RAG).
- **Publishing** — push agents to Microsoft 365, Teams, BizChat, or containerized deployments.

For lower-code scenarios, **Copilot Studio** offers a SaaS authoring canvas for retrieval and task agents, while GPUs and containers remain available as a code-first, maximum-control path.

## The pattern that ties it together: retrieval-augmented generation

The architectural pattern most teams reach for is **retrieval-augmented generation (RAG)**. A language model trained only on public data is augmented with a retrieval system that injects relevant, grounded data into the request context. This scopes the model's answers to *your* content — vectorized documents, images, and other formats — and gives you control over what the model uses when it responds.

A typical generative AI workflow on Azure looks like this:

1. The application receives a user query.
2. An orchestrator — Foundry Agent Service or the open-source Microsoft Agent Framework — manages the data flow.
3. A search-and-retrieval mechanism locates the grounding data.
4. The grounding data is passed to the generative AI platform.
5. The platform composes a response from the query plus the grounding data.

When you're choosing components: use **Foundry** (or Azure OpenAI for OpenAI-only models) as the generative platform, pick a compute type that fits your performance and budget, and select an orchestrator that supports the agent-orchestration patterns your workload needs. For vector search, Azure offers several options — including extensions like `pgvector` in **Azure Database for PostgreSQL**, which lets you co-locate semantic search with your operational data.

## Don't skip observability and evaluation

The difference between a demo and a production system is everything that happens *after* the model returns a token. Foundry frames the AI application lifecycle in three stages, and each deserves real investment:

- **Base model selection** — compare candidate models on quality, task performance, safety, and cost using benchmarks and the Azure AI Evaluation SDK.
- **Pre-production evaluation** — validate with your own datasets against quality, safety, and custom evaluators, and run an **AI red teaming agent** (built on Microsoft's PyRIT framework) to surface safety and security vulnerabilities before launch.
- **Post-production monitoring** — track operational metrics, run continuous evaluation on sampled production traffic, schedule quality and safety evaluations to catch drift, and schedule recurring red-teaming. Foundry Observability integrates with Azure Monitor Application Insights for real-time dashboards.

Groundedness, relevance, task adherence, and safety aren't one-time gates — they're metrics you watch in production, because real traffic always finds the edge cases your test set missed.

## A reference architecture, end to end

Putting the pieces together, a modern Azure Data & AI solution tends to look like this:

1. **Ingest** operational and external data into OneLake via Data Factory, continuous replication, or shortcuts — no migration required.
2. **Refine** it through the medallion layers in a Lakehouse, with Purview enforcing governance from the moment data lands.
3. **Serve** business-ready Gold data to Power BI through Direct Lake and to AI workloads as grounding data.
4. **Build** agents in Foundry that retrieve from that governed data (RAG), call tools, and maintain memory across turns.
5. **Evaluate** before launch and **monitor** continuously, with red-teaming on a schedule.
6. **Publish** the agent into the surfaces your users already live in — Teams, Microsoft 365, or your own application.

## Closing thought

The strategic shift in Azure's Data & AI stack is consolidation: one governed copy of data in OneLake, one place to build and operate AI in Foundry, and open formats and protocols (Delta Parquet, ADLS APIs, MCP, A2A) so you're not locked into a single engine. The teams that win with AI in the next year won't be the ones with the cleverest prompts — they'll be the ones whose data is governed, reachable, and observable end to end. Start with the data plane, treat evaluation as a first-class engineering discipline, and the agents will have something trustworthy to stand on.