Clay Just Drained Its Own Moat (On Purpose)

What it means that Clay shipped a CLI and API

If you were forwarded this newsletter, join 9,852 weekly readers—some of the smartest GTM operators & founders—by subscribing here:

Thanks for reading this hand-poured, 100% organic, farm-to-table (human-written) newsletter.

Presented by:

Clay is the infrastructure GTM engineers build on. Start building for free.

& Supported by:

Attention → AI Agents for RevOps.

Clarify → The Autonomous CRM. Sell more, admin less.

Clearskies → The Context Layer for Revenue AI.

Nooks → All your outbound. One AI workspace.

Rox → Revenue Agents for the Global 2000.

Sumble → Buying signals from tech stacks, people data, & active projects.

Terret → The answer-to-action engine for revenue teams.

Hey y’all! 👋

Earlier this month, Clay shipped a public API and CLI. Something every GTM Engineer building at the cutting edge has been begging for for the last 6+ months. And the one thing almost everyone (myself included!) said they’d never be able to ship.

The consensus logic was simple: Clay’s stickiness lived in its UI. Open it up, and the moat drains. Adam Robinson polled “all of the smartest Clay pundits in the world” and they told him Clay would absolutely never do it (by the way, I told him the same thing when we talked on the phone last month).

They did it anyway (I was wrong), which makes Clay’s decision to go this direction all the more noteworthy. Today, I’m sharing my personal opinion of what it means for our space.

---

What Clay shipped

On July 8, Clay released an API, a CLI, and an Agent Plugin that bundles both (plus MCP and skills) into a one-line install for Claude Code, Codex, and Cursor. From Kareem’s announcement:

I found two things notable:

1. It’s available on every plan, including legacy self-serve. And work triggered through the API or CLI burns the same credits as work done in the product. No API tax.

2. The comments read like a pressure valve releasing. GTM engineers, growth leads, RevOps operators, and even CROs, who started building in Claude Code/Codex/Cursor 6+ months ago and have been switching to tools that work natively inside these coding agents.

   

Why everyone said they’d never do it

Back in April, I wrote out why I didn’t think Clay could (or would) release a public API without crushing their business (and even texted it to Adam). Clay’s moat had three layers.

Layer one: negotiated access+pricing to 150+ data providers (for more, see: aggregation theory). This allowed builders to work across multiple data providers in a single workflow/Clay table. And also enabled the—now ubiquitous—‘waterfall’ feature (which everyone is now copying).

Layer two: workflow lock-in. Your enrichment logic, your templates, your prompts, your team’s muscle memory, all living inside Clay’s environment. This second layer is the expensive to rebuild, which is the real switching cost.

Layer three: Their go-to-market motion. I think the most underdiscussed/underrated. They accidentally stumbled into it. Selling to agencies (“Claygencies”) who build content on their behalf, creating a magical, organic flywheel for Clay. I unpacked this topic back in January of 2025: Clay’s Moat (not a sponsored post).

A public API threatens both #1 and #2. Once an endpoint exists, someone builds an abstraction layer on top of it. Your workflow logic moves out of Clay’s system and into your own codebase, where it’s portable. Clay becomes the backend instead of the product.

But there was always a counterpoint: Clay charges per credit, not per seat, so the unit economics shouldn’t care about the delivery mechanism. However, an API doesn’t kill revenue directly. It kills stickiness, and lost stickiness kills revenue over time.

Adam Robinson heard the same thing that I outlined above:

All of the smartest Clay pundits in the world told me they’d absolutely never ever do it. What does THAT tell you about the state of the world?

My Take: You’re an idiot if you’re building UI for people.

…Leave it to Adam to make my point more crudely bluntly. :) (Hello if you’re reading this, Adam 👋)

Why they did it anyway

Demand. Again, Adam put it well:

This way of doing things is in such high demand that a $5B darling unicorn is willing to satisfy it, even though it’s very not good for the stickiness of their business.

Two things I’d add.

First, the users changed. The most technical (and often highest-spending) slice of Clay’s market now builds in Claude Code, Codex, and Cursor. I’ve seen this shift happen firsthand (myself included). GTM builders don’t want a UI. They/we want an endpoint. You can see examples of GTM teams building in Claude Code during an event back in April (which feels like a decade ago).

Second, Clay had every excuse to sit still. $100M+ ARR. 14,000 customers. A $5B valuation. Enterprise NRR above 200%. Clay shipped the feature its own moat argued against, in the fastest-shifting stretch software has ever been through. Most companies at that scale defend. Clay went on the offense. Adapting to the (quickly) shifting environment. Impressive to see.

This isn’t the UI dying, either. As my friend (and the person who first showed me Clay), Andreas Wernicke, said in the comments:

This and UI have to coexist.

It just stops being the only door in. Here’s an excerpt from a piece I published recently about building agents inside your CRM:

The pushback (and what it tells you)

This is just the start for Clay.

Matthew Quan (Product at Clay) responded to a common question in the announcement post:

Clay isn’t porting its UI to an API, feature by feature. They’re rebuilding the primitives around what agents do well: workflows as code, no row caps, and an agent that converts the old format into the new one.

For builders of GTM tech

An API, a CLI, and MCP support are no longer “nice-to-haves” in 2027. They’re “need-to-haves.” Your most technical users (RevOps, growth, GTM engineers, and increasingly even the SDR and sales leaders hacking in these tools) already build out of the terminal, and they won’t use products that can’t meet them there.

I understand that this isn’t just a simple feature. It’s a product decision, a pricing and packaging decision, an architecture decision, a positioning decision, and a go-to-market decision.

Building API/CLI/MCP-first forces the whole org to re-orient around it. And I realize it’s a big and scary decision. But if even Clay is doing it—and remember, this was supposed to kill their business model—you probably should too.

For buyers of GTM tech

When a vendor ships a real API, your workflow logic moves out of their UI and into your own repo, where it’s version-controlled and under your control (see: “AI sovereignty”). That vendor is choosing to win your renewal on capability every month instead of on sunk cost. Reward that choice with your budget, and be suspicious of the UI-only, seat-walled alternative.

Second, buying and building stopped being opposites. The old question was build vs. buy. The new motion is: buy the infrastructure (data, enrichment, execution, agents) and own the intelligence. Even if you’re building in-house tooling, and more teams are than ever, you should be buying infrastructure from Clay and other agent-native companies (like Rox, Sumble, Attention, Nooks, Clearskies, etc.).

Buyers used to ask “will my team actually log into this?” Now they’re asking “can my agents call this?” API, CLI, and MCP coverage moves from an afterthought to a first-order buying criterion, next to data quality and price.

Within 12 months, I think the vendors who treat the agent as a first-class user will win the most technical, highest-spending slice of the market—operators building in the terminal. And if you’re an operator in GTM, become someone comfortable in the terminal.

It’s unclear how it’ll unfold exactly (which makes this moment so exciting!). So, please reply to this email with what you think happens from here! I’d love to continue to evolve my thinking here. Regardless, it’s a blast to watch as the space shifts so fast, and we all figure out the new playbook together.

---

That’s it for today!

As always, thank you for your attention and trust. I do not take it for granted.

See you next time,
Brendan 🫡

Related posts:

• Inside “ChatGTM”: Cursor’s Internal Sales AI Used by their 400+ Sales Org (SDRs are booking 3x qualified meetings and AEs are shaving ramp by 50%+. What Cursor’s Head of Enterprise Growth, George Hou, built. And whether you should build your own version.)

• How to Think About Build vs. Buy in the AI Era (“Build Your Intelligence. Buy Your Infrastructure.” With Kyle Norton.)

• 9 Lessons From 11 Growth-Stage Companies That Built GTM Agents In-House (Vercel, Ramp, LangChain, ClickUp, Deel, Vanta & others: what they built, their tech stacks, and what we can learn from them)

• 54% of the Fastest-Growing B2B SaaS Companies have a GTM Engineer (Research Report by The Signal)