## TL;DR

The agent changed what one row means (grain) and every downstream sum counted rows twice. Revert the model to its prior grain, or if the new grain is intended, fix every downstream aggregation to dedupe first. Verify with row counts before and after at each grain level.

## Error

```text
dbt fix agent changed the model grain: downstream sums doubled
```

## Steps

1. Confirm the grain change: compare row counts grouped by the old grain key before and after the agent's edit (use git to see the diff).
   Expected: You see the duplication, e.g. two rows per order_id where there was one.

2. Decide: revert the model to the old grain (git checkout the model file), or keep the new grain and fix downstream. Reverting is safer unless the new grain was requested.
   Expected: A deliberate grain decision, documented.

3. If keeping the new grain, update every downstream model that sums or counts: dedupe to the new grain first or aggregate at the new grain explicitly.
   Expected: Downstream models reference the grain change; no silent double counting.

4. Add a dbt uniqueness test on the grain key so the next grain change fails loudly instead of inflating metrics.
   Expected: dbt test enforces the grain going forward.

## When to use

- downstream sums doubled after an agent edited a model
- row counts changed at a grain key with no source change
- an agent's fix touched join keys or group-bys

## When not to use

- the grain change was deliberate and approved (then update downstream, not revert)
- the source data itself duplicated (that is upstream, not the agent)
- aggregates are wrong for other reasons (check the SQL logic)

## Tool compatibility

- git diff to see exactly what the agent changed
- dbt uniqueness tests to lock the grain
- dbt build --select +model to rebuild downstream after the fix

## Variant phrasings

### agent changed the grain via a join
A new join fanned out rows. Make the agent use a pre-aggregated CTE or a many-to-one join instead.

### sums tripled, not doubled
Same diagnosis, worse fanout. Count rows per grain key to size the fanout before fixing.

## Why it happens

Agents optimize for the failing test in front of them and do not track grain as an invariant. Changing a join or a group-by to fix one test silently redefines one-row-means-what, and every downstream sum multiplies by the fanout.

## Edge cases

- Reverting loses any good part of the agent's fix; cherry-pick the good hunk instead of blanket revert when needed.
- Require agents to report row-count deltas per grain key after any model edit; make it part of the agent's done criteria.

## Provenance

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