How to Write Agent Prompts for GTM Research Without Hallucinated Signals

Ask a research agent for a company's latest funding round and it will usually hand you one. A dollar figure. A round letter. Sometimes a lead investor's name, stated with the same flat confidence as the founding date. None of that has to be true for the agent to say it that way.

We run Clay-based Claygent agents and Claude Code as daily production research infrastructure, not as a one-off experiment someone ran once and screenshotted. If your stack does GTM research at any real volume, the failure mode below is already sitting in your data somewhere. The self-selected, n=228 survey behind "The 2026 State of GTM Engineering" (OneGTM; in the authors' own words, "meaningful but not statistically representative") found 84% of GTM engineers report using Clay, climbing to 96% at agencies. Whatever the exact number is at your shop, this isn't a rare workflow anymore. It's most of the category. Which enrichment tool actually sources the raw data, Clay, Apollo, or ZoomInfo (we've written about choosing between the three), matters less here than what you tell the agent to do with what it finds.

Skip the "how to use Claygent" walkthrough. What follows is the prompt discipline that keeps a research agent from inventing a signal it can't back up, plus a full line-by-line before/after showing what that discipline looks like in real prompt text. If you already know what GTM engineering is, treat this as the operational layer underneath it: the part where the research your system runs actually has to be true.

Why research agents hallucinate signals in the first place

An LLM asked "what's this company's latest funding round" with no grounding data doesn't reach for a "don't know" button by default. It doesn't have one. What it has is a next-token prediction problem: given everything it's seen about funding announcements, what's the most statistically plausible completion for a company that looks like this one? So it pattern-completes. A dollar amount sized to the company's stage. An investor pulled from firms that fund companies like it. None of it retrieved. All of it generated to sound retrieved.

Contrast that with a properly grounded call: the agent fetches a specific page, finds a specific sentence, and reports what that sentence says. That's retrieval, and it's a different operation entirely. Most agents don't distinguish between the two modes in their own output, and that's the gap the usual advice on this topic doesn't cover. A pattern-completed guess and a retrieved fact come back in the same confident sentence, same punctuation, same tone. Nothing in the raw text tells you which one you're looking at.

That's the actual bug, and it's a prompting bug before it's a model bug. An agent never told the difference between "I found this" and "this seems likely" will keep collapsing the two. Fix the prompt and you fix the collapse.

The confidence-labeling framework

Every claim a research agent returns should carry one of three labels, and the label should never be optional.

One agency's Claygent guide, from ColdIQ, ships a confidence-plus-source_urls field in its prompt templates, and that's a real step up from an agent left to run wide open. But treated as a nice field in a JSON schema, it doesn't do much work on its own. Nothing forces the agent to fill that field in with a true answer, and nothing downstream enforces what happens when the label comes back low. A label only earns its keep when it's mandatory in the prompt and paired with a routing rule decided before the agent ever runs, not improvised after someone notices a bad claim in a draft.

The same distinction separates an agent whose logic you can open and check when something breaks from a black-box AI SDR making the same promise with no way to inspect its work. A confidence label with a quote attached is inspectable. A confidence score alone is a number you have to take on faith, which is exactly the thing this whole exercise is trying to avoid.

Structured this way, the three labels do more than sort claims by how sure the agent feels. They define what's allowed to happen next, and that routing step is the piece most guidance on this topic never gets to.

Prompt anatomy for a hallucination-resistant research agent

Constrain the source set explicitly

Tell the agent, in the prompt, which source types count as evidence and which don't. Company site, SEC/EDGAR or Crunchbase where accessible, a named publication with a byline and date, or a wire-service press release: those are admissible. A LinkedIn post, a forum thread, a "someone mentioned" aside buried in a scraped article: not evidence for a funding or headcount claim, whatever the agent's default instinct says about them. Growth Unhinged's write-up on deep research for GTM notes, in passing, that agents "show bad judgment" treating social posts as fact. The fix isn't a warning line in the prompt. It's a named, explicit list of what counts, so the agent has no ambiguity to fill with a guess.

Force "unavailable" over invented filler

An agent with no instruction to say "I don't know" won't say it, because that reads like failure and pattern completion doesn't. Put the instruction directly in the prompt: if no admissible source states or clearly implies the claim, return UNVERIFIABLE. Not a plausible guess. Not a hedge like "likely" or "probably around." Hedged language is often worse than a flat guess, because it reads as careful while doing the exact same job: filling a gap with words instead of admitting the gap is there.

Require quote-level grounding before a claim counts

Of everything in this framework, requiring the quote does the most mechanical work. Most hallucination happens in the gap between finding a source and summarizing it: the agent reads a page about a company's early Series B conversations, then writes a sentence that quietly treats "conversations" as "closed." Requiring the exact quote closes that gap, because paraphrasing invites drift and a verbatim quote doesn't. "The company recently discussed raising a Series B" can't slide into "the company just raised a Series B" if the agent has to paste the original sentence next to its claim. It's also free auditing. You or a downstream script can check the quote in seconds instead of re-researching the whole claim from scratch.

Build in a contradiction check

Every instruction above stops at "find a source." That's not enough, because one confirming source doesn't rule out that the agent landed on the single outdated or wrong page in a sea of accurate ones. Instruct the agent to actively look for a second, independent source, and specifically one that might disagree, not just one that agrees. A press release plus a corroborating trade-press piece is stronger evidence than either alone. A press release plus a six-month-old job posting referencing "pre-Series B headcount plans" is a contradiction worth surfacing, not averaging away.

When the agent finds a disagreement, it shouldn't try to resolve it. Deciding which of two sources is right is a judgment call, and an agent guessing at that judgment is exactly the failure this whole framework exists to prevent. Flag it, surface both quotes, and let a person decide. Almost nothing published on this exact setup asks for that step, and it's also the cheapest one to add: one more line of prompt instruction, applied consistently every time.

Force structured output, not prose

Prose hides all of the above. A paragraph reading "the company recently raised a Series B led by [Investor]" looks identical whether it's VERIFIED or a total fabrication. Structured output doesn't let that happen. Ask for JSON or a table: claim, label, source_url, quote, contradiction_found. A human working a review queue, or a script filtering before anything reaches a sequence, can sort on the label field instead of reading every claim's tone and hoping it earned the confidence it's projecting.

A worked example: rewriting a real research prompt line by line

Here's a prompt that looks reasonable and invites every failure mode above.

Find [Company]'s latest funding round and their current tech stack.
Include amount raised, investors, and tools they use for sales and marketing.

Nothing in this prompt tells the agent what counts as a source, gives it explicit permission to come back empty, or asks it to show its work. It will return an answer. The answer will read fine. Whether it's true is a coin flip you didn't have to take.

Here's the rewrite:

Research [Company]'s most recent funding round and current sales/marketing tech stack.

ADMISSIBLE SOURCES ONLY:
- The company's own site (press page, about page)
- SEC/EDGAR, Crunchbase, or PitchBook where accessible
- A named business publication with a byline and date (TechCrunch, Axios, Forbes, etc.)
- A wire-service press release (PR Newswire, Business Wire)
NOT admissible as fact for this task: LinkedIn posts, X/Twitter posts, forum threads,
or any secondhand "someone said" reference inside a scraped page.

For the funding amount, round, and lead investor:
1. Search the admissible sources above.
2. If you find a claim, extract the exact sentence that states it. Quote it verbatim.
3. Search for at least one additional independent admissible source. If a second
   source disagrees with the first on amount, round, or date, flag the contradiction.
   Do not resolve it yourself.
4. Label the claim:
   - VERIFIED: quote-level match in an admissible source, no contradiction found.
   - INFERRED: no direct statement, but reasoned from adjacent quotable facts
     (e.g., a job posting referencing "post-Series B hiring").
   - UNVERIFIABLE: no admissible source states or clearly implies this. Use this
     label. Do not estimate a number.
5. Never state a specific dollar figure, round letter, or investor name unless it
   is quoted from an admissible source.

Repeat the same process for tech stack, using job postings, the company's careers
or engineering pages, and public case studies as admissible sources.

Return each claim as JSON:
{"claim": "", "label": "VERIFIED|INFERRED|UNVERIFIABLE", "source_url": "",
 "quote": "", "contradiction_found": true or false}

Line by line, what changed: the admissible-sources block replaces an implicit "use your judgment" with a named list, so the agent can't count a LinkedIn post as evidence just because it read fluently. Step 2 forces quote-level grounding before anything counts as a claim. Step 3 is the contradiction check the naive version never asked for, and it's explicitly told not to referee a disagreement itself. Step 4 turns the confidence label into a required field with real definitions attached instead of a vibe. Step 5 closes the loophole where an agent, blocked from inventing a precise number, invents a fuzzy one instead by rounding to "approximately." And the JSON structure means a script can filter on the label before a human even opens the file.

None of this is exotic. It's five ordinary instructions, stacked in the right order, that together make it structurally hard for the agent to hand back a fabrication dressed as a fact.

Where the agent's uncertainty should go, not just how it's flagged

Labeling a claim is only half the job. The other half is deciding, before the agent ever runs, what happens to a low-confidence claim, not after someone spots a wrong number in a sent email.

UNVERIFIABLE claims should never reach personalization copy or a live sequence. Not as a soft "may have recently raised funding" line, and not folded into a broader sentence where the unverifiable part is hard to spot. Drop them from the send, or route the account to a human researcher who can put real time in if the account is worth it. INFERRED claims go to a review queue, not straight into copy, because "reasoned from adjacent facts" still means a person checks whether the reasoning holds. Only VERIFIED claims move into a properly configured sending sequence unreviewed, and even those are worth spot-checking on your highest-value accounts.

The actual stakes sit here, and it's a part the existing playbooks on this topic mostly skip. A wrong "just raised a Series B" line landing in a live sequence isn't a minor accuracy slip you shrug off if a prospect replies to correct it. It's a data-hygiene signal at the domain level. A prospect who gets a fabricated claim about their own company doesn't read it as one isolated mistake. They read it as evidence the sender didn't check anything, which is precisely the impression a research-first outbound motion exists to avoid. That's a trust cost, and trust costs compound across a sending domain in ways one bounce never does.

Pre-send checklist for signal-based outbound

Run this before any sequence with agent-sourced personalization goes live.

1. Every claim in the copy has a label. No unlabeled claims made it past the agent's raw output into the draft.
2. Every VERIFIED claim has a source_url and a literal quote you can pull up in under 30 seconds.
3. Every INFERRED claim has actually been read by a person, not just generated and waved through.
4. Zero UNVERIFIABLE claims appear anywhere in the send copy, including softened or hedged versions of them.
5. Any contradiction the agent flagged has been resolved by a human, with a note on which source won and why.
6. The admissible-source list in the prompt matches what you'd actually accept if a prospect asked where the claim came from.
7. Spot-check at least one VERIFIED claim per batch against its source directly, not against the agent's summary of that source.

Skip a step because the batch is large and you're behind schedule, and the large batch is exactly where a bad signal does the most damage. It's going to more people at once.