Introduction
You built three shapes on one fictional repair chain. None of them depend on auto repair - or on any one warehouse.
In this lesson, you will see how to port the shapes to your own lakehouse, and the decision that travels with them: derive versus federate.
Swap the source, keep the shapes
Each shape is sourced once and then never cares where it came from:
| Shape | What changes when you move platform |
|---|---|
Connections |
The neocarta connector: swap BigQuery for Snowflake, Databricks, or any source with declared keys - same metadata graph out |
Trees / Themes |
The document parser’s input path (cloud storage); the graph and GDS are unchanged |
The federated finale |
The SQL dialect your agent writes; the join paths still come from the connections graph |
Nothing in your skill is bound to BigQuery. Point the connector and the parser at your own sources and the same skill - playbook, tools, policy - runs on your data.
The decision that travels: derive vs. federate
The sharper takeaway is not a shape - it is where each shape should live. You ran every migration through the four-pains test:
-
Derive a graph where you own the data or nothing else structures it - the documents (trees, themes), and the agent’s decision trail.
-
Federate where a system of record already owns the rows - the warehouse. Migrate only its metadata (the connections graph); query the rows in place.
That rule is what keeps the pattern honest at scale: you get graph reasoning where it pays, without copying a warehouse you would only have to keep in sync.
Re-skin the domain
The pattern fits any business with manuals plus assets - documents that describe things, and records of what happened to those things, sharing IDs:
-
Manufacturing - equipment manuals + maintenance logs, joined on model and error codes
-
Pharma - protocols and regulatory filings + batch records, joined on compound and lot numbers
-
Financial services - policies and procedures + transactions and cases, joined on product and account identifiers
-
IT operations - runbooks and postmortems + incidents and deploys, joined on service names and error codes
The questions port too: "what does the documentation say applies to this asset, and what actually worked on assets like it?"
Where the shapes slot into an agent stack
You built it already - the skill is the stack:
-
Connections → the neocarta MCP: grounded SQL routing where Text2SQL guesses
-
Trees → your navigation tools: grounded browsing instead of similarity guessing
-
Themes → your theme cards: the whole estate in one prompt-sized view
-
The federated finale → your judgment tools: graph grounding + live warehouse facts on the shared key
-
Policy → the playbook: when to act, when to escalate, always leave a trail
Vector search still has a seat - "find me a passage about X" - and works better here, because every hit carries its tree position and theme as context. When a platform without a shell needs your tools, wrap the same scripts in whatever interop standard it speaks; today that is MCP, and the scripts do not change.
Keep building
-
This course - revisit any module self-paced; every query is in the lessons
-
neocarta - the connector library for the connections shape over your own warehouse
-
Neo4j Agent Skills - the skills catalog your agent gained from
neo4j-cli skill install -
Next courses - Neo4j & GenAI Fundamentals for retrievers and GraphRAG, Community Detection to go deeper on Leiden and Louvain
Summary
In this lesson, you saw how the pattern ports:
-
Swap the source - the shapes are platform-agnostic; neocarta and the parser take a new source
-
Derive vs. federate - the portable decision: graph what you own, federate what a warehouse owns
-
Agent stack - connections, trees, themes, and the federated finale become tools alongside vector search
One knowledge check to go.