data agent hallucinated a table that does not exist: schema-ground e

Not specified by the original author.

TL;DR

Agents invent column names that sound right but dont exist. Fix it by giving the agent the real schema (from information_schema or the table DDL) in its context and validating every generated query's columns against that schema before execution, rejecting or repairing hallucinations automatically.

agent's SQL referenced a column that doesn't exist: schema grounding

Use this when

• Agent-generated SQL fails on a nonexistent column
• The agent invents plausible but wrong field names
• The schema changed and the agent works from memory

Not for this skill when

• The SQL syntax is invalid (thats parsing)
• The role lacks permission (thats grants)
• The logic is wrong but columns exist (thats the query logic)

Steps

1. Pull the real schema and put it in the agent's context:

SELECT column_name, data_type
FROM information_schema.columns
WHERE table_schema = 'public' AND table_name = 'orders';

Expected output: the authoritative column list. This is ground truth; the agent's memory of the schema is not.

2. Instruct the agent to use only listed columns:

You may only reference these columns: [id, customer_id, total, created_at].
If you need another column, STOP and ask instead of guessing.

Expected output: the agent stops inventing names. Explicit permission to stop beats a confident hallucination.

3. Validate generated SQL against the schema before running it:

import sqlparse  # or your parser of choice
# extract referenced columns, compare against the schema list, reject unknowns

Expected output: bad queries are caught pre-execution with a clear message naming the unknown column. The validator is cheap; the failed query against prod is not.

4. Refresh the schema snapshot on a schedule or on failure:

# on "column does not exist", refresh the schema cache and retry once

Expected output: schema drift (a renamed column) is handled by refresh-then-retry instead of looping on a stale snapshot.

Variant phrasings

agent uses the right column name but wrong table

Same grounding problem at the table level. Provide the table list too, not just columns.

works for one database, fails on another

Schemas differ between environments. Ground per environment; never share one schema snapshot across dev and prod.

Why it happens

LLMs predict plausible text, and column names are highly predictable from table names (orders probably has customerid... or is it userid?). Without the actual schema in context, the model guesses, and its guesses are confident and often wrong. Schema grounding turns generation into selection from a known list, which is what makes it reliable.

Edge cases

• Case sensitivity: quote rules differ by database; ground with the exact cased names.
• Wide tables make full schemas expensive in context; provide per-task relevant tables, not the whole warehouse.
• Views and computed columns may not appear in information_schema the way the agent expects; include view definitions where needed.

Provenance

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

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

Thread query: agent's SQL referenced a column that doesn't exist: schema grounding

TL;DR: Agents invent column names that sound right but dont exist. Fix it by giving the agent the real schema (from information_schema or the table DDL) in its context and validating every generated query's columns against that schema before execution, rejecting or repairing hallucinations automatically.

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

The agent is guessing table and column names instead of reading them from the catalog. Pull the live schema from information_schema, put it in the agent's context, and validate every generated query against that schema before it runs. Hallucinated names get caught pre-execution instead of failing (or worse, silently returning empty) at runtime.

Symptom

The agent generates confident SQL referencing tables or columns that are not in the warehouse. Queries fail with "relation does not exist", or return empty results when the agent invents plausible-sounding names. The pattern repeats across runs because nothing corrects the agent's mental model of the schema.

Steps

1. Pull the live schema from the catalog. This is ground truth; the agent must never guess names:

SELECT table_schema, table_name, column_name, data_type
FROM information_schema.columns
WHERE table_schema NOT IN ('pg_catalog', 'information_schema');

Expected output: the real tables and columns. Save this as the allowlist every query is checked against.

2. Inject the schema into the agent's prompt context, scoped to the schemas it may query. Keep it compact: table names with their columns, refreshed each run or cached with a short TTL.

Expected output: the agent's generated SQL references only listed tables and columns, because it can see what exists.

3. Validate every generated query against the catalog before executing: parse the identifiers and check each against the schema from step 1. Reject or repair on the first unknown identifier instead of running it.

Expected output: hallucinated names are caught pre-execution; the agent gets the validation error plus the real schema and retries with correct names.

4. Log every rejected query with the hallucinated identifier. If one table name keeps appearing, it is either a stale schema cache or a naming convention the agent expects; fix the cache or add the alias mapping.

Expected output: repeat hallucinations drop to zero after the cache or mapping fix.

When to use

• Agent-generated SQL fails on tables or columns that do not exist
• The agent works on one schema fine but invents names in another
• You are giving an agent write access to run queries at all

When not to use

• The tables exist but the query logic is wrong (that is a SQL-logic problem, not hallucination)
• A human writes the SQL (they can read the schema themselves)
• The failure is permissions, not missing objects (check grants)

Variant phrasings

agent keeps using an old table name after a rename

The schema cache is stale, or the old name is baked into the prompt. Refresh the cache and grep the prompt for the old name.

agent invents columns that sound right but do not exist

Same fix. Column-level validation in step 3 catches these; table-only checks do not.

Why it happens

LLMs complete patterns; without the schema in context, the model fills in the most plausible table and column names from its training data. It has no way to know your warehouse calls it fact_orders_v2 instead of orders. Schema grounding replaces guessing with lookup.

Edge cases

• Very wide schemas do not fit in context; scope to the relevant schemas or summarize to table names plus a column list on demand.
• Temp tables and CTEs the agent creates itself are not in the catalog; exempt the agent's own session objects from validation.
• Case sensitivity: quoted identifiers in some warehouses are case-sensitive; normalize case the same way the warehouse does before comparing.

Provenance

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

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

Thread query: data agent hallucinated a table that does not exist: schema-ground every query

TL;DR: The agent is guessing table and column names instead of reading them from the catalog. Pull the live schema from information_schema, put it in the agent's context, and validate every generated query against that schema before it runs. Hallucinated names get caught pre-execution instead of failing (or worse, silently returning empty) at runtime.