GTM Platform vs. Clay: What Happens After the Signal Fires

Writing on GTM platform vs. Clay is unreliable in both directions, and it is easy to show rather than assert. One 2026 review of Clay's weaknesses states that Clay does not identify anonymous website visitors and has no account-level deanonymization. Clay's own documentation walks you through installing its tracking snippet and says plainly that visitor tracking identifies accounts. Another 2026 review, arguing the other way, says Clay lets you score leads on title match, company size, and industry fit, which reads like a scoring feature and is actually a formula you write yourself in a column. Comparing a full sales motion against Clay means first getting Clay right.

So this post starts from Clay's current documentation and changelog instead of recollection, and it lands somewhere more specific than a gap list. The line between what Clay owns and what it does not is not a category boundary. It is a duration boundary. Every job Clay covers natively completes inside a single run. Every job it leaves to something else needs state that outlives the run.

That reframing matters because it is predictive rather than descriptive. A feature list goes stale in a quarter. A structural line tells you what Clay will and will not have absorbed by next year, and it tells you which of your own workflows are quietly being held together by a formula column and an export.

The short version

• Clay is the best enrichment product in go-to-market, and this post does not argue otherwise.
• It is also no longer enrichment-only. Sequencer sends email natively. Web intent, ad sync, and Audiences all shipped as real surfaces.
• The most repeated claim in Clay comparison content is wrong: Clay has no native lead scoring. Its own docs implement scoring as a Formula column you build.
• Clay's sequencer caps at four emails per campaign, email only, and each lead enters a campaign once. No re-entry, no branching, no wait steps measured in weeks.
• Clay owns no deal objects, no stages, no forecasting, no scheduling, no call recording, no customer health, and no multi-touch attribution.
• Workflows, the closest thing to a journey builder, is labeled beta on Clay's own site and documents no wait, branching, or re-entry logic.
• The pattern behind all of it: jobs that finish when the run finishes are Clay's. Jobs that need state for weeks are not.
• Call it the run test. The 16-row table below runs it across the whole motion.
• Clay appeared in 71 percent of the 62 stacks ColdIQ collected and 84 percent of Maja Voje's 228 GTM engineers. This is not a fringe tool, which is exactly why the boundary is worth drawing precisely.

What Clay is genuinely the best at

Clay's core job is finding and verifying data about companies and people, and it does that better than anything else on the market. The mechanism is waterfall enrichment: for a single field, Clay tries provider after provider until one returns a match, so you pay per successful lookup instead of buying a full seat from every data vendor. That is a genuinely better economic model than the one it replaced, and it is why Clay became infrastructure rather than a preference. Its placement against the rest of the category is covered in the prospecting tool field.

Claygent, its research agent, is the second thing Clay does that nothing else matches. It browses, reads, and writes structured output into a column, which turns open-ended research questions into a repeatable field. Clay's own framing is that every agent decision comes with a full reasoning trace, which matters more than it sounds: a research answer you cannot audit is a research answer you cannot ship into a first touch. In 2026 Clay added a builder around it with prompt versioning and a sandbox, plus connectors that pull first-party data from Salesforce and Gong.

Adoption backs this up rather than marketing doing it. ColdIQ's 2026 survey of 62 revenue leaders found Clay in 71 percent of stacks, ahead of n8n at 48 percent and HubSpot at 39 percent. Maja Voje's separate 2026 State of GTM Engineering report, based on 228 respondents across more than 30 countries, put Clay at 84 percent, rising to 96 percent among agencies. The full stage-by-stage breakdown is in the GTM tech stack in 2026. Clay is close to a default, and the job title it is credited with popularizing now has its own GTM Engineer skill set.

One more thing in Clay's favor, and it is the part most comparison posts miss entirely. Clay's 2026 direction is agent-native infrastructure: a command line interface, a context protocol server that Claude and Codex can call, and reusable functions that let a team build logic once and use it across tables and audiences. If the question is which tool an agent should call to get data, Clay has a real claim to that answer.

The correction: Clay does not have native lead scoring

This is worth its own section because nearly every comparison post gets it backwards, including posts that argue in Clay's favor. Clay's own documentation implements lead scoring as a Formula column. You create a column, set its type to Formula, and use the formula generator to write the logic. It supports point scoring, letter grades, and binary fit, and it works fine for a snapshot.

What does not exist is a score that is maintained. There is no persistent score object, no decay as a signal ages, and no model trained on your closed-won outcomes. Lead scoring sits in Clay's navigation as a use case rather than a product surface, and the difference between a use case and a surface is exactly the difference between a cell you recalculate and an attribute the system keeps current.

The reason to flag it loudly is that scoring is usually the first thing a team assumes it can move into Clay, and a formula column will pass a demo. It fails three months later, when the score that ranked an account highly in April is still ranking it highly in July on the strength of a signal that has gone cold. That failure is not a bug in the formula. It is what happens when a stateless calculation is asked to do a stateful job.

The run test

The run test is one question, asked per job rather than per vendor: does the job finish when the run finishes? If a job completes the moment the enrichment returns, the signal fires, or the campaign sends its last email, it is inside Clay's design. If the job requires state that survives after the run ends, it is outside it.

Run it against Clay's strengths and it explains all of them. Enriching a record finishes. A research question finishes. Detecting that somebody changed jobs finishes. Picking the next rep off a round-robin counter finishes. Recomputing which accounts belong in an ad audience finishes, every time the attributes change. All of these are native in Clay, and all of them terminate.

Now run it against the jobs Clay does not own. A fit score that decays does not finish. A nurture track that adapts over a quarter does not finish. A deal moving through stages does not finish. Customer health trending down over six weeks does not finish. Attribution across a full buying cycle does not finish, because the answer depends on touches that have not happened yet. Every single one of Clay's gaps is a job with a duration longer than a run.

That is why the test is worth more than a feature list. It is not a summary of Clay's roadmap gaps, it is a description of what Clay is built out of. Rows get enriched and the run completes. That architecture is why enrichment is so good and why nurture is not available, and it is stable in a way that any individual missing feature is not.

Sixteen go-to-market jobs, and what Clay actually does with each

Verified against Clay's own product pages, its university documentation, and its changelog in July 2026, plus independent 2026 teardowns where the sources disagreed. Native means Clay ships it as a product surface. Build-it-yourself means the capability is reachable but you assemble it. Integration-only means Clay reads or writes to a tool that does the job. None means it is absent.

The column on the right is the whole argument. Read it top to bottom and the yes rows are Clay's product, with routing the one partial case and the sequencer's four-email cap sitting right at the edge. The no rows are what a team assembles around it. Nobody at Clay drew this line as a compromise. It follows from building on tables and runs, which is also what makes the enrichment so good.

Blu Agent

Seven of the sixteen jobs finish when the run finishes, and six of those seven are native Clay surfaces. Nine need state that outlives a run, and not one of those nine is native. That split is not a roadmap accident, it is the architecture showing through.

The boundary in detail: four emails, one entry, no branches

The sequencer deserves precision because it is where a vague claim becomes a false one. Clay does send email itself. You connect a mailbox through Google Workspace or Microsoft Outlook, and Clay runs inbox warming from the linked account, rotates domains, manages aliases, enforces daily caps, and spaces sends five to thirty minutes apart inside business hours in the recipient's timezone. There is a global inbox for replies, suggested responses, and reply categorization into interested, meeting request, and not interested. Saying Clay cannot send email is simply wrong.

The documented limits are where it stops. Campaigns cap at four emails per campaign. Email is the only channel, so no calls, no messaging, no in-product prompt. Sequences end when the sends run out or the lead replies. And each lead can be sequenced only once per campaign, which means re-touching the same person requires building a separate campaign by hand.

Put those four constraints together and the shape is clear. Clay can fire a sequence off a signal, and that is a real capability worth naming plainly. What it cannot do is hold somebody for eleven weeks, branch on what they did in week three, pause when they open a support ticket, resume when a pricing page visit lands, and exit when a deal opens. That is a different kind of object: not a campaign that terminates but a journey that persists. The strategy side of that job is covered in lead nurturing automation.

There is a commercial reason duration matters here. 6sense's B2B Buyer Experience Report found that in 95 percent of cases the winning vendor was already on the buyer's day-one shortlist, and that four out of five deals go to the pre-contact favorite. Read that against a four-email campaign and the mismatch is structural rather than tactical. If the deal is mostly settled before anybody replies to anything, the job is being present and useful across the months while the shortlist is forming, and a campaign that terminates on its fourth send is the wrong shape of instrument for that job.

Workflows is the feature people point to here, and it needs care because more than one thing in Clay's history has shared that word. The one documented on Clay's own site today is labeled beta and described as guiding cold outreach and CRM-enrichment prospecting inside Clay, with no published wait steps, branching, loops, or re-entry logic. The only delay primitive documented anywhere in the product is a pre-enrichment delay capped at ten minutes, which is a rate limiter rather than a nurture wait.

The five-tool line, and the 2026 edit it needs

Intempt's own framing of this space has been a single sentence for a while: Clay enriches. Outreach sequences. Gong records. Apollo dials. Five tools, zero connection from intent to close. It is a fair description of how a founding sales team's browser actually looks, and the reason it lands is that each tool is good at its piece and none of them owns the handoff.

That line now needs an edit, and the honest thing is to make it rather than keep quoting it. Clay sequences. It absorbed one of the five tools in the list, which is a real product achievement and should be counted as one. The number is closer to four.

The second half of the sentence did not move at all, and that is the part worth sitting with. Zero connection from intent to close is not a statement about how many tools you own. It is a statement about whether the thing that detects the intent still knows about it at the close. Clay can detect an account visiting a pricing page and start a campaign the same hour. Six weeks later, when that account is a deal sitting in stage two with a call recorded in Gong and a support ticket open, nothing in Clay knows those three facts belong to the same customer. Consolidating the sequencer into the enrichment tool made the stack smaller. It did not make the motion continuous.

This is the same failure that took down the standalone signals category, documented in what happened to signal-based selling: six signal companies acquired or shut down in twelve months, every buyer a company that already owned the customer record. A signal is worth what the context around it is worth. The tools that could not own the context got bought by the ones that could.

What the other side of the line looks like

The alternative to a run is a profile that keeps accumulating. Same customer, one record, and every event lands on it: the page views from last week, the product event from yesterday, the call transcript from Tuesday, the open deal, the renewal date. Nothing in that description is exotic. It is what a customer data platform was supposed to be, applied to the whole revenue motion instead of only to marketing.

Clay's Audiences feature is the closest it comes, and it is genuinely more than a spreadsheet. It imports millions of records from a CRM and a warehouse, layers enrichment and signals on top, and keeps records updated as the source data changes rather than on a scheduled refresh. Segments update on their own and can trigger ads or a sequence downstream. Credit where it is due.

The distinction that remains is attributes versus events. Audiences maintains what is currently true about an account. It does not keep the timeline of what that account did, and it does not stitch an anonymous visitor to a known contact once they identify themselves. Web intent is account level by design. Product usage can arrive as a custom signal but there is no event schema and no history. So the profile is persistent on attributes and absent on behavior, and behavior is what every job in the no column of that table actually runs on.

This is where the agentic GTM platform makes a structural bet rather than a feature claim, and it should be read as one. If the enrichment, the nurture, the deal, the call, and the renewal all read and write the same profile, then the eleven-week journey is possible because the state has somewhere to live. The Lifecycle Marketer responding to a stalled trial can see the open deal on the same account. The SDR working a job change can see the thread the last rep already had. And one customer context stops being a phrase and starts being the reason the follow-up is any good. The agent roles doing that work are only as useful as what they can see when they run.

The same reasoning applied to the record rather than the enrichment layer is in GTM platform vs. CRM, which arrives at the same test from the opposite side.

The honest counter-arguments

Three of them, and they are not weak. The first is that a specialist beats a generalist on the specialist's job, and enrichment is the job where that is most true. Clay's waterfall economics across a marketplace of providers is not something a platform replicates by adding a data partner. If contact data is the binding constraint on your motion, buy the tool that is best at contact data.

The second is that Clay's boundary is moving, and moving fast. Six product launches in one event, then a native sequencer, web intent, ad sync, Audiences, functions, a command line, and a context protocol server inside a year. Reading Clay's changelog as a straight line suggests the run-based architecture will grow surfaces the run test currently rules out. That is a reasonable bet and this post does not claim otherwise. What it claims is narrower: the nine no rows are all the same kind of job, so closing them is an architectural change rather than a feature release.

The third is the most uncomfortable one. Clay is at 84 percent adoption among GTM engineers for a reason, and part of that reason is that a table you can see beats a journey you have to configure. Debuggability is a real feature. A row with 40 visible columns tells you exactly why the output is what it is, and a stateful journey engine is much harder to reason about when it does the wrong thing. Anybody arguing for the platform side should concede that trade rather than pretend it does not exist.

There is also the survey finding that cuts both ways. In the same 228-person study where 84 percent use Clay, 26 percent named poor integrations and closed ecosystems as their main frustration, 11 percent named expensive platforms with limited flexibility, and 12 percent said outright that they want a true all-in-one outbound platform they cannot currently buy. That last number is small and it is the most interesting one in either dataset: the people most fluent in assembling the stack are the ones asking for it to stop being assembled. The wider consolidation trend behind that request is mapped in the best tooling for GTM teams.

The consolidation case is genuinely unsettled, though, and a post that leans on it should say so. Salesforce's annual State of Sales research has reported sellers juggling several tools per deal and sizeable shares of teams saying they plan to consolidate their stack. Scott Brinker and Frans Riemersma's annual State of Martech research has argued the opposite in the same period: that the stack is stratifying rather than consolidating, and that platform versus best-of-breed has no clean winner. Treat both as directional, not as a settled score.

Both readings can hold at once. Buyers want fewer tools, and the market is not producing a single winner that grants the wish. That is precisely why the argument here is about where state lives rather than a prediction that consolidation wins, and it is why the run test is scoped to one layer instead of to every point tool in the stack. Somebody running Clay plus a warehouse plus a CRM they trust may be making the right call, and nothing in that table says otherwise.

What this comparison does not claim

1. 1Not that Clay is a weak product. It is the strongest tool in its category and this post's table shows it winning six jobs outright, including the one most teams care about most.
2. 2Not that Clay should be replaced. The enrichment job has no better answer, and a team ripping out Clay to consolidate is optimizing the wrong variable.
3. 3Not that Clay pairs neatly with a platform either. Two systems holding two versions of the same customer is the problem, not the solution, which is why this post argues about where state lives rather than recommending a bundle.
4. 4Not that any analyst firm has drawn this line. The run test is this post's own framework, built from Clay's published documentation. The capability verdicts are checkable, the framework is an argument.
5. 5Not that the adoption numbers prove anything about architecture. ColdIQ's 62 stacks and Maja Voje's 228 respondents establish that Clay is close to a default. They say nothing about what it does or does not cover.
6. 6Not that the 6sense shortlist figures prove nurture beats outbound. They establish that most deals are decided before first contact. They do not establish which tool changes that, and the widely repeated nurture statistics that would have made the stronger claim turn out to have no locatable primary source, so they are not cited here.
7. 7Not that agents close the gap on their own. Where agent work returns something and where it does not is mapped separately in the honest map of agent coverage.

How to run the run test on your own motion

1. 1List the jobs your motion actually needs. Start with the 16 rows above and cut the ones that do not apply to how you sell.
2. 2For each one, write down where it runs today. Name the tool, or name the person, or write nothing if the honest answer is that it does not happen.
3. 3Ask the duration question per job. Does it finish when the run finishes, or does it need state next week? Be strict: a report you rebuild monthly is state you are maintaining by hand.
4. 4Flag every job you are faking. A formula column standing in for a maintained score, an export standing in for a handoff, a manual reminder standing in for a wait step. These are the real findings.
5. 5Count the tools each faked job touches. A job spread across three tools and a spreadsheet is where the cost sits, and the per-tool math in the real cost of a sales stack gives you the number to argue with.
6. 6Check what the acting system could see. For each automated job, look at the payload the action was built from rather than the integration diagram. A first touch built on the trigger alone is faster and no smarter, which is the trap in first-party data versus scraped intent.
7. 7Fix the longest-duration job first, not the loudest one. The job that needs the most state is the one costing the most manual maintenance, even when it feels less urgent than the one people complain about.

Step four is the one that changes decisions. Teams rarely have a list of jobs their tooling does not do, because those jobs get absorbed into somebody's calendar instead of showing up as a gap. Writing them down converts an invisible cost into a number, and the number is usually larger than the license the team was arguing about. The definitional groundwork for which signals belong in that list is in what buying signals are.

The version that holds up

Read the primary material rather than the comparison posts, this one included. Clay's sequencer page and its university documentation state the four-email cap and the one-entry-per-campaign rule plainly, which is more than most third-party reviews manage. Its lead scoring documentation shows the formula column approach directly. Two things to watch for while reading: Clay's own pages give provider counts of 50, 150, and 200 in different places, and the plan names and prices differ between the pricing page and the feature docs. Do not quote either number without checking it that day.

The defensible claim here is small. Clay owns the jobs that finish, and it owns them better than the alternatives. The jobs that do not finish need a profile that persists, and no amount of enrichment quality substitutes for that. So stop comparing feature lists, count how many of your own jobs need state that outlives a run, and decide on that number, which is the one input that will still be true after Clay's next release. If the count is high, one platform where the enrichment and the motion share a profile settles GTM platform vs. Clay differently than another tool bolted to the side of a table.