synthetic agent hallucinated a column that does not exist in the sou

Not specified by the original author.

TL;DR

Fix this in synthetic data agent workflow by acting on the exact message first: require the agent to validate every column name in its plan and generated code against the source schema list before running anything, reject and regenerate any step naming an unknown column, and show it the schema as a checked list rather than a description it paraphrases. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.

agent hallucinated a column that does not exist in the source schema

Use this when

• The operation in synthetic data agent workflow fails with this exact message or symptom: agent hallucinated a column that does not exist in the source schema.
• The same failure repeats on retry with unchanged inputs.
• Generation, validation or export is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in synthetic data agent workflow, and copy the full message plus the table, column or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: require the agent to validate every column name in its plan and generated code against the source schema list before running anything, reject and regenerate any step naming an unknown column, and show it the schema as a checked list rather than a description it paraphrases. Verify: the smallest failing scope now completes, or the named column, table or job behaves as the fix predicts.
3. Check the neighbouring tables, columns or jobs that share the same config, schema or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in synthetic data agent workflow on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, distributions or status against the source in synthetic data agent workflow so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Agents invent plausible column names when they work from a task description instead of the schema itself, and a name check against the real schema catches the invention before it becomes a failed run.

Variant phrasings

agent hallucinated a column that does not exist in the source schema

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - synthetic agent hallucinated a column that does not exist in the source schema

The how-to phrasing for the same failure in synthetic data agent workflow. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

synthetic data agent workflow troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: synthetic data agent workflow at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstflNLpXIx-0xUWdk9yZr-w

Resolved from the public thread: https://vectle.com/posts/pstflNLpXIx-0xUWdk9yZr-w

Thread query: synthetic agent hallucinated a column that does not exist in the source schema

TL;DR: Fix this in synthetic data agent workflow by acting on the exact message first: require the agent to validate every column name in its plan and generated code against the source schema list before running anything, reject and regenerate any step naming an unknown column, and show it the schema as a checked list rather than a description it paraphrases. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Ground every generated query in the live catalog: before running generated SQL, resolve each column name against the information schema for the target table and reject or correct any name that does not exist. Hallucinated columns usually are plausible names from similar tables or from an older schema version.

agent hallucinating column names that don't exist error failed query generation

Use this when

• The check or run fails with this symptom: generated queries fail because the agent invented column names that do not exist.
• You are working on an agent that writes SQL or data quality checks from natural-language requests 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 that exists but under a different table or schema, where the fix is qualifying the name rather than treating it as invented.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Extract every column reference from the generated query and look each one up in the information schema for its table. Verify: each reference is marked found or missing against the live catalog
2. For missing names, search the catalog for near matches by suffix, prefix, or similar tables the agent may have copied from. Verify: each missing name has a candidate real column or is confirmed absent
3. Rewrite the query with only verified columns, and where a requested field genuinely does not exist, report that instead of substituting silently. Verify: the corrected query uses catalog-verified names only
4. Run the corrected query with a small limit first and confirm it executes before the full run. Verify: the limited run returns rows with no unknown-column error

Variant phrasings

agent invented column names sql failed

The invented-column phrasing.

hallucinated columns in generated data quality checks

The generated-check phrasing.

agent query references columns that do not exist

The missing-column phrasing.

Compatibility: Agents generating SQL against warehouse schemas with Great Expectations or dbt context

Why it happens

Language models generate column names from patterns in training data and prior context, so names sound right while belonging to other tables, older versions, or no schema at all. Nothing in generation checks the catalog; verification has to be an explicit step after generation and before execution.

Edge cases / pitfalls

• A column dropped minutes ago can pass a stale cache; refresh the catalog for the target table when a lookup disagrees with a fresh error.
• Case sensitivity differs across warehouses; compare names using the warehouse's folding rules.

Provenance

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

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

Thread query: agent hallucinating column names that don't exist error failed query generation

TL;DR: Ground every generated query in the live catalog: before running generated SQL, resolve each column name against the information schema for the target table and reject or correct any name that does not exist. Hallucinated columns usually are plausible names from similar tables or from an older schema version.

Not specified by the original author.

TL;DR

Fix this in synthetic data agent workflow by acting on the exact message first: constrain the agent to the source schema field list, validate every field name in its output or plan against that list, and reject any step that references a field the schema does not contain. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.

agent hallucinating synthetic data fields - invented data not in source

Use this when

• The operation in synthetic data agent workflow fails with this exact message or symptom: agent hallucinating synthetic data fields - invented data not in source.
• The same failure repeats on retry with unchanged inputs.
• Generation, validation or export is blocked until this item completes.

Not for this skill when

• The message is an outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output quality. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in synthetic data agent workflow, and copy the full message plus the table, column or job involved into the run notes. Verify: the error is reproduced on demand with a named scope, not only seen in a log.
2. Apply the specific fix for this error: constrain the agent to the source schema field list, validate every field name in its output or plan against that list, and reject any step that references a field the schema does not contain. Verify: the smallest failing scope now completes, or the named column, table or job behaves as the fix predicts.
3. Check the neighbouring tables, columns or jobs that share the same config, schema or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in synthetic data agent workflow on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, distributions or status against the source in synthetic data agent workflow so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

Agents invent plausible sounding fields when working from a task description instead of the actual schema, and schema validation is the cheap check that stops it.

Variant phrasings

agent hallucinating synthetic data fields - invented data not in source

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single scope proof, then the full rerun.

How to fix - agent hallucinating synthetic data fields error invented data not in source failure

The how-to phrasing for the same failure in synthetic data agent workflow. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

synthetic data agent workflow troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: synthetic data agent workflow at current versions, plus the platform API or console the query names; no extra tooling beyond the source system access needed to verify counts.

Provenance

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

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

Thread query: agent hallucinating synthetic data fields error invented data not in source failure

TL;DR: Fix this in synthetic data agent workflow by acting on the exact message first: constrain the agent to the source schema field list, validate every field name in its output or plan against that list, and reject any step that references a field the schema does not contain. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one table, batch or record set first, then rerun the full scope and reconcile the counts.