KKR, the private equity giant, recently had me present to 16 of their portfolio Chief Revenue Officers on GTM AI transformation.

To be honest, I was a bit nervous. Then I realized presenting to a room filled of CROs is as new to me as those CROs actually using AI themselves.

If the impetus for for GTM AI transformation isn’t obvious, reports already indicate that high AI adopters generate 2X more revenue per GTM FTE compared to medium and low adopters. That’s a massive difference.

Like most execs, their urgency to adopt AI equally matched their hesitancy to chart a new course. It’s hard to drive change management when you don’t know how to use the tech yourself. This isn’t their fault. They don’t have nearly as much time to tinker, experiment, and build AI skills.

The above is the reason I started the AI Run Club for GTM Operators:

If you’re a Director+ GTM operator and looking to level up yourself, then you should join the AI Run Club. We’re building an exec AI coaching program that includes highly tailored training to accelerate your skills + how you use AI internally. Our upcoming session will teach you how to build a MEDDICC self learning Agent for your team. Reply to this email if you’re interested.

One of the CROs told the room he was pausing his AI initiative. He wanted to take a step back. Think through where AI should actually fit in their GTM before moving forward.

I kept my face neutral, but was thinking:

This guy doesn’t know how to use AI himself. He’s never automated a single workflow with his own hands. And he’s going to sit down and decide where AI belongs in his organization?

We’ll come back to that one at the end.

When we talk about AI transformation, I’m not talking about whether your team has access to AI uses chat like another search engine. Real AI transformation comes from changing how the entire org operates, the infrastructure we build on, our process for shipping & iterating fast, and route to a more sustainable competitive advantage.

AI GTM Transformation needs to be led at the top and change 4 things:

1. Objective - understand and continually seek GTM alpha.

2. Org design - operate more like product and engineering teams.

3. Infrastructure - new infrastructure & primitives are needed to engineer new GTM systems.

4. Process - ship in sprints, learn, iterate, improve.

You combine these to built modern, AI-native GTM systems that help you scale without increasing headcount. These systems follow a maturity curve:

Everett Berry, Head of GTM Engineering at Clay, and I are working on experiments to build the first GTM Loops. This is the name we’re giving self-optimizing agentic systems that improve overtime by executing GTM plays, analyzing data, improving AI with learnings, and then running the next iteration of the play.

We’re not there yet. So the key is to focus on the 4 elements above to drive more effective AI implementations for GTM.

AI adoption is no longer the story – how companies embed it is. And the gap between deep adopters and everyone else is now showing up in the numbers.

Companies with deeper AI integration are outperforming peers across funnel metrics, quota attainment, and team efficiency. The gains are most visible at the top of the funnel, where AI-influenced pipeline generation is driving meaningfully higher lead-to-MQL and MQL-to-SQL conversion rates– up 11% and 8%, respectively. The impact on active deal cycles is more modest for now, but the pipeline quality improvements are real and compounding.

The organizational implications are becoming clearer too. High AI adopters run leaner GTM teams at every revenue band, suggesting that AI is beginning to drive genuine leverage rather than just incremental productivity. The same revenue is being generated with fewer people, which changes the unit economics of growth in ways that will increasingly separate high-growth companies from the rest.

Let’s dive deeper into each one steps that your org can take today to start your AI transformation in GTM.

ICONIQ 2026 State of Go-To-Market

GTM alpha is your North Star

The teams pulling ahead right now aren’t winning because they have better reps or a larger budget. They are winning because of this equation:

Unique data × Unique plays × GTM Engineering capability

Canva detects off-brand content across social channels and sends tailored recommendations directly to design leads. Intercom analyzes the depth of a company’s support documentation to find new verticals. Reddit find recently launched products and then recommends 3 perfect subreddits that the company should advertise within. All of them are on auto-pilot. I personally built the Reddit system.

These aren’t AI experiments. They’re systems that run semi-autonomously.

That’s GTM alpha.

Organization design

GTM AI transformation is more of an organizational problem than a technology problem. To solve the org transformation, think of the following:

Broadly speaking, AI has birthed new roles in 3 general areas.

New roles in AI from product building → deployment

1. AI in software engineering - the AI Engineer

2. AI in go-to-market - the GTM Engineer

3. AI in customer deployments - the Forward Deployed Engineer

Those are the doers, and we’re also seeing the emergence of new leadership types of roles within each category. For example, GitLab just posted 2 new roles:

• AI Transformation Owner, CRO [$139,200 - $235,200 USD]

• AI Transformation Owner, Marketing [$152,800 - $259,200 USD]

(Kind of interesting that the Marketing role pays better)

These are the responsibilities of the AI Transformation Owner in the CRO office:

What are the characteristics of a GTM Engineer?

They typically come from an engineering/technical background and have the slope to learn the business context, or the other way around. You do need both sets of skills.

We look for the following:

The demand for GTM Engineers and Forward Deployed Engineers are exploding in parallel.

We have both teams at Clay. Check out my previous post Rise of the Forward Deployed Engineer and video on the GTM Engineering YouTube channel:

Transition from silos to a platform team

Historically, Sales Ops, Marketing Ops, and RevOps have worked in silos. Separate teams that build for their respective departments and less for the aggregate whole.

At Clay, the GTM Engineering department consolidates these into one function, Revenue Platform.

The team is run under our Head of Revenue Platform. Similar to a software engineering team, the Revenue Platform team builds infrastructure supports the GTM team to reduce friction and ship faster. Platform teams in engineering do the same thing, but for developers.

Many debate whether GTM Engineering is the same as RevOps. At one of our panel discussions, it was debated that RevOps is more about setting guardrails and is reactive, where as GTM Engineers are more proactive and invent new ways of doing GTM.

Loading...

Before our GTM Engineering team builds anything, they must figure out how that system services all segments of the GTM org: Sales, Marketing, RevOps, and Customer Success. The silos are collapsed. The results are systems that are more deeply integrated and have a more significant impact.

If you haven’t caught onto the analogy yet, it’s this…

GTM needs to operate more like product & engineering

Modern GTM orgs operate more like product & engineering teams these days.

The guiding principle here is thinking in systems, not headcount to scale the business. You need to ask yourself: “am I scaling by adding labor or by building systems?”

Architecting and building systems aren’t the operational elements. There’s much more that goes into operating like product & engineering:

Build once, then reuse. Engineers don’t rewrite auth for every feature. They build it once, version it, and compose. GTM still treats every campaign, account plan, and sequence as a one-off. Operating like eng means your enrichment workflows, signal definitions, message frameworks, and research skills become reusable assets that get versioned and pulled off the shelf across accounts and not rebuilt from scratch every time.

Deployment & observability. Engineers ship behind instrumentation. They can see what’s running, what broke, and what changed. GTM ships a sequence into the void and finds out three weeks later when someone notices reply rates cratered. Treat your outbound motion as a deployed system with monitoring, not a set-and-forget artifact. Speed-to-lead is a good place to start: it’s a service-level objective for GTM, and most teams have no idea they’re breaching it.

Spec before activity. Good eng work starts with a clear problem definition before anyone writes a line of code. GTM skips straight to doing. Borrow the PRD habit — what signal are we acting on, what’s the hypothesis, what does success look like — and you kill most of the low-quality motion before it ever ships.

Tight iteration loops. Product runs on build-measure-learn. GTM’s feedback loop is the quarterly pipeline review. Lagging and slow. Compress the loop so a messaging or targeting change returns a signal in days, not a quarter. (This is exactly what Clay’s bi-weekly campaign board does, which you get to below.)

Ownership & on-call. In eng, someone owns the service and is accountable when it degrades. GTM systems too often belong to nobody — the workflow that “just runs” has no owner until the day it breaks. The maturity move is naming who owns the machine. It’s the same reason the function is shifting from RevOps to GTM Engineering: proactive ownership of systems, not reactive guardrails.

So how do you start operating this way?

This is the advice I gave the CRO who wanted to pause AI:

• You don’t need to go all in on GTM Engineering, yet

• Start off with 2 high impact workflows (team + individual you) and figure out how to

  • Automate

  • Apply AI

• The process helps you figure out what’s possible.

• There’s always someone tinkering with AI on the team who is building in their free time. Figure out who that person is and free up more time for them to do that. This person has potential to become your first GTM Engineer

• Start to build buy-in from other stakeholders across GTM

• At the very least, get everyone a Claude or OpenAI subscription. Have a 1 day hackathon where everyone builds a skill. Show and tell at the end of the day. Then decide which one will have the biggest impact and operationalize it.

Infrastructure & Process

These are the last 2 changes that go into successful GTM AI Transformation.

I ran out of room in this newsletter, so I’ll cover the 2 topics in the next post.

I’m exited to announce the GTM Engineering & AI YouTub channel.

The Clay Studio team and I have a TON of content planned - all focused on the future of GTM, how to use AI, experiments we’re running, and interviews with incredible founders. Upcoming topics include:

• GTM Engineering benchmarks

• How Lovable uses Lovable

• Self optimizing ad campaigns with agents

• Learning loops in GTM

• A startup working towards automating businesses full-stack with AI. They want to be the first company to help a solo entrepreneur build a billion dollar business!

• Interview with the founder of AgentMail as a follow up to this post

We are gonna cook!

Back to regularly scheduled programming…

Subscribe now

A brief history of email

The most consequential piece of digital communication in history was sent by someone who wasn’t supposed to be working on it — and the message itself was so forgettable he couldn’t even remember what it said. What he accidentally invented in that moment still runs every inbox on Earth, and until about a year ago, it had never had a second kind of recipient.

In late 1971, a programmer named Ray Tomlinson was tinkering in a Cambridge, Massachusetts lab at a company called Bolt, Beranek and Newman — a government contractor building ARPANET, the precursor to the internet. His actual job was helping route data across the network.

But he’d gotten curious about a simpler problem:

People could already leave messages for each other on the same computer, but there was no way to send a message to someone on a different machine.

He wheeled his chair between two PDP-10 computers sitting roughly ten feet apart, typed a test message on one, rolled over, and checked if it arrived on the other. It did.

To make it work, he needed a way to separate the person’s name from the machine they were on. He scanned the keyboard for a character that wouldn’t appear in anyone’s name. He landed on @. “I thought about other symbols,” he later told Forbes, “but @ didn’t appear in any names, so it worked.” It was a practical decision made in seconds. The format he created — user@host — remains the global standard for every email address on Earth today, more than half a century later.

The message he sent? ”The test messages were entirely forgettable and I have, therefore, forgotten them,” he said. Probably “QWERTYUIOP.” He showed the system to his colleague Jerry Burchfiel and his first instinct wasn’t pride — it was caution.

”Don’t tell anyone,” he said. ”This isn’t what we’re supposed to be working on.”

Within two years, a study by ARPA found that 75% of all traffic on the network had become email. The infrastructure built to share computing resources and scientific data was being used, overwhelmingly, for people to talk to each other. The killer app of the internet wasn’t computation. It was conversation.

For 54 years since that moment, the fundamental shape of email never changed. A human writes. A human reads. A human responds.

2025 agents enter the email thread.

They now have email, too.

Say hello to AgentMail.

2026 last week - Clay integration with AgentMail is live!

What does AgentMail do?

AgentMail is purpose-built email infrastructure for AI agents. Not AI for your email. Email for your AI.

Every tool in your GTM stack that touches email right now is a one-way pipe. Smartlead sends. Outreach sequences. Klaviyo broadcasts. None of them give your agent a persistent inbox — a place to receive, thread, reply, and remember.

AgentMail provisions real inboxes via API. One customer alone runs 25,000 inboxes through the platform, handling millions of emails. It handles deliverability, spam prevention, proper email headers, and threading.

Why do agents need an email?

Here’s an example:

Browser Use is the open-source framework that gives AI agents control of a web browser — 96,000+ GitHub stars, used by Fortune 500 and YC teams to automate real tasks on real websites. They hit a wall that had nothing to do with browser control: the moment a site asked an agent to check its email — a signup confirmation, an OTP code, a 2FA prompt, a password reset — the run just stopped. The agent had no inbox to receive anything, so a human had to step in and paste a code. The bottleneck was never the browser. It was identity.

Browser Use’s fix was to give every session its own AgentMail inbox, automatically, no config required. Tell the agent to sign up for a service, and it creates an inbox, fills in the form, waits for the verification email, confirms the account, and keeps going — no human, no pause. The same primitive — a real inbox an agent actually owns — that unblocks a browser agent stuck on a verification screen is what unblocks a Clay table that’s been able to send email but never receive it.

What makes AgentMail + Clay such a special combo?

The thing that makes this different for Clay specifically: before today, email was only ever an output from a Clay table. You could send from Clay. But you couldn’t receive. You couldn’t trigger a Clay workflow when someone replied, signed up, submitted a form, or sent anything back.

That changes now. Your Clay table can have its own inbox — and that inbox can kick off workflows, update rows, classify intent, route to CRMs, and trigger actions the moment an email arrives.

Here’s what that opens up.

11 Clay use cases with AgentMail

1. Build an AI SDR in Clay

AISDR runs autonomous SDR agents at scale on AgentMail with roughly 500 inboxes in production and 7,000 emails per week, no human in the loop.

You can now build this in Clay.

Build a table enriches and scores prospects, generates a personalized first-touch via Claude, and fires it through an AgentMail inbox. When a prospect replies, a webhook fires, Claude classifies the intent — interested, objection, referral, not now — and the agent responds within the same thread. A human AE only gets a Slack ping when there’s a live buying signal in the thread.

2. Measuring speed to response for form fills

We have the speed to lead GTM Engineering benchmark coming up. We used Subconscious.dev agent to fill out thousands of B2B web forms (contact us, demo request, etc.). We couldn’t have done this easily without AgentMail. Subconscious agent provided an AgentMail address as the contact email, logs the submission timestamp, and then the webhook fires when the first response arrives. You now know exactly how fast every company in a given market responds to inbound leads — measured the same way, at the same time, across an entire category. No survey data, no self-reported numbers. Just timestamps.

There’s hundreds of variations to this with forms on the web.

3. Inbound reply handling without a human SDR

This is the minimum viable version most teams should build first.

Right now someone on your team reviews replies every morning and triages manually. That’s a bottleneck where the fastest leads go cold.

Replace it: AgentMail webhook fires on every reply, Claude classifies intent, routes automatically. Interested → drop a meeting link and log to CRM. Not now → set a 30-day snooze. Referral → extract the contact name, create a new Clay row, start a new thread. Unsubscribe → suppress forever, no exceptions.

You still write the first-touch. You just stop doing the triage.

4. CC an agent into a live deal thread

Every AE has live deal threads where context lives and dies in their own inbox — what the prospect said, what was promised, what’s still open. None of that is visible to RevOps until the deal closes or stalls.

CC an AgentMail inbox on the thread. The agent reads every message as it comes in, tracks context across the whole conversation, and can draft follow-ups, suggest next steps, or schedule the next meeting. Every meaningful update gets written back to Clay — what was discussed, what’s outstanding, what changed. RevOps gets visibility without asking the AE for a status update. The AE gets a second set of eyes on a thread that used to be a black box.

5. Forward messy GTM signals into Clay

The signal you need is almost never sitting in a clean database. It’s a newsletter mention, an ICP list someone shared in Slack, an intro email, an event attendee list, a funding alert, a job-change notification — all landing in someone’s personal inbox and going nowhere.

Forward any of it to an AgentMail inbox instead. AgentMail turns the email itself into a workflow trigger — it doesn’t matter if the body is a forwarded newsletter or a pasted spreadsheet. Clay picks it up, enriches the people and accounts mentioned, segments them, and routes them into the right GTM motion. The inbox becomes the front door for every messy, unstructured signal your team already has — instead of letting it die in someone’s forwarded folder.

This is one I built for a rep selling financial services at UBS to startup founders. I used AgentMail to turn PitchBook emails into automated signal → outbound workflow.

6. Reply-based outbound automation

This is the more general version of use case #3, and it’s worth building even if you already have a triage process, because the classification logic is where most teams under-invest.

When a prospect replies to an outbound campaign, AgentMail captures the response and classifies it — positive, not interested, OOO, referral, needs follow-up. From there, Clay enriches the account with whatever’s missing, assigns an owner if one doesn’t exist yet, and hands the rep (or the agent) everything needed to draft the next reply with full context. The output isn’t just a routed lead — it’s a fully prepped next move.

7. Email-native meeting prep

The annoying part of meeting prep isn’t the research — it’s remembering to do it before every single call, especially the ones that get added to your calendar with two hours’ notice.

Forward the prospect or customer thread to an AgentMail inbox before the call. Clay generates an enriched account brief on the back end: company context, the relevant stakeholders, recent signals (funding, hiring, product launches), known pain points, and suggested talking points based on what’s already been said in the thread. By the time you open your calendar invite, the brief is sitting in your inbox.

8. Per-account research agents with persistent inboxes

Most enrichment is pull-based — you query an API and get back whatever’s cached at that moment. This inverts it. Spin up a dedicated inbox per target account, and have the agent subscribe to that company’s competitor newsletters, product announcements, job change alerts, and press releases on its behalf. When something lands, the webhook fires and updates the Clay row in real time.

You’re not scraping anything. You’re building a listening layer per account that gets smarter the longer it runs.

This one is on my to do list to build & try out.

9. Two-way partner channel management

Channel programs break at scale because the coordination overhead per partner eats the margin. Build an agent that manages a partnerships@yourdomain.com inbox: receives partner lead submissions, extracts structured data, routes to the right AE with context, sends a professional acknowledgment, and logs to CRM.

The agent holds the thread and only surfaces a human when the deal is warm enough to need one.

10. A lightweight GTM command inbox

Sometimes the fastest interface isn’t a tool, it’s an email. A rep or operator emails a plain-language request to an AgentMail inbox — “enrich these companies,” “find me 20 accounts that look like this one,” “prep these leads for tomorrow” — and Clay handles the enrichment and workflow execution on the back end, replying in the same thread when it’s done.

No login, no new tab, no learning a new interface. The inbox is the UI. For non-technical reps especially, this collapses the gap between “I know what I want” and “I know how to ask the system for it.”

11. Multi-agent coordination via email threads

The most architecturally interesting use case. Instead of building complex orchestration infrastructure to pass state between agents, use email threads as the shared memory layer.

Research agent drops enriched prospect context into a thread. Outbound agent picks it up, writes and sends the first-touch. Reply-handler watches the inbox, classifies responses. CRM sync agent reads the thread and updates Salesforce. Each agent has its own inbox. The thread is the handoff protocol.

Email becomes the message bus. It’s already universally understood, persistent, and standardized. Using it for agent coordination instead of building something custom from scratch is exactly the kind of move that looks obvious in retrospect.

Emails give agents an identity

Clay has been adding more and more purpose-built agents — research agents, enrichment agents, outbound agents. Every one of them has had the same missing piece. They could act, but they couldn’t be reached. They had no address.

That’s the gap AgentMail closes, and it’s bigger than any single use case above. Agents now have an identity. It can be CC’d. It can be replied to. It can hold a conversation across days or weeks without losing the thread, literally. Once every agent in your stack has that, the whole category of “things only a human could do because only a human has an inbox” starts to shrink.

Btw Agents just got phone numbers, too:

Where this goes next

A few things worth watching, because they’ll shape how fast this category moves.

Agent traffic is already outpacing human traffic, faster than anyone predicted. Cloudflare tracked agentic AI traffic growing nearly 80x over the course of 2025, and crossed the point where bot traffic exceeds human traffic about a year and a half earlier than its own CEO had forecast. The agents showing up in inboxes aren’t a future trend to plan for. They’re already the majority of the traffic.

Email is the first layer of a much bigger identity stack, and the people building this know it. Email is the start, not the finish. As agents take on more of what humans currently do, they’ll need credentials, reputation, and trust — the fuller architecture of an online identity — not just an inbox.

The next billion internet users are already arriving, and they’re agents that just need somewhere to receive their mail. Inbox first, then the rest of what identity requires.

Standards for proving who an agent is are showing up faster than most people realize. Google’s Agent-to-Agent protocol, OpenID’s extension for agent identity (OIDC-A), and a wave of academic work on delegation chains and cryptographic agent verification are all trying to solve the same problem from different angles: when an agent shows up in your inbox claiming to represent a company, how do you know it’s telling the truth? Nobody’s fully solved this yet. Whoever does will own a meaningful piece of how every agent-to-business interaction gets trusted.

Security is the open wound, and it’s GTM’s problem too, not just engineering’s. Prompt injection through email is a real, demonstrated attack vector — a malicious actor can craft an email specifically to manipulate the Claude prompt reading it, not just the human. Any team building reply classification or autonomous response logic needs to treat every inbound email as untrusted input, the same way a developer treats user input on a web form.

The winners will be the teams that treat the agent’s inbox as infrastructure, not a feature. Every prediction above points the same direction: agents are going to need persistent, verifiable, increasingly trusted identities, and email is the first and most universal piece of that. Teams that build on top of that primitive now — rather than waiting for a fully-baked, all-in-one platform — will have a multi-year head start by the time this becomes the obvious way every GTM team operates.

How to setup ‘email as a source’ in Clay with AgentMail

1. Setup an AgentMail account

Complete the following steps in your AgentMail account before connecting to Clay.

1. Sign up at agentmail.to and open the dashboard.

2. Add a domain. In the AgentMail dashboard, add the domain or subdomain you want to send and receive from. AgentMail will generate DNS records (MX, SPF, DKIM, DMARC) for you to add to your domain manager.

   • If your root domain already receives mail through Gmail (Google Workspace) or Outlook (Microsoft 365), its MX records already point to that provider. A domain’s MX records can only point to one mail server, so you cannot also route it to AgentMail. Use a dedicated subdomain instead (e.g., inbox.yourdomain.com).

3. Add the DNS records. Copy the records AgentMail generates into your domain manager exactly as shown — type, name/host, and value. DNS propagation can take a few minutes to a few hours. Once the records are in place, click Verify Domain in the AgentMail dashboard.

4. Create an inbox. Once your domain is verified, create one or more inboxes (e.g., sales@inbox.yourdomain.com). This is the live address Clay will listen to.

5. Generate an API key. In the AgentMail dashboard, generate an API key. This is the only credential you need to connect AgentMail to Clay.

For more detail on domain configuration, see AgentMail’s custom domains guide.

2. Create a Clay table and use AgentMail for ‘email as a source’

1. In a workbook, click + Add at the bottom.

2. Search for AgentMail and select it from the results.

3. In the modal, you will be asked to Select AgentMail account.

   • If you haven’t already connected your AgentMail account, click + Add account and enter the API key you generated.

You can check out more Clay + AgentMail documentation here.

GTM Engineer role of the week

Honesty, I’m thinking of applying to this one. That’s how cool I think this company is and how much potential it has.

That’s right… AgentMail is hiring a Founding GTM Lead.

Check out more details here.

Subscribe now

25% of clay.com’s web traffic comes from programmatic SEO. That’s 8,000 landing pages generating ~400k visits every month (1.6M total).

The best part?

The system is easy to replicate with Clay. I’ll show you how in this newsletter.

Then I thought, what if I run an experiment to see if the same approach can drive faster subscriber growth for The GTM Engineering Newsletter. Had to do it. I started building.

That’s the experiment I’m kicking off.

And I’m going to share everything with you:

1. The workflow

2. How to build the system step by step

3. What I’m tracking

4. Metrics

5. SEO & AEO best practices

6. What I’ve learned along the way

Just as I was finishing the first MVP (and super excited), I learned a few weeks ago (May 21) Google shipped a core update that specifically targets this type of approach - templated landing pages that simply replace variables with keywords.

Then there’s AI and the internet yelling SEO is dead.

So, is it working for Clay due to the brand or something else? And, will it work here?

Is SEO dead or has it just evolved?

The hypothesis: a GTME job board as a growth engine

The goal is to attract more GTM Engineers or any GTM Operators interested in the field.

Here’s what that person is doing right now:

• Searching for GTM engineering jobs

• Researching companies who are hiring

• Comparing salaries as they range widely

• Figuring out how to prepare for those interviews

Based on the 2026 State of GTM Engineering, hiring exploded during 2025, with over 3,000 open positions by January 2026 and compensation ranging from $60K to $250K for roles with specialized AI skills. The role is hot.

Report was in collaboration with who writes and who writes . Both are great, check them out!

A standard job board would capture some of that traffic. But standard job boards are boring. You scroll past 40 listings, maybe save one, close the tab.

1. There’s no reason to come back tomorrow.

2. There’s definitely no reason for AI to cite you.

Here’s the twist to solve both: every company page on this job board includes a research layer that helps you decide if it’s actually worth joining. Not just salary ranges.

The stuff you’d want to know before you quit your current job:

• Funding history and total investment raised

• Investor tier (who’s backing them — a16z or a no-name rolling fund?)

• Employee growth rate over the past 12 months

• News momentum — is the company getting press or going quiet?

• Why the company is interesting — actual thesis, not a copy-paste of their careers page

• Competitive landscape — who they’re up against and how they’re positioned?

• Technographics — is it a stack you know?

A GTM Engineer who’s job hunting isn’t only asking “who’s hiring?” They’re asking “which of these companies should I bet on?” And “who will be the best for?

The reason most programmatic pages fail is that they’re thin.

This is a data problem.

The test: if you stripped out the company name and the remaining content was still generic, the data isn’t doing enough work. Claygent-enriched company profiles with funding history, investor tier, and headcount trajectory is proprietary data a generic AI couldn’t generate without the same toolchain. That’s what makes a page worth ranking — and worth citing.

Example GTM Engineer job post page

More data coming soon… the build is still in progress.

Before we get into the build, lets dive into a few primers.

What programmatic SEO?

Quick definition for anyone who hasn’t touched this side of GTM: programmatic SEO means pairing a data source with a template to generate pages automatically instead of by hand — “best CRM for [industry]” times two hundred industries, or in my case, one page per open GTM engineering role. The technique is as old as SEO itself. What’s changed is the bar for what counts as a legitimate page versus a doorway page Google is now actively hunting.

Why “pSEO is dead” is the wrong read

Google’s May update arrived days after Google I/O 2026, where the company announced AI Overviews had crossed roughly 2.5 billion monthly users and AI Mode had passed 1 billion — plus a new AI-powered search box the company billed as its biggest search change in over 25 years. Read the two announcements together and the message is coherent:

Google is getting more aggressive about surfacing answers directly, which means it has less patience for pages that don’t add anything beyond what the answer already contains.

Clay’s own team is the clearest evidence that the response to that isn’t to stop building programmatic content, but to stop treating it as fire-and-forget. Clay maintains a library of over 8,000 “dossier” pages: detailed company and executive profiles built to answer questions people are actually searching. Instead of letting them go stale, Clay built a Clay table that pulls each page’s content from Webflow, checks whether the underlying data has changed, rewrites the stale sections with an LLM, and pushes the update back to the CMS automatically. What used to be a two-week content cycle — keyword research, brief, draft, edit, publish — now runs in about three days, on a continuous loop.

Comparative search volumes

Google’s own disclosure puts it at roughly 5 trillion searches a year — about 13.7 billion a day. ChatGPT’s total prompt volume is enormous, but the slice that actually functions like a search query is much smaller: independent clickstream analysis from firms like Ahrefs and SparkToro puts genuine search-like ChatGPT activity in the tens of millions of queries a day, not billions.

This is why you need both SEO & AEO.

The SEO updates from Google this year

What is E-E-A-T and how does Google judge content?

How do you build a programmatic SEO engine with Clay?

This is the high level workflow:

Step 1 — Design the job board in Claude Design. You can also do this in Lovable. I just have my design system setup in Claude Design.

Note: There’s 2 ways you can send this to Lovable: 1) MCP connector 2) Asking Claude for an HTML download and prompt to recreate it in Lovable

Step 2 — Open job signal detection Clay table. A Clay table monitors job postings for open GTM Engineer roles. When a new role appears at a company we haven’t seen before, it gets added to the table and triggers enrichment

Step 4 — Enrichment workflow with agentic research. Multiple Claygents researches each company: funding history from Crunchbase, investor tier classification, LinkedIn employee headcount over time, recent news via web search, etc. To get a unique data point, we can come this to data that was found in the ‘26 State of GTM Engineering Report.

Key: you also need a column that generates a unique URL slug or each page.

Step 5 — Send data to Supabase via HTTP API. This is our database layer that Lovable will pull from to generate the pages. Once the job openings in Clay are enriched they’re sent to Supabase (that is managed by Lovable) via an HTTP API column.

Key: copy the JSON Body in the HTTP API column and tell Lovable that you need the Supabase table to support the variables and update the DB

Step 6 — Supabase as the data layer. Enriched company records land in a Supabase table. This becomes the source of truth that feeds the site. When the Clay table refreshes weekly, Supabase updates automatically.

Step 7 — Lovable generates the pages. Each company gets a landing page on gtmengineering.ai, populated from Supabase.

There’s some additional work & prompting to build the site, but more on that + AEO best practices in upcoming posts.

Programmatic SEO is not the only Clay marketing use cases. There’s actually many…

What are Clay’s top marketing use cases?

1. Account Based Marketing

2. Events

3. Advertising

4. Trigger based campaigns

5. Lifecycle marketing

6. Automated inbound follow ups

7. Dark funnel (personal emails to work identities

8. Content generation

9. AI lead qualification

10. Programmatic SEO

11. Competitive research & monitoring

12. Customer intelligence mining from call transcripts

13. Data analysis

14. List building

15. Content localization

The list goes on… and there’s multiple use cases within each category.

Coming up in Part 2

I likely won’t have results yet, so I’ll plan to go deeper on the technical aspects of the experiment:

1. Reveal of the site

2. SEO page best practices

3. AEO 101 and best practices

4. Tips from AEO experts

5. Monitoring

Clay grew from < 30 to over 300 in 2 years. Sales will grow to 100+ by EOY from 60 today.

As new GTM Engineers join, I’m frequently asked: “what have you learned about AI & GTM Engineering over the last 2 years that’d help me get going?”

In this post, I share 30 insights I’ve been collecting & where I think GTM Engineering is headed.

Before we dive in, I also want to bring you up to speed on a few projects I’ll be sharing more of soon:

1. AI Run Club - Executive coaching, but for AI. More on this below.

2. GTM Engineering Benchmarks - A new content series that will help you:

   1. Benchmark against your peers

   2. Provide steps you can take to improve your GTM systems

   3. Behind the scenes on how we built the workflows to collect the data

3. GTM Engineering Labs - A YouTube show that I’ll host and will be produced by the Clay Studios team. (Might change the name, tbd)

4. Experiments - I’ll be using this newsletter & site to run growth experiments and share everything that I learn. The first one will be using a Job Board to drive programmatic SEO. This will come with a twist…

If you’re not subscribed, come join the fun!

Subscribe now

AI Run Club

It takes time to become AI-fluent (and actually productive). Tinkering, experimentation, & distilling/staying on top of what you really need to know.

The challenge is execs are too busy.

I’m starting the AI Run Club with fellow AI-pilled friends Nick Goel, GTM Engineer at Clay, and Jeff Ignacio, RevOps leader who writes the popular RevOps Impact Newsletter.

Our goal is to help execs accelerate their AI skills (and AI strategy for their teams) with:

• Virtual lessons

• Weekly content

• Community of like minded

We’re looking to start with 20 VPs (10 open spots) who:

1. Understand the importance AI skill development

2. Deeply feel this is the key to staying competitive

3. Have a desire to learn

4. Excited to connect & learn from peers on the same journey

Subscribe now

31 insights from 2 years in GTM Engineering

1. GTM Engineering is not just outbound email.

Sounds obvious, but people forget there’s almost infinite use cases (many not discovered). Which ones are most common/needed? I shared the most in demand Clay use cases that enterprises are paying for on LinkedIn:

• CRM enrichment

• TAM sourcing

• Automated inbound

• AI outbound

• Account research & scoring

• Signals & intent driven workflows

• Account Based Marketing

• GTM co-pilots

• Just in time rep enablement

• Data analysis (like reverse engineering signals on closed won opps)

2. AI broke the SaaS post-sale model.

Deploying AI isn’t like deploying SaaS. This is why the Forward Deployed Engineer is the hot new role (and why Clay is building a team). There's A LOT of customization to get AI working: context engineering, discovery, evals, iterations, constraints, etc.

More on this here:

3. Executives all want to adopt AI, but struggle to give direction.

Becoming AI-fluent takes time, tinkering, and experimentation. Naturally, they don’t have this luxury. This impacts how they direct their teams to use AI. There’s a big opportunity to provide an accelerated learning path and that’s why I’m bullish on the AI Run Club.

4. AI is reducing team sizes, and not replacing all jobs.

There’s a lot of fear, but it’s really those who become AI-fluent who they need to worry about. New titles have emerged to put a name on those who are AI-fluent and it’s typically just placing ‘Engineer’ after the function; like Marketing Engineer from Profound.

Some companies have significantly reduced their SDR teams or cut them. This is more prominent for inbound SDRs. Clay has an SDR team and its growing.

Rob Cook leads the team and he’s one of the best SDR leaders I’ve come across in my career. Come join if you’re looking at these roles.

5. AI Software Engineer > GTM Engineer > Forward Deployed Engineer.

AI 100x'd software teams 1st. Then came the GTM Engineer to bring products to market faster. Now the FDE is on the rise to ensure AI products are sticky and deployed correctly. Every size company from early stage startup (1-50 employees) to large enterprises are hiring for the role.

6. The next frontier in GTM is learning loops & self-optimizing systems.

Learnings compound into nuanced playbooks over time and add to your moat.

7. Context engineering is more important than the workflow.

Bad context upstream compounds downstream.

8. Speed to lead is more important than ever.

This is the difference between getting to the prospect before your competition. That prospect is filling out all forms at once and is coming in much more informed. Connection and qualification drop off faster than most realize.

This will be the first GTM Engineering Benchmark that I’ll be releasing.

Subscribe now

9. AI hasn’t freed up anyone’s calendar.

If anything, everyone is more busy with higher expectations to produce more.

10. System thinking is an imperative.

Not only for building new types of GTM systems for your business. Think how you can build AI and agentic systems for your own productivity.

11. AI is coming for more labor vs. software budgets.

Salesforce isn’t going to be replaced by AI apps. Most don’t realize that enterprises only spend ~5.7% of annual revenue on software. AI will eat more labor budget than software. And, there’s much more value to build new types of software vs. risk replacing a stable system. The savings won’t compare to focusing on the labor budget.

12. Vibe coded apps are replacing GTM point solutions.

Lovable is replacing everything from CPQ (this one really surprised me) to customer onboarding portals, and even Google Slides for decks.

This points to GTM teams using a smaller number of vendors who provide infrastructure to build a fuller spectrum of capabilities. Cobbling together point solutions just leaves you with a fragmented stack.

13. GTM Engineering requires real key stakeholder buy-in.

Leadership needs to be open with rapid experimentation and trying new things. Sadly, there’s still many that are stuck in their ways.

14. MQLs are getting replaced by AI Qualified Leads (AQLs).

Automated inbound and AI qualifying leads is one of the most popular Clay workflows we deploy for customers.

15. Enterprises are still solving foundational problems.

• Data foundation

• Automation

• Sales rep workflows

Some skip to deploying agents before they get the data right and that’s key reason deployments aren’t successful or don’t produce ROI.

16. Data maturity is the first step in AI maturity.

1. Data foundation

2. Agents

3. Orchestrated agents

4. Self-learning systems

Each one builds on the prior.

17. Agents have started calling prospects.

I didn’t think this would happen or work (anytime soon), but that’s what the RevAI team at Monday.com has built. Agents call and follow up with hundreds of inbound prospects. Meetings are getting booked. Obviously, we hope this doesn’t move over to cold calling.

18. More powerful LLMs don’t necessarily give you better results.

Content is the code. Less powerful LLMs with the right context outperform more powerful LLMs without context.

More on how this plays out and how to improve in Clay —> Context Engineering 101 for Clay.

19. Agencies tout that Claude can replace Clay.

In reality, enterprises need security, governance, observability, and deterministic workflows. That’s hard to do if you’re vibe coding GTM systems. By the way, Anthropic is one of Clay’s largest customers.

20. On hiring GTM Engineerings:

You typically get 2 different personas. A great GTM Engineer will be able to learn the side because you need both:

• Technical skills

• Business context

21. Want to get AI-pilled? The most AI-fluent:

• Start with curiosity.

• Experiment daily to learn what's possible.

• Start by selecting one repetitive workflow and figure out how to automate it.

• Iterate on it (and the next ones) until you get it right.

• Use AI as a sparring partner, not only as an answer engine.

• Turn great outputs into skills for reusability.

• Repeat steps A through F

22. AI disproportionately impacts higher performers.

Everything you engineer for sales reps will have a disproportionate impact on high performers compared to the bottom. AI won’t make you better at sales. You still need to be good - have the right mindset, motivation, curiosity, and so on. AI and GTM Engineering will raise the floor of the team, but the distribution won’t be even. This is important to keep in mind and for expectations

23. Building Clay tables isn’t the future in Clay.

Think more along the lines of infrastructure for building GTM systems. Data will always be at the center, but the future of what you build and how you build it will be different:

• Clay MCP - use Clay from within your chat/LLM interface; Claude, Codex

• Agents - example: continuously scores and prioritizes accounts based on new intelligence or signals.

• Functions - turn workflows into functions you can call instead of building the workflow again.

• Workflows - think 8n8 killer.

• Skills - with Clay infrastructure (functions, workflows, data in the backend).

• Apps - company specific apps built on top of the data / GTM infrastructure. Increasingly these are vibe coded.

• Unified context layer - this is Audiences (just launched) that combines all of your 1st & 3rd party data

• Learning loops

24. GTM Engineering generally has 2 phases:

The 2nd one is where you find real GTM Alpha.

25. Rep interfaces are dying.

Almost everything a rep logs into (except email, calendar, slack) will be replaced by doing work in Claude Cowork or Codex. Custom skills, apps, workflows, and orchestration via MCP to all of your systems. Voice will be the interface Cowork/Codex.

26. On building a career:

Get really good at building and share what you’re doing. Having a personal brand gives you leverage & increases your surface area for luck in business. Plus it accelerates connections. It’s helped me make plenty of good friends along the way.

27. Consider deterministic vs. probabilistic.

Use deterministic logic to route and gate, probabilistic logic to enrich and personalize. Deterministic handles: “does this lead meet ICP criteria?” Probabilistic handles: “what’s the right angle to open this account?”

3 predictions for GTM Engineering

28. All components of GTM will be self-optimizing.

An agent will be responsible for analyzing the conversion rates of landing pages, running experiments, and then automatically adjusting the page based on the data. This loop repeats. Now think of everywhere this could apply:

• Website design

• Ad campaigns

• Outbound prospecting

• Marketing content

• The list goes on… there will be learning loops built into all functions.

29. The hot new sales question will be:

“What is your labor budget and how much do you want to 1) reduce 2) move to software?”

The ratio of labor to software budgets will indicate how large the opportunity is.

30. The most important marketing KPI will be:

The frequency of product mentions in ChatGPT, Claude, Perplexity, and related AI answer engines.

AEO then becomes one of the most important skills to learn in GTM

31. Distribution and deployment are the moats.

Everything in-between can be replicated. But distribution and deployment require taste & judgement.

Both can’t be outsourced to AI.

Recent posts

16 slides on Context Engineering

For a long time, ZoomInfo was considered the gold standard data provider.

Then Clay pioneered GTM Engineering and the data marketplace.

Now most companies want to adopt Clay’s GTM Infrastructure without sacrificing an experience reps are used to.

One question always comes up… “how do we replace the rep experience of ZoomInfo since Clay isn’t designed for reps?”

This is where Exportly.ai comes in and why I’m excited to host it’s Founder, Elliot O’Connor, for this guest post. Exportly.ai is the most intelligent chrome extension for reps specifically designed to work with Clay. This is how to build a more powerful prospecting system for your reps and why a $20B company just moved a $1M+ ZoomInfo contract over to the tech duo.

Migrating off ZoomInfo

Replacing ZoomInfo is not a data project.

It is a GTM systems project.

The mistake: looking for another ZoomInfo

Most replacement projects start the same way. A renewal comes up. The team makes a spreadsheet. ZoomInfo goes in column A. Apollo, Cognism, Lusha, LeadIQ, and a few others go in the next columns. Then everyone compares database coverage, seat cost, and contract terms.

That can be useful, but it misses the bigger shift.

ZoomInfo is a vertically integrated sales data product. It owns the data, the interface, the integration paths, and the user experience. That is why it feels easy to reps. They open LinkedIn, click a button, reveal a phone number, and push a contact.

It is also why the contract can feel bigger than the use case. Many teams bought a platform, but the behavior that actually renews every day is much narrower:

Search. Reveal. Enrich. Export. Sequence.

Clay and Exportly split that system into two layers:

• Clay is the programmable data and workflow layer.

• Exportly is the rep-facing interface for those Clay workflows.

With ZoomInfo, you get the workflow ZoomInfo decided to build.

With Clay and Exportly, you get the workflow your GTM team decides to build.

That is a very different operating model.

Consolidate or compose

Most ZoomInfo replacement content pushes one of two arguments.

The first is consolidation:

Replace ZoomInfo plus Outreach plus deliverability plus social automation with one all-in-one platform.

That argument is compelling for teams whose stack is fragmented, underused, and expensive.

The second is unbundling:

Stop paying for the parts of ZoomInfo you do not use. Keep the tools your reps already like and replace the data & workflow layer.

That argument is compelling for teams that already have Salesforce or HubSpot, already have Outreach, Salesloft, Gong Engage, or Apollo, and already use Clay as the enrichment brain.

Clay plus Exportly belongs to the second camp, but with an important twist.

You are not just unbundling the contact database you bought from ZoomInfo. You are making the workflows programmable and therefore customizable.

Replace the rigid data-and-export motion with Clay workflows that can be exposed to reps through Exportly.

What you are actually replacing

Most teams say they use ZoomInfo for contact data.

That is only partially true.

In practice, ZoomInfo usually handles five jobs:

• It gives reps a familiar place to get data.

• It provides email and phone enrichment.

• It moves records into Salesforce, HubSpot, Outreach, Salesloft, Gong Engage, Apollo, or wherever the next action happens.

• It creates a sense of autonomy for reps.

• It creates contract gravity because ZoomInfo feels like the safe default.

The first four are workflow problems.

The fifth is a change-management problem.

That distinction matters. If the replacement forces reps into an admin-heavy workspace, adoption will suffer. If it gives them better data but breaks CRM matching, RevOps will not trust it. If it saves money but removes rep autonomy, sales will feel like it lost a tool.

The winning replacement needs to preserve the surface area reps expect while giving the business more control underneath.

The replacement architecture

The cleanest way to replace ZoomInfo is to separate the old product into layers.

The rep experiences a familiar UI to run any sales play they want.

RevOps gets to design those sales plays and iterate them with feedback.

That is the unlock.

Share

How it works

What we’ve learned from migrations

1. Data quality is important, but data validity is the better frame.

“More data” is not always the goal.

Savvy GTM teams are asking:

• Did we find a usable email?

• Did we validate it?

• Did the phone connect?

• Did the record land in the right account?

• Did we avoid a duplicate?

• Did the rep get to the next action faster?

This matters because ZoomInfo can still be strong in certain slices, especially North American phone data. You should be honest about that.

Do not walk into the replacement project with a religious argument.

Run the test.

Take 200 to 500 representative contacts across your key segments and regions. Include known-good contacts, stale CRM contacts, newly hired prospects, small companies, large enterprises, and the regions where your reps complain most about coverage.

Compare valid email coverage, mobile/direct-dial coverage, connect rate, bounce rate, CRM match rate, duplicate rate, cost per usable contact, and time from selection to sequence.

The winning system is not the one that fills the most cells.

The winning system is the one that creates the most usable downstream records.

2. CRM sync is harder than it looks.

Almost every buyer eventually gets to the same question:

Can my reps get this person from the web into my CRM without creating a mess?

This is where Clay and Exportly should win.

Because the export passes through Clay first, the team can define real business logic before the record touches CRM:

• Match to the correct account.

• Check whether the person already exists as a lead or contact.

• Decide whether to create, update, or block the action.

• Respect do-not-contact status.

• Prevent protected field overwrites.

• Add the right source, sequence, owner, territory, creator, and timestamp.

• Route to Salesforce or HubSpot first, then to the sales engagement tool.

That is not just enrichment.

That is GTM infrastructure.

3. You do not need a big-bang migration.

One of the strongest ideas from teams already moving from ZoomInfo to Clay is this:

You can start before the ZoomInfo contract ends.

If you still have ZoomInfo access, use it during the transition. In many setups, ZoomInfo data can be pulled into Clay while Clay starts doing what it does best: enriching gaps, validating records, running alternate waterfalls, and writing clean updates back into Salesforce or HubSpot.

Instead of:

We are turning off ZoomInfo and hoping the new workflow works.

You get:

We are running both systems in parallel, measuring where Clay adds coverage, and gradually moving reps onto the better workflow.

Parallel migration is how you turn a scary replacement into a measured rollout.

The 30-day migration playbook

Before you build anything, find the contract.

TIP: ZoomInfo is notorious for having different non-renewal notification dates than others. They’re usually 2 months in advance, and non-forgiving if you miss it.

You need the renewal date, cancellation notice window, required notice format, current seat count, paid modules, data export rules, and API access. Set reminders well before the notice deadline. The migration clock starts months before the contract ends.

Then compress the rollout into five moves:

1. Audit the real usage

Do not start with vendor comparison. Start with behavior.

Which teams use ZoomInfo? How much usage is Chrome extension lookup? How much usage is list building? Which destinations matter? Which workflows must exist on day one?

Most teams find the replacement surface is smaller than the contract surface.

That is good news.

2. Build the benchmark

Run the same representative records through ZoomInfo and your Clay waterfalls.

Measure the outputs that matter: valid email, connected phone, CRM match, duplicate avoided, record sequenced, and cost per usable record.

Use the results to create a one-page business case:

• Where ZoomInfo still wins

• Where Clay plus Exportly wins

• Recommended rollout path

3. Pilot with champions, make them heroes

Pick a small group: a few power users, one manager, one RevOps owner, and one Clay/admin owner. Ideally the sellers are some of your top performers. This makes it much easier to ‘sell’ to the rest of the team and highlight them as examples.

Give them a narrow job:

Use Exportly instead of ZoomInfo for the core daily workflow for 5 business days.

Track active usage, enrichments, successful CRM writes, duplicate rate, sequence adds, credit usage, valid email rate, phone coverage, and rep feedback.

4. Incorporate feedback & ship new workflows

Make the reps feel part of the process. Include them in iteration process of building custom workflows that they help design.

Make sure the champion group is super happy before moving to the next group.

The best outcomes happen when you provide workflows that weren’t possible before. The system becomes more exciting and viewed more than just a replacement.

You’ll probably want another 5 business days of testing and iteration.

5. Roll out sequentially to other teams

Include enablement and ops as part of the process.

Keep building trust with reps as you roll-out Exportly from group to group.

Also realize that different teams will have different workflow needs. Enterprise sellers work uniquely compared to velocity/SMB reps.

Subscribe now

The objections

“ZoomInfo has great phone data.”

Sometimes it does, especially in North America.

So test it. Build regional waterfalls. Tune provider order. Compare by segment. If needed, keep a fallback for a specific use case while you migrate the broader workflow.

The honest answer builds trust.

“Reps will not use Clay.”

Correct.

Most reps should not have to.

Clay is the builder interface.

Exportly is the seller interface.

“Credits will get out of control.”

They can if you do not design controls.

Use export limits, table limits, waterfall skips, and reporting.

Good credit governance is one of the benefits of moving to Clay.

Legacy to modern

ZoomInfo belongs to the old GTM tooling era:

One vendor. One database. One interface. One set of product decisions applied to every customer.

Clay and Exportly belong to the new GTM engineering era:

Composable data. Programmable workflows. Company-specific logic. Continuous optimization.

Once the data layer is programmable and the rep interface can surface any approved workflow, the sales team is no longer limited to “get phone” and “export contact.”

You can give reps buttons like:

• Find the buying committee for this account.

• Check whether this person matches our ICP.

• Refresh this stale Salesforce contact.

• Find lookalike companies.

• Pull recent hiring signals.

That is the real reason to replace ZoomInfo.

Not just to lower cost.

Not just to improve data.

But to turn a static lookup tool into a programmable GTM system.

The bottom line

ZoomInfo gave sales teams an interface to query a database.

That interface gave reps autonomy.

But the next generation of GTM teams need more than a database with a few static workflows layered on top. They need an interface connected to their own logic, their own CRM rules, their own waterfalls, their own ICP, their own territories, and their own plays.

That is what Clay and Exportly make possible.

The goal is not to rebuild ZoomInfo.

The goal is to replace it with something more programmable.

Whoever owns the workflow owns the GTM system.

Get started with Exportly: www.exportly.ai

Get started with Clay: www.clay.com

Subscribe now

GTM Engineering jobs of the week

Equinix is hiring 3 different types of GTM Engineers.

What makes Equinix interesting?

You're at the epicenter of the AI infrastructure wave

Equinix is in the early chapters of what they describe as a multiyear infrastructure investment cycle — arguing that just like the internet three decades ago, AI is a catalyst for a fundamentally new approach to how enterprises connect and orchestrate technology workloads. The financials back it up. Q1 2026 revenues hit $2.44 billion, a 10% increase year-over-year, with operating income up 26%, and the 2026 outlook projects revenue between $10.1–10.2 billion with margin expansion.

The AI product surface is expanding fast

In September 2025, Equinix unveiled its Distributed AI infrastructure solution — including a new AI-ready backbone, a global AI Solutions Lab, and Equinix Fabric Intelligence to support inferencing workloads — with key partnerships spanning Adobe, Dell, Groq, HPE, NVIDIA, Zayo, and Zoom. If you work in solutions, engineering, partnerships, or GTM, you're selling and building something that didn't exist two years ago.

GTM Engineer: Revenue Acceleration [$136k - $245k]

Responsibilities mentioned:

• Build deal signal detection and next-best-action systems that surface the right insight for AEs at the right moment in the deal cycle, from early qualification through close

• Serve as the builder for ideas that originate in the field -- when sellers, marketers, or customer success managers identify an opportunity but lack the technical depth to execute on it, you turn their insight into a production-ready solution on their behalf

• Run data-driven experiments on GTM workflows and automations, measure impact against pipeline and conversion metrics, and scale what works into durable infrastructure

GTM Engineer: Pipeline and Revenue Generation [$136k - $245k]

Responsibilities mentioned:

• Build AI-powered prospecting and outbound personalization systems that help SDRs engage the right accounts at the right time, without the manual research overhead

• Develop intelligent inbound lead scoring, routing, and response automation that reduces friction between a prospect’s first signal and their first conversation with a rep

GTM Engineer: Customer Experience & Lifecycle [$136k - $245k]

Responsibilities mentioned:

• Develop onboarding and adoption automation that accelerates time-to-value for new customers and reduces manual coordination across Customer Success and delivery teams

• Create intelligent support routing, case deflection, and delivery workflow automation that frees teams from administrative overhead and surfaces escalation risks before they become problems

Newsletter recommendation of the week

The AI Leadership Edge

AI leadership insights and tools for Leaders, GPs and Boards. Make AI your advantage. Turn capital into outcomes.

Most of the time - I have no idea what model to use. The subtitle on the model selection says ‘complex reasoning’. But what does that even mean?

Many of us default to the most powerful model for most tasks. There’s no incentive not to. It’s not problem yet, but it will be soon.

Think about what that means at scale. Anthropic’s flagship model costs roughly 15x more per token than its smallest one. A rep summarizing a call transcript doesn’t need the flagship. Neither does a workflow that formats CRM notes or drafts a follow-up email. But nobody told them that, there’s no system enforcing it, and nobody’s measuring the difference. Across a 200-person GTM org running AI workflows all day, that adds up to a real budget line nobody owns yet.

This is just one problem with AI adoption on GTM teams.

AI skill sprawl is another one. Lack of centralization is another, and the larger one is how inconsistent AI usage is and varied due to a wide spectrum of individual fluency.

I’ve been thinking about this problem for awhile. Then was introduced to Tessl, a company founded by Guy Podjarny. He also started Snyk (a cybersecurity unicorn where I used to work).

Tessl is a management layer that turns risky, sprawling, invisible skills into a governed, measurable system. They argue there’s 3 questions that every AI native team need to answer:

1. Security & governance - if a risky skill ran in your environment, would you even know?

2. Standardization & reuse - how much are duplicate, outdated skills costing your team?

3. Continuous optimization - your agents have the skills, but are they actually using them?

There’s a lot more to AI skills to unpack than I realized.

Skills are a new unit of software.

This has many implications for security, governance, and so on. But at a basic level, they’re building a product I believe will become a default layer of everyone’s GTM stack and approach to adopting, scaling, and using AI effectively across the org.

This is one symptom of a bigger problem: GTM teams are building AI skills with zero infrastructure underneath them. And we’ve seen this exact movie before.

Subscribe now

A skill marketplace will solve for more than just cost and a single source to find your organizations built skills. But let’s dive into the cost problem first.

A parallel to cloud computing

In the early cloud days, every engineer could spin up whatever compute they wanted. It felt like freedom. Then the bills arrived, and an entire discipline — FinOps — was invented to clean up the mess. It still hasn’t fully worked: Flexera’s 2025 State of the Cloud Report found that 27% of cloud spend is wasted, a number that’s barely moved since 2019. At a $675B global cloud market, that’s roughly $180B a year evaporating into idle instances and over-provisioned resources.

Flexera’s own analysts drew the line to what’s next: just as early cloud usage produced unwieldy costs, AI spend is following the same arc — and “FinOps for AI” is already forming as a category to deal with it.

Most GTM leaders haven’t connected this yet: Skills, not infrastructure, decide what AI costs in your org. The prompts, instructions, and workflows your team feeds to Claude, ChatGPT, and your agents determine which model runs, how many tokens burn, and whether the output is even usable. Skills are the unit where cost, quality, and security all get decided. And right now, in almost every GTM org I see, skills are markdown files living in someone’s Slack DMs.

The wild west of AI exploration

The cost problem is the visible one. There are three quieter problems compounding underneath it.

Nobody is testing anything.

Software engineers learned long ago that untested code is broken code — you just don’t know it yet. The dev world is already applying this to AI: Tessl runs task-based evaluations on agent skills and found that evaluated, optimized context produced up to 3.3x improvement in agents using APIs correctly. Now ask yourself: who in your GTM org has ever run an eval on a prospecting skill? On an account research prompt? Anyone? In GTM, “testing” a skill means one person ran it twice and it seemed fine. We’re shipping un-evaluated skills to entire sales teams and wondering why output quality is inconsistent.

Everyone gets different outputs.

When ten reps each write their own version of “research this account before my call,” you get ten different research standards walking into ten different meetings. The whole point of GTM engineering is building systems that make the team’s floor higher than any individual’s ceiling. Unversioned, unshared skills do the opposite — your output quality becomes a lottery based on who happened to write the best prompt.

Everyone is rebuilding the same thing.

I see this constantly. Someone builds a great ICP-scoring skill. Three weeks later, someone two pods over builds a worse version of the same thing because they didn’t know the first one existed. In software, we solved this with package managers — npm, pip — so nobody rewrites a date-parsing library from scratch. GTM has no equivalent. Good work doesn’t travel; it just gets duplicated, badly.

Your team needs an AI skill marketplace

This is the thesis: every company is going to need an internal marketplace for AI skills — a governed, versioned, measurable registry — the same way every company eventually needed a package manager, a CI pipeline, and a FinOps function.

Why?

There’s a structural paradox at the center of modern GTM teams: the gap between what the best rep on the team knows how to do and what the average rep actually does is enormous — and it’s getting wider as AI tooling proliferates.

Tacit knowledge — intuitive skills learned through first-hand practice — is the hardest type to capture and scale. The best practices and tricks that high performers develop through years of customer interactions live inside those individuals, not inside any system. The enablement challenge is codifying that expertise and sharing it across the team.

Meanwhile, AI has made the technical surface area of GTM work dramatically larger. While 81% of sales teams are experimenting with AI, only 26% can scale it beyond pilot programs to generate real ROI. McKinsey reports that 60–70% of tasks performed by sales reps are technically automatable — but the gap between potential and performance is an operator problem.

This is the structural need for an “internal skills marketplace” that addresses: not a training catalog, but a living library of executable workflows that any rep or operator can pull from and deploy.

The skills gap is quietly widening

92% of sales professionals already use AI in some form, yet 84% say the main benefit is saving time or optimizing processes. That’s table stakes. The reps pulling ahead have moved past time savings into genuine competitive advantage. The gap comes down to AI fluency, not tool access. The top skills that separate them are prompt engineering, AI output verification, and data literacy. These are almost certainly the ones most companies ignore.

Is anyone building this right now?

The dev world is building this right now. Tessl is essentially npm for agent skills: install skills as versioned dependencies, track them in a manifest, run evals before they ship, scan them for security issues, and push updates across the whole team instead of copying markdown files between repos. The framing they use is the right one — skills are software, and software needs a lifecycle.

Skills are the new code

GTM should steal this wholesale.

Here’s the minimum viable version:

• A single source of truth. One repo (or Notion database, or shared directory — the tool matters less than the discipline) where every team skill lives. If a skill isn’t in the registry, it doesn’t exist. Kill the Slack-DM distribution model.

• An owner per skill. Every skill gets a named maintainer responsible for updates when the underlying tool, model, or playbook changes. Orphaned skills are how you end up with reps running a six-month-old prompt built for a model that’s been deprecated.

• A model recommendation baked into every skill. This is the cheapest fix with the biggest cost impact. Each skill should declare which model tier it needs: fast-and-cheap for summarization and formatting, mid-tier for drafting, flagship only for genuinely hard reasoning. Most GTM skills don’t need the flagship — saying so explicitly, inside the skill itself, beats sending anyone a memo about token budgets.

• Lightweight evals before anything ships team-wide. You don’t need an eval platform to start. Take 10 real inputs — 10 actual accounts, 10 real transcripts — run the skill against all of them, and have the skill’s owner grade the outputs against a simple rubric. If it can’t pass that, it’s not ready for 50 reps. This one habit alone puts you ahead of nearly every GTM org I’ve seen.

• Versioning, even if it’s crude. v1, v2, v3 in the filename beats nothing. When a skill gets improved, the team adopts the improvement automatically — not whichever copy they happened to save. This is also how messaging changes ship: update the pitch skill once, and the whole team is running the new play tomorrow instead of next quarter.

What drives better outputs (relative to cost): context or model?

Tessl used it’s platform to answer this question by comparing Claude Fable 5 vs Opus 4.8 within the context of skills.

It’s a great example of why all of this matters.

Every scenario in the evaluation is a real agent task tied to a published skill, scored on two axes: instruction-following (does the agent do what it was told, in the way it was told) and task-completion (does it reach the goal). The overall score weights instruction-following at 4 and task-completion at 3, then divides by 7. Each task runs with and without the skill, so the lift from the skill is visible directly. The tasks and skills are public, in the task-evals-for-skills dataset, so you can inspect any scenario yourself.

This design is deliberate. The tasks come from published skills, so they mirror the real work teams write skills for, not frontier puzzles meant to find a model’s ceiling. That is why task-completion runs high for both models and why the signal that separates them is instruction-following: doing the work the specific way the skill asks. — from “Claude Fable 5 vs Opus 4.8: The Mythos Hype Meets Reality”

How a skill marketplace helps your team

The registry is the infrastructure. The value shows up in three places — and conveniently, they map to the three people who need to approve this.

For your VP Sales: day-one rep ramp.

Today, a new rep spends their first month reverse-engineering how the best people on the team work — shadowing calls, begging for prompt screenshots, slowly assembling their own janky toolkit. With a skill registry, day one looks different: the new rep gets the full team loadout auto-installed. The account research skill, the call prep skill, the follow-up writer — all the same versions your top performer runs. Ramp time has always been gated by how fast knowledge transfers from senior reps to new ones. A skill registry turns that transfer from months of osmosis into a download.

For your CRO: top-performer extraction.

Every team has one rep whose call prep is unreasonably good. Right now, that advantage retires when they do. Turn their process into a skill, eval it, publish it, and their edge becomes the team’s floor. This is the highest-ROI knowledge management most GTM orgs will ever do, and almost nobody is doing it.

For your CFO and legal team: governance by default.

Model recommendations baked into skills fix the default-to-expensive problem without policing anyone. And legal approves the claims in the outreach skill once, instead of auditing a thousand freelanced prompts after a rep promises something the product doesn’t do. For regulated industries, this is the only realistic way to let reps use AI at all.

The companies that built FinOps muscle early saved millions while their competitors argued about whose AWS bill it was. The same window is open right now for AI skills in GTM — and it’s wide open, because almost nobody is doing this yet. The first RevOps or GTM engineering leader at your company to stand up a skill registry will cut model spend. They’ll also end up owning rep ramp, playbook velocity, and the layer where every AI workflow in the org gets built.

The biggest impact?

Everyone operating at a higher level of execution with the same sharpened tool set.

Share

Subscribe for upcoming content:

1. How to replace ZoomInfo with Clay

2. Marketing use cases with Clay you’ve never heard of

3. How to do context engineering in Clay (or for any agent) to get better outputs

4. GTM Engineering Benchmarks

Subscribe now

Subscribe now

A phone carrier for agents?

No, this isn’t a post about building AI Cold Callers.

It’s post about infrastructure for agents and why it matters.

Last week I sat down with Idan Bier, Founder of Saperly. He’s building phone infrastructure for agents. , GP of Boldstart.vc, introduced us. I’ve made a habit to take introductions. One led to my first angel investment. Another resulted in using Clay before it got popular, and then working there.

Last week, the CEO of Cloudflare also announced bots surpassed human traffic for the first time in internet history.

Bots aren’t necessarily all agents. But we know the trend will only continue in one direction.

I keep thinking about one thing that Idan said:

We as humans — we have these boring primitives we carry around for years. Our email address. Our phone number. Our ID. We need to rebuild all of that for agents.

As agents take on more types of human work, they need new infrastructure to become actors in real world.

Here’s one example - 2FA (two factor authentication). It’s often done via SMS. That’s just one use case where a phone numbers comes into play. A phone number is a way to confirm identity.

There’s many more use cases for phones and types of primitives that agents will need:

• Email

• Wallet

• Memory

• Legal identity

• Reputation?

The boring primitives are about to become very interesting infrastructure.

Subscribe now

What primitives do agents need?

First, what’s a primitive?

Primitives are your basic building blocks. You combine them to build something more complex.

These are primitives agents will need:

Email — mostly solved. AgentMail raised $6M in March to build dedicated agent inboxes with API-layer permissioning. Email is infinite and cheap, so the engineering problem was always tractable.

Agents you can clone on AgentMail:

Phone number — in active build-out. Unlike email, phone numbers are a finite, government-regulated asset. Getting real carrier-grade numbers (the kind banks and WhatsApp trust) means building partnerships country by country. Whoever locks up those carrier relationships first holds a moat that can’t be replicated with code. That’s what Saperly is building.

Wallet / payments — in active build-out. Mastercard Agent Pay launched April 2025. Visa’s Trusted Agent Protocol launched October 2025. In February 2026, Coinbase launched Agentic Wallets. In May 2026, AWS + Coinbase + Stripe shipped stablecoin payment rails for agents. The rails are real. The volume is still small — ~$73M settled — but the infrastructure is production-grade.

Memory — being worked on but not there yet. Most agents reset completely between sessions. Mem0 raised $24M in October 2025 to build persistent memory infrastructure. Memory layers that cut token costs by 90% now exist.

Production chatbots live or die by how well they remember. Users expect an assistant that can recall past preferences, ongoing tasks, and previous mistakes, even across sessions and devices. Traditional prompt engineering and longer context windows help only for a while, then costs and latency start to dominate.

How memory works in AI chat bots

Reputation / credit history — almost nonexistent. A new agent looks identical to a malicious one. Skyfire is building verifiable track records for agents — essentially credit scores. Nascent, but the problem gets loud as agent-to-agent commerce scales.

Legal personhood — the frontier. An agent can negotiate a contract but can’t be party to one. A company called ClawBank made news when their agent, Manfred, independently filed for a U.S. LLC and received an EIN — reportedly the first known case.

The hierarchy of primitives that emerges

Why phone is the hardest primitive to replicate

Email infrastructure companies like AgentMail are building the email layer — email and phone-call infrastructure for AI agents, enabling them to send and receive real email and text messages, and place agent-driven outbound voice calls, all programmatically. That problem is solvable. Email addresses are cheap, scalable, and don’t require carrier relationships in 40 countries.

Phone is different. The $2 trillion global telecom industry was built for humans. Agents can’t act in the real world today because without a phone number, they lack identity.

There are two kinds of phone numbers in circulation:

1. Virtual numbers — easy to get, used for OTP flows, disposable, no real identity behind them.

2. “Aged” numbers — numbers tied to real carrier records, trusted by platforms like WhatsApp, Meta, and banking apps, capable of being used for sustained identity and inbound/outbound calling.

Getting the second kind globally is genuinely hard. You need carrier partnerships in each country. You need to navigate each national regulator’s allocation process. You need to build trust with each provider before they’ll give you real number blocks. And once you have that allocation? You’re holding a hard asset.

Every country you unlock, every carrier relationship you build, every batch of real numbers you secure — the moat gets wider. A competitor can’t just catch up by writing more code.

Using a phone agent in GTM

At first, I could only envision the support line use case.

Turns out there’s many more:

Pricing research calls Idan mentioned this in the conversation: calling a vendor, spa, or service provider that doesn't publish pricing online. Agent calls, asks, logs the answer. Competitive intelligence at scale — imagine running this across every competitor's reseller network or every vendor in a category weekly.

Inbound support lines. Customer support platforms need real phone numbers so their AI can receive calls — not just chat messages. A customer calling a number shouldn’t know or care if they’re talking to an agent; they just need to reach someone who can help.

WhatsApp / Meta / Instagram presence. Real carrier-grade numbers can be registered on WhatsApp Business, Meta platforms, and others. Virtual or VoIP numbers typically can't. Agents with a real number can operate as a recognized entity inside messaging platforms where billions of business conversations happen.

Outbound call automation. No, not cold callings. Think: agents calling vendors to book appointments, confirm appointments, or inquiring where a shipment might be.

Agents operating inside businesses at scale. The more interesting case: companies like HoneyBook (CRM for small businesses) want to deploy agents inside their customers’ businesses. Each of those businesses may need its own number. That’s not a single deployment — it’s a franchise-scale provisioning problem.

Real-world agentic workflows. We were literally sketching a demo on the spot where you SMS a LinkedIn URL to a number → it triggers a Clay enrichment waterfall → the phone number comes back as an SMS to the rep. Total build time: maybe twenty minutes. The “SMS as interface” pattern is underrated for reps who won’t log into another tool but will absolutely text a number.

More on this one below…

Multi-factor authentication for agent-controlled accounts Agent accounts on SaaS platforms, banks, and services often require phone verification to set up and to reset credentials. Without a stable number, the agent can't maintain these accounts autonomously.

Government / regulatory data extraction Calling agencies or departments that only share information via phone — the kind of data that can't be scraped. Think permitting offices, court clerks, licensing boards. Agent calls, gets the information, logs it.

Reference check automation Agent calls references on behalf of a hiring team or a due diligence process. Structured questions, consistent scoring, logged transcript.

Vendor / supplier outreach Agent calls vendors to check inventory, confirm lead times, get quotes, or negotiate terms. Especially powerful for companies managing complex supplier relationships where the information doesn’t live in a database.

Building Clayline - enrichment via SMS

Idan and I came up with the idea as we were walking out of the meeting.

Later that day, he slacked me over a video of the MVP working.

This is the scenario - you’re a rep on the road and looking up LinkedIn profiles like you normally do for research. Let’s say you need the prospects phone number.

Share the LinkedIn profile, choose SMS, Clayline (saved in your contacts), text it over and a few seconds later you receive the person’s phone number.

You could create a similar workflow to update Salesforce via SMS.

Agent primitives market map

Working on this now…

Know of a company that should be included?

I’m looking for primitives like the ones we talked about above.

Think services for agents that give agents new powers in the real world.

Drop a comment with the company I should look into.

Leave a comment

Subscribe

AI Agents broke the SaaS delivery model.

a16z put it perfectly:

Enterprises buying AI are like your grandma getting an iPhone. They want to use it. They just need someone to set it up.

We see this at Clay, too. Customers need help to figure out how to take existing business context, workflows that aren’t well documented, and then integrate AI into it all.

That’s why Clay is building a Forward Deployed GTM Engineering team and we’re not alone.

Hundreds of companies from Salesforce to seed stage AI startups are hiring Forward Deployed Engineers. Job openings have ballooned this year (see chart below).

OpenAI even launched The OpenAI Deployment Company (aka DeployCo) to scale their implementations.

Google, too:

Why?

SaaS products are fairly straightforward.

AI products? Another story… there’s more complexity, customization (infinite?), and building solutions into companies existing workflows.

Current AI capabilities require significant customization to deliver reliable business outcomes. This is particularly evident in enterprise deployments where data variability is extreme, workflow complexity is high, and performance standards are unforgiving. Consider the difference between a consumer chatbot that provides “helpful” responses and an enterprise legal assistant that must flag compliance risks with 99%+ accuracy. - Foundation Capital

There’s a trend here in how AI is changing how companies develop an bring products to market.

• First - AI gives software engineers superpowers to 100x their output for software development.

• Next - The GTM Engineer role is born to rethink GTM with AI to bring products to market more effectively and to grow faster.

• Now - The final leg is getting AI into production.

That’s where the Forward Deployed Engineer (FDE) comes in.

Is the role just a glorified consultant with shiny name to attract talent & excitement?

This all led me down a research rabbit hole:

• What is the origin story of the FDE?

• How did it develop?

• Who’s hiring this new role?

• What are the ‘jobs to be done’?

• How much are they getting paid

• What are employees looking for in candidates?

• What does all of this mean for our new era of GTM?

These are all great questions to answer by sourcing and analyzing job data within Clay.

In this post, I aim to answer the above questions.

If you’re building in AI, you’ll want to read this deep dive.

Rise of the Forward Deployed Engineer

Software is no longer aiding the worker — software is the worker. Software doesn’t need the same graphical user interface on top of a database to operate; it can autonomously complete tasks end-to-end. But as those tasks get more complex, fulfilling them becomes more challenging. For AI agents to truly be on par with human workers, companies will need expert services to redesign job functions and processes around this new approach. Without hands-on implementation support, AI risks falling short of the standards set by a dedicated employee. With the right support, however, agents can take on a more holistic role, unlocking far greater business value than basic task automation ever could. - a16z

Origin story at Palantir

It started with a problem no one had solved before.

In September 2001, the US intelligence community had more data than it had ever collected in its history. It had analysts who were extraordinarily skilled at interpreting fragments of information. What it did not have was the ability to make those two things talk to each other. The CIA had its systems. The NSA had its systems. The FBI had its systems. None of them could see what the others were seeing.

Palantir was founded to solve that specific problem. But they ran into a wall immediately.

The founders faced a significant hurdle: they didn’t know any spies, and even if they did, those individuals couldn’t disclose the details of their work. There were no clear requirements, no proper feedback loops, no user interviews possible. Traditional product development was useless.

So Palantir did something unusual. Instead of asking customers what they wanted, it put engineers directly inside customer environments. These engineers learned by observing, experimenting and building in real time. That decision resulted in the forward-deployed engineer model. What began as a necessity later became a great strategy.

The name came from the military.

The phrase “forward deployed engineering” has its roots in military operations — forward-deployed forces — and Palantir popularized it in the late 2000s, largely because they were working with defense contractors and government agencies. They were already speaking the language of their customers. The title followed the culture.

The internal team structure was unusual.

Palantir didn’t send lone engineers into the field. They built a two-team model with distinct roles:

Echo teams were domain experts, often from the same industries as the customers — military, healthcare, or finance. Their role was to understand real problems, see where technology could create value, and serve as a bridge between the customer and engineering teams. Delta teams were execution-focused engineers who built solutions fast, prioritizing speed and impact over perfect design. Together they functioned as a mini startup within each client environment. Palantir’s own framing was precise: “A Dev’s focus is one capability for many customers, while a Delta’s focus is many capabilities for one customer.”

The feedback loop is how Foundry was born.

The FDE model had a mechanism that made it fundamentally different from consulting — what insiders called the “gravel road to paved highway” loop.

FDEs on-site lay down a “gravel road” with code and custom solutions to address immediate needs. Meanwhile, the product and engineering teams at headquarters observe this road and figure out how to upgrade it into a “paved highway” that can serve the next ten or twenty customers.

The core elements of what became Foundry were first developed in places as far-flung as Zurich and Houston, São Paulo and Toulouse, Westport and Baku. They were born of necessity, because small teams wanted to fix a problem, with cost, compatibility, or cohesion as only secondary concerns. Customer deployments were proving grounds for new technologies — those that worked were migrated toward the core, while FDEs fanned out in search of the next frontier problems. In 2014, at Palantir’s annual “Hobbitcon” conference, the stated product strategy was literally “strong opinions, weakly held” — basically throwing things at a wall and seeing what stuck. And this happened entirely bottoms-up.

The 4 waves of Forward Deployed Engineers

The FDE model didn’t go from Palantir to everywhere overnight. It moved in waves — each one triggered by the same underlying problem hitting a new sector.

Wave 1 (2003–2018): Just Palantir. Intelligence agencies with classified workflows, no clear requirements, and no way to do user interviews. You couldn’t ask the CIA what it needed. So Palantir put engineers inside and had them figure it out. The rest of the industry called it unscalable and moved on.

Wave 2 (2018–2022): Data infrastructure. Scale AI, C3.ai, Databricks, Snowflake. Complex deployments, large contracts, environments where a generic implementation was useless. You can’t produce useful training data without understanding the customer’s specific data architecture. You can’t deploy a data lakehouse without touching every legacy system in the org. The FDE model spread to anyone selling infrastructure that required judgment, not just configuration.

Wave 3 (2021–2024): Enterprise SaaS. Intercom, Rippling, Stripe, Datadog. These weren’t AI companies. They had well-documented products and large CS teams. Didn’t matter. Enterprise customers stopped buying point solutions and started demanding platform integrations. The implementation surface exploded faster than anyone could document it.

Wave 4 (2024–present): Everything. MIT found 95% of enterprise AI pilots return nothing. RAND puts AI project failure rates above 80%. The bottleneck isn’t the model. It’s the last mile — the legacy ETL, the undocumented workflow, the compliance constraint no one wrote down because the person who handled it never thought of it as a process.

Every wave happened for the same reason: a product hit a deployment problem so complex that no support ticket could solve it. The only fix was putting an engineer in the room.

AI just made that problem universal.

How is this panning out in 2026?

Chart: ‘26 Growth of US FDE Job Openings

I pulled job data in Clay for 2026 (this was a pull mid-May, so May numbers are likely even higher) and deduped by companies to find how many unique companies are hiring.

The actual number of open roles is much larger. For example, Salesforce alone has committed to hiring 1,000. Clay has multiple offerings.

Forward Deployed Engineering at Clay

Clay’s Forward Deployed GTMEs will be focused on:

• Translating business requirements to Clay builds

• Building Clay GTM systems

• Integrating Clay with internal tooling

• Bringing feedback from customers back to our product team

• Building agents & writing/tuning prompts

In Q1, I spent a large portion of my time forward deployed with a couple of customers. One even invited me to give a prompt engineering crash course to their entire marketing team. 100+ marketers showed up.

I went deeper with this customer, even spending an hour a day for several weeks supporting them. This was over top compared to what we normally do (especially since pre-sales usually disappears after the contract is closed and the Growth Strategist takes over as CSM.) The time investment accelerated everything:

• Strength of the customer relationship

• Deployment of Clay and their skills

• Introduction to more teams and stakeholders

• Understanding of their business & nuances

• Roadmap of new use cases to be deployed

Foundation Capital put it plainly: forward-deployed engineers have become “one of the most strategic assets in enterprise AI companies.”

What are Forward Deployed Engineers’ responsibilities?

In the same Clay table, I set up a Claygent column that takes the job posting URL as an input and then deploys the research agent to read & analyze each post. The output is a summary of responsibilities and requirements of the role. Then back to Sculptor to analyze all data in the table for a statistical analysis.

The most common responsibilities clustered around 3 motions.

Building customer-specific integrations

40% of postings. This is the nuts-and-bolts work — connecting the product to the customer’s data warehouse, CRM, identity provider, or the legacy system that hasn’t had an API since 2009.

Translating business requirements into technical architecture

30% of postings. The customer knows what outcome they want. They don’t know how to spec it. The FDE sits in the discovery call, hears “we want AI to handle our tier-1 support tickets,” and leaves with a technical architecture document.

Owning end-to-end delivery

25% of postings. Not handing off to a services team. Not filing a ticket. Shipping it, watching it break, fixing it, and making it stable enough to hand back.

Here’s why this is hard. Emergence Capital identified the core problem: most companies think they’ve documented their business logic in SOPs and process guides. But those documents are “corporate fiction: static, incomplete, and often wildly outdated.” AI systems need to internalize how work actually gets done — not the idealized version written in the wiki three years ago. FDEs extract that real-world knowledge directly, on-site, by watching and building.

FDEs contribute throughout the lifecycle of numerous organizations, including the initial evaluation and proof-of-concept phases up to the actual deployment and optimization. - FDE Academy

What are the job requirements for Forward Deployed Engineers?

40% of Forward Deployed Engineer job postings now require AI/LLM experience.

Eighteen months ago that number was near zero.

Traditional FDE job descriptions asked for Python, REST APIs, and cloud deployment experience. That’s still the baseline — 55% of postings require Python or TypeScript, 50% require REST API experience.

But 40% now require retrieval-augmented generation, prompt engineering in production, and debugging agentic workflows at customer sites. That’s a different job than integrating an API.

Joe Schmidt at a16z framed the shift precisely: in the current era:

Software is no longer aiding the worker — software IS the worker.

When that’s true, deploying software means deploying a worker. And you wouldn’t onboard a new employee with a Loom video and a support ticket.

Sarah Khalid, an FDE Director at Salesforce, described what’s changed technically: the agentic platform, she said, “is not quite as black-and-white as coding. It’s a little bit more art and not as deterministic.” That non-determinism is exactly why you need an engineer on-site. When the agent does something unexpected in a customer’s production environment, someone has to diagnose it in real time — not file a bug report.

This is why the FDE role is expanding so fast. Every company selling AI agents is discovering the same thing: the product can do what it says it can do. Getting it to do that inside the customer’s environment is a completely different problem.

How much do Forward Deployed Engineers get paid?

Minimum salaries range from $80K-$100K at the typical floor. Maximum salaries run $250K-$325K at the top of the market, with outliers reaching $400K at principal/staff level.

That’s a $170K gap between where the role starts and where it maxes out.

The reason: 60% of postings require 3-5 years of engineering experience. 45% require demonstrated customer-facing skills. That combination is genuinely scarce. You’re not hiring one discipline — you’re hiring two.

Salesforce’s hiring approach captures it well. Ben Kracker, FDE Director there, described what they actually look for: “problem-solving is the number one skill an FDE needs to have.” Not coding fluency. Not account management experience. Problem-solving — specifically in situations where the customer “does not know what they do not know.” That’s the judgment premium the salary gap is paying for.

Salesforce tripled its FDE team in six months and built a six-week onboarding program to support it.

What’s the difference between CSM, TAM, and FDE?

What this means for AI product GTM?

When every company can ship the same primitives using the same models, what you build is no longer your moat. How you integrate, embed, and operate becomes the moat. - Foundation Capital

Ramp’s engineering team, which built one of the most documented FDE functions in the market, found that enterprise-focused B2B companies grow at a CAGR of 29.6% vs 15.2% for non-enterprise peers. The FDE function is part of how you earn the right to be in that cohort — by deploying reliably enough that customers expand rather than churn.

If you’re a founder

The FDE function is not optional at enterprise. Budget for it before you feel the pain — by the time you feel it, you’ve already lost the renewal.

If you’re a GTM leader

Start mapping which accounts have deployment complexity that exceeds what your CSM can handle. Those are your FDE candidates. The metric is simple — if solving the customer’s problem requires writing code, your CSM isn’t the right person in the room.

If you’re an engineer

The FDE path is one of the highest-leverage roles in the current market. The $170K salary ceiling isn’t a ceiling for long — it’s a floor for the engineers who figure out how to do this at scale.

The companies that get to production fastest will win the renewal. Whoever deploys best, builds the moat.

Subscribe

It’s been awhile since my last post.

Going from 1 to 2 kids is no joke.

Good news is I’m back at it and starting with a rebrand of Claymation.io.

I’m going from this…

To this: GTM/Engineering

There’s still plenty of tweaks and polish to be applied, so let me know if you see anything out of place.

This will be more than a newsletter and have bunch of additions that’ll be coming, too:

• Prompt library to share what I’ve developed over the last 2 years at Clay

• Automation & workflow guides from my builds

• Claude skill repo to maximize your productivity

• Job board to help you find the next gig

• Resources to help you with your career, AI transformation, and bringing GTM Engineering into your company

So, why the change?

A project earlier this year changed how I think about GTM Engineering.

Now it wasn’t a workflow or new GTM play.

I built a territory command application on top of Clay, which aggregated 1st and 3rd party data, sync’d to Supabase and then used Lovable to vibe code the front-end app.

I then build all sorts of ‘skills’ and workflows on top of the data:

• 1 click ABM landing pages

• 1 click value pyramid generation

• 1 click messaging generation for each level of seniority

• Org chart builder

• Trip planner that suggests who to see when I visit a city

• Prospecting email generation

• Views and insights of all users at my accounts

• and the list goes on…

That’s when it clicked: Clay isn’t a tool anymore.

Clay has become an infrastructure layer for GTM.

And if that was true, then claymation.io, a newsletter about how to build workflows in Clay, was the wrong newsletter for the world I’m living in and hoping to shape.

How we got here

When I started claymation.io, my goal was to show practitioners how to build GTM systems with Clay, step by step.

But my stack kept evolving and I also started to realize I was falling behind with other tools. So the last 4-5 months, I’ve been spending all of my free time learning, tinkering, and discovering what’s possible.

Claude replaced ChatGPT for most of my reasoning work. I started integrating Claude directly into Clay workflows instead of treating AI as a separate layer. I picked up Lovable for front-end builds. Learned Supbase. Claude Design. And, started building agents and workflows with Clay in the backend for infrastructure and building apps on top..

The Clay-centric newsletter got too tight. And the deeper problem was that I wasn’t really posting only about Clay anymore on the newsletter and on LinkedIn — I was writing about GTM Engineering as a practice. Org design. Hiring. The evolution of the role itself. How to combine tools into systems that actually compound.

Meanwhile, the “claymation” branding had started to feel like a cartoon and it not representing vibes of a newsletter that a CRO forwards to their team.

So: claymation.io is gone. This is GTM/Engineering: gtmengineering.ai.

What “GTM infrastructure” actually means

Clay as GTM Infrastructure is the growing mental model of what Clay is and where its going.

For most teams, Clay is still thought of as an enrichment tool. You use it to enrich the CRM, build outbound lists, score inbound leads. Those are real use cases. Unfortunately, it’s also the ceiling of what most people build.

But when you start treating Clay as GTM infrastructure (the data and automation layer that other things plug into) the surface area of what you can build expands dramatically. Territory management apps. Account health dashboards. Signal-triggered workflows that route leads before a human ever touches them. Qualification logic that talks to your CRM and your data warehouse simultaneously.

GTM Engineering job postings grew 5,205% year-over-year in 2025 (stat from the State of GTM Engineering). That’s not because more companies need better enrichment tables. It’s because companies are starting to understand revenue teams need their own engineering department.

GTM needs to be thought of as a product, or set of products, that are engineered.

Engineering requires the right building blocks.

Clay is the infrastructure that provides the later.

On the roadmap

There’s more coming that’ll make this more than just a newsletter.

My goal is this becomes the ultimate resource for GTM Engineering and those that want to build a career around it.

Where are you in the GTM Engineering evolution?

Ask your team to describe what your GTM Engineer does in one sentence.

“Manages our Clay instance and outbound sequences” is workflow thinking.

“Owns the data layer our revenue motion runs on” is infrastructure thinking. Same person, same tools, completely different ceiling.

Most teams are thinking in workflows.

The need to be thinking more like a product team using a new set of infrastructure primitives.

Let’s close that gap and inspire a new era of GTM.

GTM Engineering is still being defined. I’m one of the people trying to define it.

What you’ll find here: how these tools work as a system, how GTM Engineering teams get built, what AI in GTM looks like operationally, and the technical skills that are starting to matter.

Written for the people building it and the leaders deciding what to bet on.

Welcome to GTM/Engineering.

— Alex

Connect on LinkedIn

p.s. I’d love to share insights and builds from all of you. Just hit me up and throw me a pitch.

Subscribe now