AI Account Research Without Hallucinations

Outbound teams avoid AI hallucinations in account research by treating every answer as a claim that must carry a quote, a source and a date. The pipeline passes a claim only after it clears a schema check, an evidence check and a rule check. A claim that fails becomes "unknown" and never reaches a score or a message. Blesso, a done-for-you outbound service for B2B teams, uses this kind of pipeline as its model.

Why AI account research makes things up

A language model writes fluent text whether or not it knows the answer. Ask for a company's revenue when the website does not state it, and the model may produce a plausible number. The Fieldwork GTM Engineering Handbook names the cause: the model is weakest at facts that are not on the pages you give it.

Three failures hurt outbound most. Each one reaches the prospect as a wrong sentence in a first email.

• Wrong entity. The brief describes a subsidiary, or a company with a similar name, instead of the target account. Outsell's guide to claim-level evaluation notes that one identity error can invalidate a whole brief.
• Stale signal. A filled job post or an old funding round is presented as a current trigger.
• Invented personalization. The model "congratulates" the prospect on a milestone that never happened. The Fieldwork handbook describes a prompt that asked for "something recent to congratulate them on", with no source text and no evidence requirement.

The fix is not a better prompt alone. The fix is a pipeline in which an unsupported answer has nowhere to go.

The seven gates, in order

Order matters. Cheap, deterministic gates run first, so the expensive model calls run only on accounts that can still qualify. This is the pattern we recommend. The table shows what each gate does and what it removes.

Gate 1 and 2: clean the list before any model reads it

Start with deterministic rules. They cost almost nothing and they catch errors that no prompt catches.

Blesso's own list rules show the idea. No page, path or subdomain of blesso.ai may enter an account list as a company. A row whose company name is a URL slug, such as "pricing" or "how-we-work", is disqualified at source. Two more rules we recommend: exclude competitors, because selling an outbound service to a rival is a conflict, and drop any buyer who cannot commit to a three-month minimum at from $2k a month.

Then resolve the entity. Confirm that the domain, the company name and the location agree across at least two sources. If they conflict, return "unknown" and stop. The Unify research-agent breakdown gives the same rule: return unknown when the target entity cannot be resolved.

Gate 3: ask one narrow question and supply the source

Do not ask the model what it knows about a company. Give it the text of the careers page and ask one question about that text. The Fieldwork handbook lists four habits that make a prompt survive a thousand rows:

• One question per prompt. Five questions in one prompt make each answer worse and harder to check.
• Fixed answer options, including "unclear".
• A required quote from the source that supports the answer.
• Source text passed in, not looked up from memory.

The output is a claim, not a paragraph. Each claim is one row in a ledger. This is a made-up example of one row:

{
  "account": "example-co.com",
  "field": "hiring_signal",
  "value": "open_role",
  "evidence_quote": "We are hiring a Head of Talent Acquisition.",
  "source_url": "https://example-co.com/careers",
  "source_observed": "2026-10-28",
  "answer": "yes",
  "confidence": "high"
}

The domain "example-co.com" is invented for this article. The shape is the point: a field, an allowed value, a quote, a URL and the date the page was observed.

Gate 4 and 5: the schema check is not the evidence check

A strict schema guarantees that the output parses. It does not guarantee that the content is true. The Drevon guide to benchmarking GTM research agents reports that rigid schema constraints can push a model to force a fabricated value into a valid field. We have not reproduced that result. Treat it as a reason to add a second check, not as a measured rate.

The two gates work together:

1. Schema check. Reject any answer outside the allowed values, any missing key and any "yes" without a quote. Re-run once, or mark the field "unclear".
2. Evidence check. Search the source text for the quote. If the exact text is not there, the claim fails. Invented quotes are a common failure, per the Fieldwork handbook.

The evidence check is a string search. It needs no model, so it cannot hallucinate. That is why it sits between the model and the ledger.

Gate 6: check freshness and conflicts

A true fact can still be useless. Octave's guide to AI research agents says a funding announcement from three years ago is context, not a trigger, and a filled job post is not an active signal. Set a freshness window for each type of fact. The same guide suggests flagging signals older than 90 days. Treat that as a starting default and tune it to your sales cycle.

Then compare sources. If an enrichment record says 500 employees and a company profile says 2,000, do not pick one silently. Mark the field "disputed" and keep it out of scoring until the conflict is resolved. Several articles that repeat one press release are not independent confirmation, as the Outsell guide points out.

Gate 7: qualify with rules, not with the model

Use the model to extract facts. Use fixed rules to decide fit. A rule reads the ledger and returns a score you can explain:

• Headcount inside the agreed range, from a source that is not disputed.
• At least one verified signal inside its freshness window.
• No disqualifier hit from gate 1.

A rule never sees an "unclear" or "disputed" field as a pass. Missing data lowers confidence. It does not raise the score. Unify's guidance adds that job titles are clues, not proof of decision authority, so a title match alone should not qualify a person.

The same ledger feeds messaging. An opener may cite only a claim that cleared every gate. If no claim qualifies, the account gets a plain opener or no send. As the Fieldwork handbook puts it: no evidence, no claim.

How to audit the pipeline

Automated gates fail in ways you cannot see until you sample. Audit on every run and measure four things.

The first two follow Outsell's rubric. Keep a stable test set of past failures and add unanswerable questions to it, so the pipeline is rewarded for saying "unknown".

Sample size, worked out. Cochran's formula gives the sample for a proportion: n = z² × p × (1 − p) ÷ e². With z = 1.96 for a 95% confidence level, p = 0.5 as the cautious assumption and e = 0.05, n = 3.8416 × 0.25 ÷ 0.0025 = 384.16. Round up to 385 accounts. That is an estimate from a standard formula, not a Blesso result. For a small list, read every row that will be used in a message and a random 20 of the rest, which is the Fieldwork handbook's suggestion.

Set a bar before you look. The Fieldwork handbook uses 1 error in 20 as an example. If the sample misses your bar, tighten the prompt and repeat the audit before you use the column.

What this looks like in a managed outbound program

Blesso is a done-for-you go-to-market service. Its outbound engine lists thirteen jobs between a target market and a booked call. Several of those jobs are the gates in this article: custom scrapers written per campaign, list building and scoring, waterfall enrichment after deduplication, and reply handling traced back to the signal.

Two published results show the same approach in use. For HappierHire, an AI hiring platform, Blesso ran outreach triggered by hiring signals. The case study reports 3.1x pipeline in one quarter for that customer. For Airbills, an offshore staffing company, Blesso used signals and personalized account dossiers for first contact. The case study reports $1.4M pipeline in 90 days for that customer. Both are single-customer results, not averages, and neither study publishes a baseline. They do not isolate the effect of validation. You can read them on the case studies page.

Blesso also reports in three fixed tiers each week, and counts a demo only from your calendar. See how Blesso counts a meeting. A research error that books a bad meeting shows up there, not in a dashboard Blesso controls.

When to put a person in the loop

Some claims need a human reader before they enter a message. The Unify guide lists them: claims about finance, legal trouble or personal life, anything sensitive in a regulated industry, and messages to your most valuable accounts. Let the pipeline prepare the research. Let a person approve it.

Reliable research comes from the gates, not from the model. If you want outbound that runs them for you and reports what it counted, book a call to see what Blesso would run for your team.