What happens when you change your database schema? AI agents should know.

Someone renames orders.customer_id to orders.cust_id. They update the application code. The migration runs clean. A week passes.

Then an AI agent tries to answer “which customers placed the most orders last quarter?” using the old column name. It gets an error — or worse, it doesn’t, because the query runs against a cached schema from last session and returns wrong results.

This is a schema drift problem, and it’s the hardest category of failure to catch in AI-agent + database setups. The agent thinks it knows the schema. It doesn’t. No one told it.

Pretensor has two MCP tools — impact and detect_changes — that address this directly. Most MCP database servers don’t have either. This post explains what they do and why they matter.

Schema drift is the silent killer

Every production database drifts. Columns get added, dropped, renamed. New tables appear. Indexes change. The application keeps working because the migration scripts are tested. But the AI agent — which learned the schema during a session last week — has no equivalent of npm run migrate. It’s operating on stale knowledge.

Three common drift scenarios and what happens without schema awareness:

The agent doesn’t know it’s stale unless something tells it. And the standard MCP pattern — connect to database, let agent query information_schema — doesn’t help. The agent would need to know to check for changes. It won’t.

How detect_changes works

Pretensor’s detect_changes tool compares the currently indexed schema graph against the live database. It doesn’t run SQL against the database itself — it reads metadata (column names, types, constraints, table list) and diffs against the Kuzu graph on disk.

The output is a structured diff:

• Tables added — marketing_campaigns is new since last index
• Tables removed — legacy_orders_2019 no longer exists
• Columns added — products.color is new
• Columns removed — orders.shipping_notes was dropped
• Columns changed — orders.amount went from DECIMAL(10,2) to DECIMAL(12,2)

The agent can call this proactively — before writing queries, at the start of a new session — and adapt. No human has to remember to tell the agent “by the way, we renamed a column last Tuesday.” The tool is the notification.

This is fundamentally different from asking the agent to run SELECT column_name FROM information_schema.columns WHERE table_name = 'orders'. The agent would need to already know which tables to check, and it would need to know what the expected state is to detect drift. detect_changes does both: it knows the full indexed graph, and it compares against the full live schema in one call.

Impact analysis: downstream awareness

Detecting changes is step one. Step two is understanding what they break.

When someone renames orders.customer_id, the change isn’t just about orders. It breaks anything downstream that references that column. Pretensor’s impact tool walks the FK graph — plus inferred joins — to answer “what else depends on this?”

// Agent calls: impact(source="orders", column="customer_id")
{
  "source": "orders.customer_id",
  "downstream": [
    { "table": "order_items", "via": "FK order_items.order_id → orders.id" },
    { "table": "shipments", "via": "FK shipments.order_id → orders.id" },
    { "table": "customer_analytics", "via": "inferred FK customer_id → orders.customer_id" },
    { "table": "monthly_revenue_view", "via": "view depends on orders" }
  ],
  "depth": 3
}

The agent now knows that changing customer_id touches order_items, shipments, customer_analytics, and monthly_revenue_view. It can flag these in its response, suggest the correct new column name for each, and avoid stale references.

Without this, the agent’s reasoning about a column rename is probabilistic at best. With it, the agent has a deterministic dependency graph it can traverse before writing queries.

Why this is more than a SQL linter

You could argue: “just have the agent validate its SQL against the database before execution.” That catches syntax errors. It doesn’t catch:

• Logic errors. The query runs, but it joins on the wrong column because the agent didn’t know the FK direction.
• Silent staleness. The column still exists with the old name because the migration hasn’t run yet on this replica, but the canonical source was renamed.
• Missing context. The agent doesn’t know that customer_analytics depends on this column, so it reports results from orders but misses the analytics downstream.

Validation catches syntax. Impact analysis catches consequences.

The human doesn’t have to be the bridge

In most AI + database setups today, the human is the schema awareness layer. They paste DDL. They say “we renamed that column.” They check whether the migration ran.

Schema-aware tooling reduces that bridge step. The agent discovers the schema on its own (via context and schema), checks for drift on its own (via detect_changes), and traces consequences of changes on its own (via impact). The human reviews the agent’s SQL, not the agent’s understanding of the database.

This matters more as context windows grow. At 1M tokens, an agent can hold a large schema in memory. But holding it is different from understanding it — and understanding it is different from knowing when it’s stale. The graph-based approach gives the agent a way to verify its own knowledge without asking.

Getting started

pip install pretensor
pretensor index postgresql://user:pass@host:5432/dbname

# After a schema migration:
pretensor detect_changes   # see what changed
pretensor reindex          # refresh the graph
pretensor serve            # restart MCP server

The detect_changes + reindex loop is the intended workflow after schema migrations. Run both, restart the MCP server, and the agent picks up the new schema without human prompting.

See also: MCP tools reference, architecture pipeline, quickstart guide.