Microsoft Foundry
Naming: Azure AI Studio became Azure AI Foundry (Ignite 2024), which became Microsoft Foundry (Ignite, November 2025). You will see all three names in docs and job descriptions - they are the same product line.
Microsoft Foundry is Microsoft's hub for building with foundation models and agents - browse and deploy models, build and run agents, run evaluations, and wire in the rest of the Microsoft data stack. If your background is Vertex AI or Bedrock, the concepts map over almost directly; only the names and portal change.
Microsoft Foundry (formerly Azure AI Foundry, and before that Azure AI Studio) is Microsoft's model catalog, deployment, agent and evaluation layer - the Azure-native equivalent of Google's Gemini Enterprise Agent Platform (formerly Vertex AI) or Amazon Bedrock plus AgentCore. The November 2025 rename put agents at the centre: the Foundry Agent Service hosts agents with tools, memory and evaluation alongside model deployments. It sits alongside Microsoft Fabric (data platform) and Azure's core data services in a typical enterprise Microsoft-stack deployment.
- Trace the Azure AI Studio -> Azure AI Foundry -> Microsoft Foundry naming and map Foundry's pieces to Bedrock and Google's agent platform
- Explain what OneLake changes about Microsoft Fabric compared with BigQuery
- Choose between Azure SQL, Cosmos DB and Azure AI Search for a RAG workload
- AWS Bedrock - the comparison point
Model Catalog, Deployments, Evaluations
Foundry's model catalog lists everything from OpenAI's models (and, via Foundry, partner models such as Anthropic's Claude) to open-weight models like Llama, Mistral and DeepSeek, all deployable from one place with one billing relationship. Built-in evaluation tools score deployed models on quality and safety before they go live.
The model catalog includes first-party (Azure OpenAI Service models), Microsoft-curated open models, and partner models, each deployable as a managed online endpoint. Evaluations run built-in or custom metrics (groundedness, relevance, safety) against a deployed model or a full workflow - functionally similar to Google's agent-platform evaluation service or a custom LLM-as-judge harness, but as a first-party managed feature rather than something you assemble yourself.
Microsoft Fabric vs BigQuery
Fabric is Microsoft's unified data platform - warehousing, pipelines, and BI in one product, the rough equivalent of Google's BigQuery ecosystem for teams standardized on Microsoft.
Fabric unifies what BigQuery + Dataflow + Looker cover separately on GCP: a lakehouse (OneLake, a single logical data store underneath every Fabric workload), warehousing (Fabric Warehouse), pipelines (Data Factory, now inside Fabric), and BI (Power BI, natively integrated). The single-storage-layer design (OneLake) is Fabric's core differentiator versus BigQuery's more storage-agnostic model.
Azure Data Services
Two data stores come up constantly in Azure-stack roles: Azure SQL (a managed relational database) and Cosmos DB (a globally distributed NoSQL database) - roughly the Azure equivalents of Cloud SQL and Firestore on GCP.
Azure SQL Database is a managed, auto-scaling relational database (SQL Server-compatible) - roughly Cloud SQL's positioning. Cosmos DB is a multi-model (document/key-value/graph/column-family), globally distributed NoSQL database with five tunable consistency levels - the closest GCP match is Firestore; it is not a relational, strongly consistent SQL database like Spanner. It is commonly used as a vector store for RAG on Azure via its native vector search support.
Study Notes
Must-know for interviews:
- Microsoft Foundry (formerly Azure AI Foundry, formerly Azure AI Studio) = model catalog + deployments + Agent Service + evaluation - the Azure counterpart of Google's agent platform and Bedrock + AgentCore
- Microsoft Fabric's core differentiator vs BigQuery is OneLake - one logical storage layer underneath every workload type
- Azure SQL ≈ Cloud SQL (managed relational); Cosmos DB ≈ Firestore (globally distributed, multi-model NoSQL, tunable consistency)
- Cosmos DB has native vector search, making it a viable RAG vector store on Azure without a separate vector database
Check Yourself
- Which Google Cloud service is the closest match to Cosmos DB?
- What is Microsoft Foundry's naming history?
- What's the single biggest architectural difference between Microsoft Fabric and BigQuery?
- Why might a team pick Cosmos DB as a vector store instead of a dedicated vector database?
Exercises
An Azure team's product catalog (2M items) lives in Cosmos DB; their policy documents (50k PDFs) sit in Blob Storage. They want RAG over both. Recommend where each index lives and why.
Solution
- Catalog: Cosmos DB's native vector search, next to the operational data - no second copy to sync, and filters on item fields run in the same query.
- Policy PDFs: Azure AI Search - document cracking, chunking and hybrid (keyword + vector) retrieval with semantic ranking are built in, which suits long documents.
- An agent (Foundry Agent Service) can call both as tools. The alternative - one AI Search index over both - simplifies retrieval but adds a sync pipeline for fast-changing catalog data.
References
- Microsoft, Microsoft Ignite 2025 recap: agentic AI, Foundry and Azure (2025)
- Microsoft Learn, Microsoft Foundry documentation
Last reviewed: 2026-09