Concept 1: The "Data Gravity" Problem
What It Is
Data gravity is the idea that data is expensive and risky to move, while compute (processing power) is relatively cheap to relocate.
The Core Problem
Most enterprise AI systems are built like this:
Your Governed Data (Lakehouse)
↓ [data gets pulled OUT]
External Vector Database
↓
External LLM / AI Stack
↓
Response back to user
Every time data crosses that boundary, you pay penalties:
- Latency — network round-trips slow everything down
- Cost — data egress fees add up at scale
- Security risk — data leaves your secure perimeter
- Governance loss — your policies don't travel with the data
The Simple Analogy
Think of your data like a hospital's patient records. Moving them to a separate building every time a doctor needs them creates delays, security risks, and compliance nightmares. The smarter solution? Bring the doctor to the records.
Concept 2: Two Architectural Paradigms
Paradigm A: External Agents (The Common Approach)
┌─────────────────────────┐ ┌──────────────────────────┐
│ Your Data Platform │────▶│ Separate AI Stack │
│ (Governed Lakehouse) │ │ - External LLM │
│ │ │ - Vector DB │
│ Policies live HERE │ │ - Bespoke serving │
└─────────────────────────┘ │ Policies re-built HERE │
└──────────────────────────┘
Problems:
- Governance must be rebuilt in every AI component
- Logs scattered across multiple vendors
- Data leaves your secure perimeter
- Fragmented, brittle system
Paradigm B: Data-Native Agents (The Proposed Approach)
┌──────────────────────────────────────────────────┐
│ Your Data Platform │
│ │
│ Data + Models + Agents + Tools + Memory │
│ │
│ ONE governance layer covers EVERYTHING │
└──────────────────────────────────────────────────┘
Benefits:
- Single control plane
- Policies enforced automatically
- Low latency (no network hops)
- One bill, one security perimeter
Concept 3: Why Post-Hoc Governance Fails (The Critical Insight)
What Post-Hoc Governance Means
"Post-hoc" = after the fact. Most AI systems apply governance after the agent has already touched the data:
Agent accesses ALL data
↓
Computation runs on ALL data
↓
Result is filtered/redacted ← governance happens HERE (too late)
↓
User gets response
Why This Is Fundamentally Broken
Consider this example:
An agent calculates the average salary across employee records. Some employees' records are restricted from certain users.
Restricted records: $200,000 ← user shouldn't see this
Allowed records: $50,000
$60,000
$55,000
Average computed: $91,250 ← this number is SHAPED by restricted data
Even if you hide the $200,000 record afterward, the average already encodes that information. No redaction can undo a completed calculation.
The Rule
Governance must happen at query planning time, not at response rendering time.
Concept 4: The Token-Burning Loop
What It Is
A costly spiral that happens when governance is applied after the fact, causing agents to waste enormous amounts of compute.
How It Unfolds
Step 1: Agent requests data
↓
Step 2: Gets blocked/redacted output (governance fires too late)
↓
Step 3: Agent interprets this as a FAILURE
↓
Step 4: Agent tries again, differently
↓
Step 5: Loads more context into the model
↓
Step 6: More tokens consumed, more cost
↓
Step 7: Repeat... (1 request → thousands of billed tokens)
The Root Cause
The agent is forced to compensate for missing governed answers by:
- Traversing audit logs
- Joining fragments across external systems
- Re-reasoning over partial results
None of this is the actual task — it's wasted work caused by poor architecture.
The Fix
Give the agent a clean, governed answer in a single pass by enforcing policy before computation begins.
Concept 5: Agent State vs. Agent Memory
These are two distinct but related concepts that both need governance.
Agent State (Short-Term)
| Property | Description |
|---|---|
| What it is | The live scratchpad during a session |
| Examples | Current conversation, task in progress, cached results |
| Lifespan | Exists during the session |
| Storage needs | Fast per-row reads/writes, keyed lookups, atomic updates |
Agent Memory (Long-Term)
| Property | Description |
|---|---|
| What it is | What persists after the session ends |
| Examples | User preferences, past outputs, customer history |
| Lifespan | Outlives the session |
| Sensitivity | "User X is a high-value EU customer" = sensitive data bound by privacy laws |
The Governance Problem
Both state and memory are sensitive data — but most systems store them in external databases (Redis, Postgres) that sit outside the governance boundary:
Governed Platform External Memory Store
│ │
│ agent writes ─────────▶│ ← governance can't see this
│ "user X is EU" │
│ │ ← no lineage
│ │ ← no access controls
│ │ ← separate security model
Concept 6: The Multi-Agent (Swarm) Problem
What a Swarm Is
Multiple agents working together toward a larger goal:
Planner Agent
/ \
Specialist A Specialist B
\ /
Supervisor Agent
Why Shared State Is Hard
When agents keep private state and pass context peer-to-peer:
Agent A's memory: "Task is 60% done"
Agent B's memory: "Task is 45% done" ← diverged!
Problems that emerge:
- Write collisions — two agents update the same record simultaneously
- No single source of truth — agents diverge on facts
- Ungoverned handoffs — every peer-to-peer message is a governance gap that multiplies as the swarm grows
The Solution: Shared Transactional Storage
All agents read/write the same governed layer:
Agent A ──▶ ┌─────────────────────┐ ◀── Agent B
Agent C ──▶ │ Shared State Store │ ◀── Agent D
│ (Governed, Atomic) │
└─────────────────────┘
│
Single source of truth
Atomic updates
Full lineage traceable
Concept 7: The Full Data-Native Architecture
Putting It All Together
A data-native agent has all components inside the same governed platform:
┌─────────────────────────────────────────────────────────┐
│ Data Platform (e.g., Databricks) │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Your Data │ │ AI Models │ │
│ │ (Lakehouse) │ │ (Serving) │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Agent State │ │ Agent Tools │ │
│ │ & Memory │ │ │ │
│ │ (Lakebase) │ │ │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ════════════════════════════════════════════════════ │
│ Unity Catalog (Governance Layer) │
│ - Access controls │
│ - Policy enforcement at query planning │
│ - Lineage tracking │
│ - Business definitions │
│ ════════════════════════════════════════════════════ │
└─────────────────────────────────────────────────────────┘
The Comparison Summary
| Dimension | Data-Native | External |
|---|---|---|
| Governance | Single control plane, enforced at query time | Rebuilt in every component, applied after the fact |
| Security | Data stays in your VPC | Data leaves your perimeter |
| Latency | Low (no network hops) | High (multiple round-trips) |
| Cost | Consolidated, no egress fees | Fragmented pricing + egress costs |
| Agent Memory | Governed, traceable, joinable to source data | Separate system, no lineage, no governance visibility |
| Observability | All logs in one place | Scattered across vendors |
The Core Mental Model
Think of it this way:
Old approach: Build a city, then build a separate police department in another city and try to enforce laws remotely.
Data-native approach: The police department is built inside the city, operating under the same laws, with full visibility into everything happening.
The key insight is that governance cannot be bolted on after computation occurs — it must be woven into the fabric of where and how computation happens in the first place.