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