The smartest dumb pipe in B2B GTM. Your enrichment layer is more capable than you're treating it.

Stateless by default.

Clay's enrichment layer is the most data-rich pipe in B2B GTM. Seventy-five-plus providers. More than a billion requests. Every domain pattern, every industry, every account stage. None of it aggregates. The waterfall doesn't learn. The marketplace can't tell you which providers win for which segments. Claygent doesn't know which research patterns yielded replies last quarter. Each request runs as if it were the first.

The first version of this thesis was about MCP.

It centered on a single phrase from the April 22 MCP launch post — “creating a tighter feedback loop between Ops and sales teams”— and read it as a promise Clay shipped in only one direction. The argument was clean. The artifact ran on the rhetoric of quoting Clay back to themselves.

It died for two reasons. The first: MCP and Functions sit closer to the rep distribution layer than to enrichment. The role this thesis is for owns Claygent, the marketplace, integrations, and tables. A brilliant pitch in another PM's territory is a polite forward, not an interview.

The second: a single launch-post phrase is parry-able in ten seconds. The structural evidence — the waterfall above, Live mode as audit log, the negative-space audit — is durable. The linguistic teardown isn't. The enrichment-side version of this thesis is stronger because the evidence is in scope, the bet is in scope, and the strongest single piece of evidence is something only an Enrichment PM can act on.

Two views of the same architecture.

The Dashboard is where the intelligence shows up — Ops sees recommendations joined from cell-level data across thousands of customer tables. The Builder beneath shows what gets captured at each cell to make the join possible. The first recommendation in the Dashboard (“saves ~16 credits per row on .ai Series A–B accounts”) is what marketplace intelligence would have produced running on the waterfall in §I. Read top-to-bottom.

Marketplace intelligence. Provider performance by segment.

Capture the disposition signal Clay's pipes already produce. Aggregate provider win rates by industry, geography, account stage. Aggregate Claygent prompt-archetype performance by Function. Surface both as recommendations to Ops — not auto-applied changes. “Findymail won 73% on Series A–B .ai domains last quarter; Hunter won 31%. Promote Findymail to position 1 in your waterfall?”Ops decides. Clay provides intelligence Ops didn't have before.

This is a competitive asset no one else can replicate. Seventy-five-plus providers in the marketplace, billions of requests across every domain pattern and industry, and the implicit quality signal of which provider returned what for whom. No competitor has Clay's query volume; no competitor can replicate usage-informed routing without first becoming Clay. The advantage compounds with every enrichment run.

And no, this is not a competing surface to Sculptor. Sculptor today is stateless — every “why is this row here?” regenerates fresh, with no memory of past outcomes. Marketplace intelligence is the substrate. Sculptor stays the consumption surface, finally with something to remember.

Functions produce Outputs. Outputs flow into CRM as opportunities, replies, closed-won. Today the cycle stops there. Closing the dashed arc turns the marketplace into a node that accumulates — signal fills it as customers run Functions, recommendations refine routing, refined routing produces cleaner outputs, cleaner outputs become better disposition data. Each cycle makes the next cycle better. The dynamic that eventually counterweights it — what happens when everyone routes to the same provider — is named in §III.5.

Who this is for, and what could go wrong.

Who this is for.

The GTM Engineer or RevOps lead who builds Functions and configures waterfalls. They live inside Clay all day. They feel every dollar of wasted credit when finance reviews the bill. Marketplace intelligence is for them. Reps consume output via MCP or CRM; they don't see provider attribution, and they don't want to. This is explicitly not built for reps.

The pains, ordered.

1. i.
   Burned credits on dead-weight providers. The waterfall in §I produced 34 billed lookups for 5 valid emails — 15% efficiency.
2. ii.
   No data to defend provider choices when finance asks why the bill is what it is.
3. iii.
   Manual waterfall maintenance — provider quality drifts; Ops finds out from anecdotes, not signal.
4. iv.
   Provider sprawl. 75+ marketplace options. New customers don't know what to enable; existing customers settled into defaults years ago.
5. v.
   One waterfall, all segments. Biotech and fintech run the same cascade despite dramatically different provider performance per segment.

Why Clay should care.

The retention argument is strongest. “Clay saved us 30% on enrichment credits” is a renewal-securing line. It addresses the credit-cost narrative Clay's own March pricing memo names openly. Differentiation follows: no other orchestrator has cross-customer marketplace data at this scale, and it compounds with every enrichment run.

The subtle revenue risk is real. Helping customers spend less per row could shrink per-customer credit revenue. The honest counter: marketplace intelligence is the kind of feature that moves a customer from using Clay for one workflow to trusting it across their entire GTM stack. The lifetime-value gain from that bucket transition materially exceeds the per-row credit savings. Power users don't churn at credit prices. Casual users do.

What could go wrong.

Partner-ranking tension.

Hunter, Findymail, Apollo and the rest won't love being publicly ranked. Commercial relationships need careful handling — providers should see their own performance privately before any of it is user-facing.

Privacy and federated learning.

Cross-customer aggregation needs anonymization and a TOS review. Some customers will object to their outcomes informing others' recommendations.

Cold start.

Per-account recommendations need critical mass before they're meaningful. The fix is the standard collaborative-filtering pattern: seed with Clay's anonymized cross-customer aggregate, then personalize as per-account volume grows. Solved territory, not novel research.

Statistical significance.

Long-tail segments may never get enough signal — Series C+ logistics in EMEA, e.g. A confidence-threshold mechanic must hold back recommendations until n is meaningful.

Provider arbitrage.

If everyone routes optimally, the optimal providers gain pricing power. The marketplace's job is to keep that competition healthy, not to declare permanent winners.

What I'd ship.

1. Wks 1–3
   Diagnostic
   Partner with the enrichment + data eng team to query aggregate waterfall performance: provider win rate by industry, by account stage, by Function archetype. Pair this with 6 customer interviews (Ops champions running heavy waterfall Functions). Output: the actual shape of the loss inside Clay's pipe today.
2. Wks 4–5
   Architecture
   Marketplace-intelligence schema proposal aligned with eng. The smallest schema change to retain disposition signal from Scheduled Sources. Recommendation surface inside Functions, not a new app. Cost-neutrality and Ops-control reviews.
3. Wks 6–9
   Ship
   Marketplace intelligence v1 for one enrichment archetype (waterfall email finders) as an A/B test against control accounts. Reasoning capture for one Claygent column type, opt-in surface only.
4. Wks 10–12
   Validate
   Measure waterfall hit-rate delta on accounts running the recommendation surface vs. control. Propose Function-level recommendation expansion + sequencer-side signal-ingestion roadmap for v2.

Week one deliverable: a joint diagnostic with engineering and the Ops product PM — at which boundary inside the Functions execution path can disposition signal be retained, and what's the smallest schema change to do it?

Sidharth Sundaram.