Contents
A GTM agent's accuracy is capped by the state of the data it reads, not by the model you pick. That is the claim Clay makes in "The Ceiling on Your GTM Agent Is the Data", published on its blog on 3 November 2026 by Linda Ye and Nisola Shobayo. Clay ran a general-purpose agent connected to Salesforce and Gong against its own Account Agent, and says the generic agent missed a planted deal threat in 12 of 30 runs because the threat sat on a duplicate account record. In Clay's words: "No model can reason about a record it never opens."
This is a vendor testing its own product, on accounts it built, graded by a judge model. Read it that way. But the failure modes it describes are ones every team running a CRM older than a year will recognise, and they matter more than the headline speed numbers.
What did Clay actually test?
According to Clay's appendix, the team built five synthetic accounts sized like enterprise accounts. Each had a six-person buying group, three opportunities, 31 contacts, about 10 emails and up to 16 Gong calls. Each account's calls sat among 416 calls from 80 other companies, to mimic a real Gong org. Both agents were asked two questions per account, "What's my next play on this opportunity?" and "Write me a pre-call brief", three times each, for 30 runs per setup.
Clay planted three problems:
- **A threat on a duplicate account.** A procurement deadline of 1 November, with a competitor in the frame, sat on a second Salesforce record, with the related call logged in Gong under a subsidiary's name. Clay says its agent caught it 30 out of 30 times. The generic agent caught it 18 out of 30 times.
- **Conflicting risk fields.** A sync had flipped a risk rating from Medium to Low, while the health score was poor and usage was down 21% over the month. Clay says its agent caught the conflict 16 out of 30 times. The generic agent caught it zero times, because it never queried the custom fields.
- **Champion fields cleared by a sync.** Both agents caught this 24 out of 30 times.
That last result is the one problem where better plumbing made no difference at all.
Why did the bigger model not fix it?
Clay says the generic agent "already ran on the bigger, pricier" model and still missed the threat whenever it skipped the duplicate record. Its explanation is blunt: "Every miss in our test came from retrieval." On the duplicate test, Clay writes that the generic agent's successful runs "were exactly the runs where it happened to open the duplicate record".
The conflicting fields result makes the same point more sharply. A CRM query returns the fields you ask for. If the agent does not know a custom health score field exists, it cannot ask for it, and a stronger model asking the same narrow question gets the same narrow answer.
So the variable that moved the result was whether the right record and the right fields reached the model. Model choice sat downstream of that.
How much of the speed and cost gap is real?
Clay reports per-answer averages of 250,000 input tokens for the generic agent against 39,000 for its own, 15 tool calls against 9, and 60 seconds against 23. That is the source of the "6.4x fewer tokens" and "2.6x faster" figures in the post's summary.
The cost line is where a careful reader should slow down. Clay lists $0.56 per answer at list price for the generic agent and $0.006 for its own. That is a gap of roughly 93 times, far wider than the 6.4 times token gap, and Clay's own appendix explains why: "The setups used different models, and the figures leave out the cost of building and maintaining the account context." It also says it merged the duplicate records before the test "to simulate Audiences matching", so the test "doesn't measure matching accuracy".
Put plainly, the test assumes entity resolution has already been done perfectly, then measures what happens next. That is a fair way to isolate the value of clean context. It is not evidence that any particular product resolves your records correctly. For a GTM engineer, matching accuracy is the expensive, error-prone part, and it is exactly the part this test leaves out.
Filesystem browsing or typed tools?
Clay also compared two ways for the same agent to read an account: browsing it like a folder of files, or calling fixed, typed tools for contacts, opportunities and calls. Over 650 runs, it reports overall quality scores of 0.96 and 0.95, so close to level. Browsing won on account history (0.92 against 0.82). Typed tools won on next-best actions (0.98 against 0.93).
The useful conclusion is that open-ended questions spanning a year of calls reward broad access to resolved data, while bounded questions reward a direct lookup. Most MCP connectors give agents only the second kind.
What does this change for a team building GTM agents?
If you are wiring an agent into your CRM, the work that decides its accuracy is upstream of the prompt.
**Measure your duplicate rate before you measure your model.** Pick a sample of accounts, check for second records, subsidiary names in call tools and orphaned email threads, and count how many carry facts the main record does not.
**Expose custom fields deliberately.** If your health scores, usage trends and risk ratings live in custom fields, the agent needs a summary that includes them by default, not a query it has to know to write.
**Watch your syncs.** Two of Clay's three planted problems were caused by integrations overwriting or splitting data. Every new tool that writes to the CRM is a new source of the errors your agent will inherit.
**Test with planted problems.** Clay's method is reusable. Seed known facts in awkward places, run each question several times, and count catches. Run-to-run variance is the signal, as the 18 out of 30 result shows.
A worked example, with hypothetical numbers
The figures below are illustrative, not drawn from Clay or any other source.
Say a team runs a weekly pre-call brief across 2,000 active accounts. Say 10% of those accounts, 200 in total, have a duplicate record holding a fact that matters. Apply the catch rate Clay reports for the generic agent on its duplicate test, 18 in 30, or 60%. That leaves 40% of those 200 accounts, 80 briefs a week, that miss the fact. Over a quarter of 13 weeks, that is 1,040 briefs that sent a rep into a call without it.
Swapping to a larger model does not change that 80, on Clay's evidence. Cutting the duplicate rate from 10% to 2% does. At 40 affected accounts, the same 60% catch rate leaves 16 misses a week.
A model upgrade is a line item you can buy this week. Fixing duplicates and field coverage is slower and less visible, and on this evidence it is the bigger lever on whether an agent tells a rep the truth about an account.
