## TL;DR
Before applying any schema-drift fix, build the downstream impact list first: find every model, dashboard, and check that reads the changed column, then fix drift by adding compatibility, such as a renamed column kept alongside the old one, instead of renaming in place. A rename that satisfies the immediate error silently breaks every consumer the agent did not look for.

```text
when agent tried to fix schema drift it broke downstream model error failed
```

## Use this when
- The check or run fails with this symptom: an agent fix for schema drift broke a downstream model.
- You are working on an agent repairing schema drift in a pipeline with known downstream models and the failure repeats on the same data or configuration.
- You need the failing rows, rule, or stage isolated before changing thresholds or code.

## Not for this skill when
- A column with no downstream consumers, verified by lineage search, where an in-place rename is safe.
- The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

## Steps
1. Search lineage and the codebase for every reference to the drifted table and column before editing anything. Verify: an impact list of consumers exists before the fix
2. Classify each consumer as updated in this change, kept compatible, or knowingly broken with an owner notified. Verify: every consumer has a stated handling
3. Apply the drift fix in the compatible form first, such as adding the new column and backfilling it while keeping the old name working. Verify: both old and new references resolve during transition
4. Run the downstream models and checks from the impact list, not just the model that raised the drift error. Verify: impacted models pass, not only the originally failing one

## Variant phrasings
### agent fixed schema drift broke downstream model
The downstream-breakage phrasing.
### schema change by agent caused downstream dbt failures
The dbt-failure phrasing.
### rename column broke dashboards data pipeline agent
The dashboard phrasing.

Compatibility: Agents editing schemas or models in dbt and warehouse pipelines with downstream consumers

## Why it happens
Schema drift errors surface at the first consumer that breaks, which is rarely the only consumer. An agent optimizing for the visible error renames or retypes in place, and the remaining consumers fail later, one deploy at a time, with no obvious link back to the fix.

## Edge cases / pitfalls
- Schedule removal of the compatibility column only after a full cycle with no old-name references in query logs.
- Generated or compiled SQL can hide references; search the compiled output, not just source files.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ZRfghcsVyMAeGo4YQD81og