when an agent's analysis is wrong: verification patterns

Not specified by the original author.

TL;DR

Never trust a single agent pass on numbers that matter: require the SQL behind every claim, re-derive the headline figure with an independent method, and sanity-check the result against known bounds. Wrong analyses almost always come from a bad join or a wrong filter, and both are visible in the SQL in seconds. It works because fluent prose hides broken logic, but SQL is auditable: the pattern is trust the query, not the paragraph.

when an agent's analysis is wrong: verification patterns

Use this when

• An agent's numbers will be shared outside the team
• A result looks surprising and nobody can explain why
• Building trust in a newly deployed data agent
• The analysis drove a decision you want to double-check

Not for

• Low-stakes explorations nobody will act on
• Verifying prose style or narrative quality
• Replacing the work of getting the agent to write correct SQL

Steps

1. Require the SQL with every claim, no exceptions:

AGENT OUTPUT CONTRACT:
claim: "Q3 revenue grew 12% vs Q2"
sql: SELECT ... (the exact query that produced the number)
rows_examined: 1,204,553

Expected output: every number arrives with its query attached. A claim without SQL is unverified by definition and gets sent back.

2. Spot-check row counts at each join stage:

-- rerun the agent's query with counts at each step
SELECT COUNT(*) FROM orders WHERE ordered_at BETWEEN '2026-07-01' AND '2026-09-30';
-- then with the join
SELECT COUNT(*) FROM orders o JOIN products p ON o.product_id = p.id
WHERE o.ordered_at BETWEEN '2026-07-01' AND '2026-09-30';

Expected output: the counts at each stage. If the join multiplies rows unexpectedly, you have found the classic fan-out bug behind the wrong number.

3. Recompute the headline figure by an independent path:

-- agent aggregated by day then summed; verify by aggregating directly
SELECT SUM(amount_cents)/100.0 AS revenue_direct
FROM orders WHERE ordered_at BETWEEN '2026-07-01' AND '2026-09-30' AND is_test = false;

Expected output: a second number computed differently. If the two paths disagree, at least one is wrong, and now you know to dig instead of shipping.

4. Sanity-check against known bounds:

known_total_customers = 48210
reported_active = 61000
assert reported_active <= known_total_customers, "active exceeds total: impossible"

Expected output: the assertion either passes quietly or catches an absurdity, like active users exceeding total users, before it reaches a slide deck.

5. Get human sign-off for numbers that leave the team:

VERIFICATION LOG:
claim: Q3 revenue $4.21M (+12% vs Q2)
verified_by: independent recomputation (step 3), bounds check (step 4)
signed_off: Priya, 2026-10-04

Expected output: a short log entry naming who verified what and how. External numbers without a log entry do not ship.

Variant phrasings

verify AI data analysis

Verification is the SQL, the second computation, and the bounds check. Reading the agent's explanation harder is not verification.

check LLM SQL results correct

Correct has two halves: the query runs (validity) and it answers the asked question (fidelity). Most agent errors are fidelity errors, right SQL, wrong question.

data agent hallucination verification

Hallucination in data work rarely looks like invented facts; it looks like plausible numbers from subtly wrong queries. The SQL inspection in step 1 is what catches it.

Why it happens

Agents optimize for plausible, complete-sounding answers, not for true ones: a missing filter or a duplicated join still produces a confident paragraph with specific numbers. The failure modes are concentrated and boring, which is good news: joins fan out, filters get dropped, test data gets included, and date windows shift by one. Each leaves a fingerprint in the SQL that takes seconds to spot once you look at the query instead of the prose.

Edge cases

• Correct SQL, wrong question: the query perfectly answers something nobody asked; verify the question mapping, not just the query.
• Sampling vs full data URIs an agent that sampled for speed must say so, and the verification must account for sampling error.
• Time windows: off-by-one date boundaries are the most common silent error; always restate the window in the verification.
• The verifier can be wrong too; for truly critical numbers, the independent path should be written by a human, not by the same agent.

Provenance

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

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

Thread query: when an agent's analysis is wrong: verification patterns

TL;DR: Never trust a single agent pass on numbers that matter: require the SQL behind every claim, re-derive the headline figure with an independent method, and sanity-check the result against known bounds. Wrong analyses almost always come from a bad join or a wrong filter, and both are visible in the SQL in seconds. It works because fluent prose hides broken logic, but SQL is auditable: the pattern is trust the query, not the paragraph.

Not specified by the original author.

TL;DR

Claimed success without verification is the most dangerous agent failure: everyone believes the key is rotated. Require read-back verification: after rotation, the agent must confirm the new credential works and the old one is dead.

Error

agent hallucinated rotation success it never confirmed: trust error

Steps

1. Audit the run: find where success was claimed without a verification step. Expected: the gap found.
2. Add mandatory verification: use the new credential in a real operation. Expected: proof it works.
3. Add negative verification: confirm the old credential is rejected. Expected: proof the old is dead.
4. Make the agent's success report include the verification evidence. Expected: claims carry proof.
5. Re-run past unverified rotations through verification now. Expected: any false successes caught.

When to use

• Agents reporting unverified rotation success.
• Building trustworthy automation.

When not to use

• Rotations that actually failed (fix the rotation).
• Manual rotations (verify them too, but differently).

Tool compatibility

• Rotation verification; credential testing.

Variant phrasings

agent claimed rotation succeeded

Verify by read-back.

unverified rotation success

Same proof requirement.

Why it happens

Agents optimize for completing steps; without an explicit verification step, the last write looks like success.

Edge cases

• Verification needs the same permissions as the rotation; plan for both.
• Negative verification can lock you out if done wrong; test carefully.
• Past unverified claims need retroactive checking, not just future fixes.

Provenance

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

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

Thread query: agent hallucinated rotation success it never confirmed: trust error

TL;DR: Claimed success without verification is the most dangerous agent failure: everyone believes the key is rotated. Require read-back verification: after rotation, the agent must confirm the new credential works and the old one is dead.

Not specified by the original author.

TL;DR

The agent invented a dispute id and then acted on it: querying, updating, or citing a record that was never real. Fix: treat every model-generated id as untrusted. Look it up in the source system before acting and refuse to proceed when the lookup fails. Lookup-then-act is the whole fix.

fraud agent hallucinated a dispute id that does not exist

Use this when

• Actions reference dispute ids the provider has no record of.
• Citations in agent output point at disputes that do not exist.
• Updates fail with not-found errors on ids the agent produced.

Not for this skill when

• A real id fails lookup during a provider outage. That is availability, not hallucination.
• The id exists but under a different merchant. That is a scoping bug.

Steps

1. Confirm the hallucination: take the disputed id and query the source system directly. Verify: the system returns not found for the id.
2. Add a verification gate: no action runs until the id is confirmed to exist. Verify: a fake id is rejected at the gate with a logged reason.
3. Constrain id sources: the agent may only use ids from tool outputs and database reads, never from its own prose. Verify: ids travel as structured fields, not parsed from sentences.
4. Log every id the agent acts on together with its source. Verify: an auditor can trace each id back to the system that issued it.
5. Alert when hallucinations spike: repeated fake ids mean the prompt or the retrieval step is broken. Verify: the alert fires before bad actions accumulate.

Variant phrasings

agent invented dispute id

Common phrasing.

fake dispute id hallucination

Hallucination-focused search.

dispute id does not exist

Lookup-focused phrasing.

hallucinated dispute identifier

Identifier-focused phrasing.

Compatibility: any agent that handles provider ids; the gate is one lookup call before the action call, and the same pattern covers order ids, payment ids, and case ids.

Why it happens

Language models complete patterns, and an id-shaped string is an easy pattern to complete. Without a verification step, a plausible-looking id flows straight into real API calls.

Edge cases / pitfalls

• Ids that exist but belong to another merchant or environment: verify ownership, not just existence.
• Lookup failures from API outages should pause the action and retry the lookup later, never skip verification.
• Never let the agent fix a bad id by guessing a similar one. Reject it and re-derive from the source.

Provenance

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

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

Thread query: fraud agent hallucinated a dispute id that does not exist

TL;DR: The agent invented a dispute id and then acted on it: querying, updating, or citing a record that was never real. Fix: treat every model-generated id as untrusted. Look it up in the source system before acting and refuse to proceed when the lookup fails. Lookup-then-act is the whole fix.