agent hallucinated a source freshness policy that does not exist

TL;DR

The agent wrote config keys dbt does not recognize, and dbt either ignored or errored on them. Delete the invented keys, replace with the real freshness syntax from the docs if freshness was actually wanted, and verify with dbt parse.

Error

agent hallucinated a source freshness policy that does not exist

Steps

1. Find the hallucinated config: run dbt parse and read warnings about unrecognized keys, or grep sources.yml for the invented policy name. Expected: You see the keys dbt does not know.

2. Delete the invented keys. If the intent was real (e.g. actual freshness monitoring), write it with the documented syntax: freshness: warn_after: {count: 24, period: hour}. Expected: Only documented keys remain.

3. Run dbt parse and dbt source freshness --select the source to confirm the config is valid and active. Expected: Parse clean; freshness checks run if configured.

4. Tell the agent to check config keys against the docs before writing new ones; hallucinations love config files. Expected: Fewer invented keys in future agent edits.

When to use

• an agent wrote freshness or other config that dbt does not recognize
• dbt parse warns about unknown keys the agent added
• a config block looks plausible but does nothing

When not to use

• the config is valid but misconfigured (fix the values, not the keys)
• dbt version differences renamed a key (check the changelog for your version)
• a human wrote the config from memory (same fix, kinder tone)

Tool compatibility

• dbt parse to surface unknown-key warnings
• the dbt docs for the real freshness syntax
• sources.yml as the file to audit

Variant phrasings

agent hallucinated a model config key

Same fix: dbt parse warnings point at it, delete or replace with the real key.

agent hallucinated a whole source

Bigger problem: verify the source table exists at all before keeping any of the block.

Why it happens

Agents generate plausible-sounding YAML from patterns in training data, mixing versions and inventing keys that feel right. dbt is lenient about unknown keys in some spots, so the hallucination can sit silently doing nothing until someone depends on it.

Edge cases

• dbt parse warnings are easy to miss in long logs; grep the parse output for warning explicitly.
• Pin the dbt version the agent targets in its instructions so it stops mixing syntax across versions.

Provenance

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