Agentic Lakehouse Architecture
Seven layers from object storage to agents, with governance across the middle. Free to download and reuse under CC BY 4.0.
An agentic lakehouse is an architecture, not a product: open storage and tables at the bottom, a catalog and engines in the middle, and a semantic layer and agent interface on top, so AI agents get governed answers instead of raw access. The diagram shows each layer, what flows between them, and where governance applies.
Download the diagram
License: CC BY 4.0. Use it in slides, docs, and posts, and adapt it. Credit “Alex Merced, agenticlakehouse.com”.
The layers, bottom to top
Read the diagram from the bottom. Each layer does one job and exposes it through an open interface to the layer above, which is what lets you replace one part without rebuilding the rest. Agents sit at the top and never skip a layer: they do not read files, they do not call the catalog, and they do not write SQL against raw tables.
Object storage
Amazon S3, Azure Data Lake Storage, Google Cloud Storage, or an S3-compatible store such as MinIO. It holds every byte once, as open files (usually Parquet), so no engine or vendor owns the data. See object storage for analytics.
Table format
Apache Iceberg turns a folder of files into a table with ACID commits, snapshots, schema evolution, and hidden partitioning. Its manifests record row counts and value ranges per file, which engines, and guardrails, use to skip data before reading it.
Catalog
The catalog names tables and points each one at its current metadata. An Iceberg REST catalog such as Apache Polaris lets every engine see the same tables and is the first place access control applies: the agent platform gets its own principal with read access to the namespaces it needs.
Query engine
The engine plans and runs SQL over Iceberg tables and enforces grants, row filters, and column masks for the identity running the query. Dremio, Trino, Spark, and DuckDB all read Iceberg; the right one depends on concurrency, latency, and how much governance it enforces natively. See AI query engine.
Semantic layer
Metrics, dimensions, and agent-safe governed views: the definitions the business agreed on, compiled to SQL the engine runs. This is what keeps an agent from inventing its own meaning for revenue. See semantic layer.
Agent interface (MCP)
An MCP server exposes typed tools such as list_metrics and query_metric, with descriptions the agent reads and errors it can act on. No tool accepts raw SQL. The pattern is built step by step in exposing a semantic layer over MCP.
Agents
Assistants, coding agents, and scheduled workflows. They act for a person or a team, so their identity comes from that person, not from the prompt. See autonomous data agents.
Governance, across layers 3 to 6
Governance is not a layer you pass through once. Identity flows from the agent's user into the interface, row and column policies apply in views and the engine, query guardrails cap rows, time, and cost, and the catalog controls which tables exist for whom. Every call lands in an audit log.
Build it
The implementation patterns build the middle of this diagram in Python with working code: an MCP server over an Iceberg catalog, a semantic layer exposed over MCP, governed views, policies, and guardrails.
Build This Architecture Today
Start Your Free Dremio Trial
The semantic layer, MCP server, governance engine, and Iceberg-native query platform in one.
Get Started Free
Architecting an Apache Iceberg Lakehouse
Buy on Manning