Target Architectures
Target end-state reference architectures for deploying agentic AI. Each follows the same shape - ingest, process through a medallion architecture to a single source of truth, expose through a semantic model to BI and AI applications, and ground agents with retrieval, MCP, and a choice of LLMs - but the native tooling differs by platform.
How to Read These Diagrams
All five use one colour code, so the same concern sits in the same colour on every platform:
| Colour | Layer | What it holds |
|---|---|---|
| Rose border | Data | Source systems, the medallion data foundation, the semantic model |
| Cyan border | AI | Retrieval, LLMs, MCP, agents - anything reasoning over the data |
| Dark dashed border | Interface | Ingestion paths in, and the applications and reporting surfaces out |
| Bronze, silver, gold fill | Medallion | Landing zone, single source of truth, and business-ready models |
The point of holding the code steady across platforms is that the diagrams become comparable: what changes between Databricks, Snowflake, and Google Cloud is the product names, not the shape. Azure and AWS are the exceptions - both are drawn at a wider scope and add the governance, OCR, and platform-component tiers the other three leave implicit.
Microsoft Azure
AI Architecture Recommendation - Microsoft Azure: unified data foundation, grounded AI, agentic automation and enterprise governance
Azure's diagram is drawn wider than the Databricks, Snowflake, and Google Cloud ones. Alongside the medallion foundation on Fabric and the AI foundation, it names the OCR ingestion path (Computer Vision, Azure Document Intelligence), the platform components that keep an agentic system running (Agent 365, Azure Managed Redis, Application Insights, Azure Monitor), and a distinct safety and governance tier (Azure AI Content Safety, Purview, Foundry Guardrails). OneLake backs both the data and AI foundations as one logical store, and the integration layer exposes the Data Agent and MCP to the reporting surfaces rather than letting each application reach into the platform on its own. For the service-by-service detail behind each box, see the Microsoft platform page.
Databricks
Target End State Architecture for Agentic Tasks | Databricks
Ingestion, connectors, and integration land raw data in the same workspace that later serves it, so Mosaic AI reads the governed tables the medallion pipeline produced rather than a copy. The consumption side is what sets Databricks apart: Genie Space answers natural-language questions against the semantic model directly, and Databricks Apps hosts the agentic front end inside the platform instead of a separate web tier. Agent Bricks, the MCP Server, and Vector Search sit on the same side of the platform boundary as the data, which keeps agent tools, retrieval indexes, and source tables under one governance model.
Snowflake
Target End State Architecture for Agentic Tasks | Snowflake
Snowflake adds Openflow to the ingestion tier, which gives the architecture a managed path for streaming and unstructured payloads that would otherwise need an external pipeline tool. This is the most SQL-native of these architectures: Cortex Analyst answers business questions against the semantic model in SQL, and Snowsight is both the development surface and a delivery surface, so a large share of the consumption layer never leaves the account. Native Apps go a step further and let the packaged agent experience be distributed to other Snowflake accounts rather than deployed as a standalone application.
AWS
AI Architecture Recommendation - AWS: unified data foundation, grounded AI, agentic automation and enterprise governance
AWS is drawn at the same wider scope as Azure: it names the OCR ingestion path (Amazon Textract), the platform components that keep an agentic system running (Amazon ElastiCache, Amazon CloudWatch, Amazon SageMaker), and a separate safety and governance tier (IAM, AWS Shield, AWS Secrets Manager). AWS Lake Formation over S3 and Redshift plays the OneLake role, one logical store backing both the data and AI foundations, so medallion tables and retrieval indexes stay under the same governance. What sets it apart is that several tiers hold two products rather than one: OpenSearch and Kendra for retrieval, Claude and OpenAI in the model tier, Bedrock AgentCore and SageMaker AI for agents. That is the component-assembly trade-off made visible - more to decide per use case, none of it locked to a single vendor. Ingestion is correspondingly thin, AWS Fargate and AWS Glue rather than a managed low-code path like Openflow or Cloud Data Fusion, so you run that tier yourself. Consumption sits behind MCP, which fronts Amazon Q, Claude, and a custom chat app. For the service-by-service detail behind each box, see the AWS platform page.
GCP
Target End State Architecture for Agentic Tasks | Google Cloud
Google Cloud keeps Dataflow and Dataproc in the ingestion tier and lets BigQuery carry the whole Process & Transform layer, so the medallion runs in SQL inside the warehouse rather than in a separate compute product. Cloud Data Fusion and Cloud Workflows form the second ingestion path, for documents and external sources. The integration tier is the most code-first of the four: FastAPI and ADK rather than a platform-hosted app runtime, which gives more control over the agent surface at the cost of hosting it yourself. BI is the reverse - Looker and Tableau both read the semantic model, so the reporting layer is the least opinionated of the four.