AI-Ready Data Architecture for RAG, Agents & Feature Stores

Design the six layers behind RAG, feature stores and AI agents - vendor-neutral labs, Databricks and Snowflake mapped.
What you'll learn

---

Draw the six-layer architecture from memory and state what each layer promises the one above it, with an owner and a test for every boundary
Explain why a warehouse that passes every BI test fails a model, and identify the four failure shapes that cause it in your own estate
Apply point-in-time correctness: build an as-of feature set, and recognise the leakage a plain join introduces before it reaches a scorecard
Govern agent access to data: tool contracts, propagated caller identity, and why pre-filtering is the only tenancy control that holds
Reconstruct an automated decision long after the fact, and say what must be captured at decision time for that to be possible at all
Map every layer onto Databricks and Snowflake, including the parts neither platform gives you and you will build regardless
Decide whether your organisation needs a semantic layer, a feature store, a vector store or a tool gateway yet - and defend saying no
Requirements

---

Fluent SQL and working Python. You do not need to be a strong engineer, but you should have shipped a warehouse or a lakehouse before
No machine learning, retrieval or agent experience is assumed. The course is about the data those things consume, not about the models
A laptop that runs Python 3.10 or later. Everything is offline and CPU-only - no cloud account, no API key, no GPU, nothing paid
Helpful but not required: exposure to dbt, DuckDB or any lakehouse table format. Each is introduced where it is first used
Description

---

This course contains the use of artificial intelligence.
You have been told to make the data AI-ready, and nobody has told you what that means. The warehouse already works. Every dashboard reconciles, every test passes, the numbers have been signed off for years. Then the first model goes in front of a real decision and it is useless, and nothing in your monitoring says why.
This course is the architecture underneath that problem, taught end to end on one commercial lender - Larkfield Commercial Finance, invented for this course, with synthetic data you download and run. Six layers: the replay floor, the conformed core, three gold stores rather than one, the semantic layer, the serving stores, and the governed gateway an agent has to call through.
The argument the whole course turns on is that the unit of this architecture is not the layer, it is the boundary between layers. A layer is a promise about what is true, with an owner and a test. An unowned boundary is the thing that actually rots, and you can find them in any architecture diagram in about ten minutes once you know what to look for.
You will see why a warehouse that satisfies every BI stakeholder still fails a model: BI asks what is true when you query, and a model asks what was knowable at a past instant. Change one join from a plain equality to an as-of predicate and the measured AUC on this course's own data falls from 0.9334 to 0.6997. The first number is what leaks, the second is what the model can actually do. Both come out of a script that ships with the course.
It goes where architecture courses usually stop. Why one gold table cannot serve BI, retrieval and inference at the same time. What has to travel with a document chunk for retrieval to be governable, and why a broker being able to retrieve another broker's file is almost always a post-filter. What an agent must never be allowed to do, and what a tool contract has to state before it is allowed to exist. And how you reconstruct an automated decision eighteen months later, when the policy has been superseded twice and every input has moved.
Every hands-on lecture is offline. Python, DuckDB, dbt-core, a local vector index, FastAPI. No cloud account, no API key, no GPU, nothing paid. The labs build one thin slice that accumulates section by section and gets replayed at the end. Alongside them, every section carries a lecture mapping the pattern onto Databricks and Snowflake side by side - the object model and the concept, never a console walkthrough, and plainly where a platform has no equivalent at all.
It also refuses to sell you a platform. There is a lecture on why you probably do not need a feature store yet, another on why one internal assistant over one governed view does not need a gateway, and a self-assessment you run against your own organisation that scores evidence rather than intent and tells you which layer is actually your weakest. The most common failure in this space is building infrastructure nobody asked for, and that is treated as a real risk rather than an aside.
Who this course is for

---

Data engineers and analytics leads told to make the data AI-ready, who have not been told what that means and suspect the answer is not a product
Platform architects who need to design the stack, price each layer honestly, and brief an engineering team on what to build first
Engineering managers deciding what to build, what to buy, and what to refuse - and who need the argument, not a vendor's verdict
Anyone in a regulated industry who will one day be asked why an automated decision was made, and needs the data architecture that can answer
Homepage

---