agent hallucinating data contract owner for table with no contract caused routing failure error

Not specified by the original author.

TL;DR

No contract means no owner to invent: the agent assigned a data contract owner for a table that has no contract, so look the owner up in the contract registry or the catalog, and report the table as unowned when no record exists. An invented owner routes alerts and approvals to a person who never agreed to them, and the real gap, a table with no owner, stays hidden behind the plausible name.

agent hallucinating data contract owner for table with no contract caused routing failure error

Use this when

• The check or run fails with this symptom: an agent hallucinates a data contract owner for a table with no contract and causes a routing failure.
• You are working on an agent workflow routing data quality alerts or approvals by contract ownership 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 table whose contract exists in a different registry than the one searched, which needs the registry list fixed rather than an unowned report.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Search the contract registry and the catalog for the table. Verify: no contract and no owner record exist for it
2. List every place the agent sent the invented owner. Verify: each misrouted alert or approval is identified
3. Mark the table unowned in the workflow output and route it to the default triage queue. Verify: the gap is visible with the table named
4. Notify the misrouted recipient that the assignment was an error. Verify: the correction is on record
5. Add a workflow rule that owner fields come only from a registry lookup that can return empty. Verify: an empty lookup produces unowned, never a generated name

Variant phrasings

agent hallucinating data contract owner no contract routing

The shorter phrasing focused on the named failure.

invented table owner agent routing failure

The symptom phrasing a searcher tries next.

unowned table contract owner lookup fix

The variant naming the failing stage or tool directly.

Compatibility: Data contract registries and catalogs, agent routing workflows for alerts and approvals

Why it happens

Agents asked for an owner produce one, because an empty field feels like a failed task. Ownership is a fact stored in registries and contracts, not a property inferable from a table name, and guessing it misroutes accountability while concealing the missing contract.

Edge cases / pitfalls

• Table names that contain a team name are hints for a human search, not evidence of ownership; verify in the registry anyway.
• An unowned table report should include usage and criticality so the triage queue can prioritise assigning a real owner.

Provenance

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

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

Thread query: agent hallucinating data contract owner for table with no contract caused routing failure error

TL;DR: No contract means no owner to invent: the agent assigned a data contract owner for a table that has no contract, so look the owner up in the contract registry or the catalog, and report the table as unowned when no record exists. An invented owner routes alerts and approvals to a person who never agreed to them, and the real gap, a table with no owner, stays hidden behind the plausible name.

Not specified by the original author.

TL;DR

Keep the Search Data Source action for finding relevant documents, not for computing over numbers. If an agent hallucinates figures from a CSV, the fix is usually routing the question through SQL first.

Steps

1. When your agent answers questions over spreadsheets, CSVs, Notion databases, or Google Sheets, give it the Table Query tool and make sure it actually uses it for anything involving counts, sums, or comparisons. Keep the Search Data Source action for finding relevant documents, not for computing over numbers. If an agent hallucinates figures from a CSV, the fix is usually routing the question through SQL first.

When to use

You are seeing this: When your agent answers questions over spreadsheets, CSVs, Notion databases, or Google Sheets, give it the Table Query tool and make sure it actually uses it for anything involving counts, sums, or comparisons. Use this skill when you run into "Dust agents should answer spreadsheet questions with Table Query SQL, not semantic search".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official Dust docs on LLM limitations document when search-based retrieval gives wrong answers on structured data. LLMs handle natural language well but struggle with CSVs and spreadsheets, which organize meaning in rows and columns that linear text training never teaches. The Search Data Source action returns chunks ordered by relevance, which makes quantitative questions over full datasets unreliable, so agents should use the Table Query tool to generate and execute SQL on the structured data before answering.

Verified resolution: When your agent answers questions over spreadsheets, CSVs, Notion databases, or Google Sheets, give it the Table Query tool and make sure it actually uses it for anything involving counts, sums, or comparisons. Keep the Search Data Source action for finding relevant documents, not for computing over numbers. If an agent hallucinates figures from a CSV, the fix is usually routing the question through SQL first.

Source URL: https://docs.dust.tt/docs/understanding-llm-limitations-counting-and-parsing-structured-data

Not specified by the original author.

TL;DR

Fix this in the clause agent workflow by acting on the exact problem first: require the agent to quote the source clause text it used for the task to find the approved indemnification clause for a customer contract, reject any answer whose quoted text is not found in the clause bank, rerun the step with retrieval only, and confirm every statement in the output traces to a retrieved clause. Do not rerun the same workflow unchanged, because the same inputs produce the same failure. Prove the fix on one workflow run first, then rerun the full scope and reconcile the results.

agent hallucinating answers not in source data for find the approved indemnification clause for a customer contract error hallucination failure

Use this when

• The agent workflow fails with this exact problem: agent hallucinating answers not in source data for find the approved indemnification clause for a customer contract error hallucination failure.
• The same failure repeats on retry with unchanged inputs.
• A clause search, drafting, review or reporting task run by the agent is blocked until this is resolved.

Not for this skill when

• The notice is a platform outage from the vendor or the clause bank provider. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with a clause wording or negotiation position. That is a legal owner decision, not this failure.

Steps

1. Reproduce the failure on one named run of the task to find the approved indemnification clause for a customer contract and record the full problem text plus the contract or clause set involved. Verify: the failure is reproduced on demand on a named run, not only seen in a log.
2. Apply the specific fix for this problem: require the agent to quote the source clause text it used for the task to find the approved indemnification clause for a customer contract, reject any answer whose quoted text is not found in the clause bank, rerun the step with retrieval only, and confirm every statement in the output traces to a retrieved clause. Verify: the single failing workflow run now behaves as the fix predicts, or the corrected output is visible on the run.
3. Check neighbouring steps in the same workflow that share the same clause bank connection, playbook or session, because this class of failure rarely affects only one step. Verify: the neighbouring steps are listed and each is marked affected or clear.
4. Rerun the original task in the workflow on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the task completes and the original problem does not appear.
5. Compare the result against the source of truth, the clause bank record, the playbook position or the source document, so a silent partial success is caught. Verify: values match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the workflow run log so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied and the evidence of success.

Variant phrasings

agent hallucinating answers not in source data for find the approved indemnification clause for a customer contract error hallucination failure

The verbatim form searchers paste from the console, report or run log. Treat it identically: same fix, same single workflow run proof, then the full rerun.

How to fix - agent hallucinating answers not in source data for find the approved indemnification clause for a customer contract error hallucination failure

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

The clause agent workflow troubleshooting for this failure

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

Why it happens

When retrieval returns thin or empty results the model still produces a fluent answer from general patterns, so clause wording, dates and positions appear in the output that no source document contains.

Edge cases

• The clause bank, playbook or source document changed after the failing run started. Refresh the current state and reapply the fix against the current values, not the values from the failed run.
• The single workflow run proof passes but the full rerun still fails on other contracts. Treat each remaining failure as its own scope, because a shared connection, playbook or session can hide more than one cause.
• The source systems disagree on the correct value. The clause bank governs approved wording, the playbook governs negotiation position, and the source document governs extracted facts; record which source won and why.

Compatibility: Clause library and agent workflow tooling at current versions, plus the clause bank, playbook or document source the query names; no extra tooling beyond access to the source records needed to verify results.

Provenance

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

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

Thread query: agent hallucinating answers not in source data for find the approved indemnification clause for a customer contract error hallucination failure

TL;DR: Fix this in the clause agent workflow by acting on the exact problem first: require the agent to quote the source clause text it used for the task to find the approved indemnification clause for a customer contract, reject any answer whose quoted text is not found in the clause bank, rerun the step with retrieval only, and confirm every statement in the output traces to a retrieved clause. Do not rerun the same workflow unchanged, because the same inputs produce the same failure. Prove the fix on one workflow run first, then rerun the full scope and reconcile the results.