Agents can do real marketing and sales work now. That changes what belongs in your stack. It’s a new build vs buy dynamic: which agents to “hire,” and when to build your own. When you build, there is an exciting new class of GTM Developer Tools to help.

I’ll be presenting these frameworks on stage at Apify RUN in San Francisco on November 10. I’m on at 2:30pm. Use code ADAM50 for 50% off. I’d love to see you there!

“We’re going to build it ourselves.”

In my time selling GTM tech, I’d occasionally hear a prospect talk about building themselves. When I did, I laughed it off.

The GTM tech stack was always about buying and integrating vendor platforms. When I co-founded Simply Measured (social analytics) in 2010, when I grew Siftrock (email tools) in 2016, and when I was at Drift in 2018, we assumed “buy” was the default. When a buyer said they’d build it, they’d be back a few months later to buy a subscription. Building was harder than it looked. Buying worked.

When I launched Keyplay in December 2022, I assumed that dynamic would continue.

Man, was I wrong.

It crept up slowly at first, then fast. By 2024 I was hearing “we’re going to build it ourselves” often. In 2025 it felt like the default posture for forward-thinking companies.

It was GTM Engineers with Clay, Claude Code, and a stack of API-first tools at their disposal. This time they could actually deliver.

I saw this as existential for Keyplay.

When I turned my focus to Adam’s GTM Report, I decided that I too would embrace a builder mentality. Around October of last year, I went all-in learning coding agents and how to apply them across marketing and sales.

Now I look at GTM problems and think “I can totally build this myself.”

So what does this mean for the GTM stack? Two frameworks help me think about it:

The pre-agent GTM stack worked in a predictable way for 20 years.

You’d identify a problem, explore vendors for that problem, and figure out how they all integrate. RevOps and MOps teams would administer each tool and try to make the stack do everything you needed. They’d work within the confines of a vendor’s design and then bring in more solutions to fill the gaps.

Buy a vendor, integrate it, hire an admin to run it. Repeat. A bunch of roles became vendor managers and process managers. The typical seller or marketer was kinda like human middleware.

14 browser tabs. Clicking around. Copy and paste. Tons of hours using the tools rather than connecting with customers or creating unique campaigns.

Marketing and sales tech proliferated in this world. For a while people even showed off their stacks. Remember the Stackies?

Awards for martech stack diagrams. It felt like a game to see who had the craziest setup.

AI changed what software could do.

First it was chat. You asked a question and got an answer. Then tasks: write this email, research this account, summarize this call. Now it’s work.

Agents run multi-step jobs on their own and come back with the result. In 2025, METR found the length of tasks AI agents can finish had been doubling about every seven months for six years.

GTM was slow to get there. All year our space felt so far behind coding, legal, and customer support.

AI SDR was the first big swing. The first wave went after outbound and didn’t deliver. Now a second wave is building around inbound. Vercel’s agent took inbound qualification from 10 people to about 1.25. Then came the AI-native CRMs like Lightfield, built “for companies that run on agents.”

Agents can do real marketing and sales work now. That changes what belongs in your stack.

Most of your GTM stack was built for people clicking around in browser tabs, not for agents.

For the pre-AI vendors, that means moving toward two valuable positions:

New startups are launching on both sides as well. I call this the AI x GTM Tech Triangle.

This is the lens I now use to think about every product in the GTM space. The higher a product sits, the more agent-native it is. The big players are moving on both sides (eg Salesforce, HubSpot, Clay, ZoomInfo).

For buyers, it’s the new build or buy. You’re not vibe coding SaaS apps. You’re considering which agents to “hire” and when to build your own agents, skills, or agentic workflows to solve the problem. I don’t see any buyers getting excited about SaaS 2.0 with AI bolted on. The interesting opportunities are on the edges.

Coding agents aren’t the only reason the “build” path is getting more exciting. We’ve also seen the rise of agent-ready GTM Developer Tools. This means you can build the system (agent or agentic workflows) and buy the Legos.

I used to see tools like Apify, Exa, and OpenRouter as Dev Tools. Not for me, not for GTM. Now my agents call them every day. I’ve been mapping GTM Developer Tools since June.

For two decades we picked GTM software on usability. Nice UI, easy onboarding, good G2 reviews. Agents are users now and they don’t care about that stuff. They care about what they can call easily to get the job done.

To me, Apify is the prototype for what a modern GTM developer tool looks and feels like. It’s a marketplace of over 100,000 tools that agents can choose and call. It has the right pricing model: pay as you go, and agents can now pay per run. And it has all the right interfaces: API, MCP, CLI, and agent skills.

You can see the shift in job posts. Vanta wants an AI GTM engineer with “a clear ‘build vs. buy’ perspective.” Nooks wants a Director to “set the build vs. buy strategy for the revenue tech stack.”

I’m not an engineer. Not even close. I didn’t have a GitHub account until January. But these days I’m building a lot.

When I say I’m building it myself, I don’t mean “I need lead routing, so I’ll rebuild LeanData.” Or “I need a calendar tool, so I’ll rebuild Calendly.” I start with the problems and needs I have. The solution is often an agentic workflow or set of agent skills.

In my single-person media and advisory business, audience management is a big surface area. Instead of buying SaaS tools, I built a night-shift agent that runs my audience ops. One of the workflows starts with everyone who liked or commented on my LinkedIn posts. Apify collects them. ZoomInfo fills in titles and companies. Then my system keeps the people who fit my ICP and don’t subscribe yet, and syncs them to Primer for LinkedIn ads. On October 21 that was 3,199 people in, 386 out. Claude Code and Codex built it with me. It runs every night and I never log in to the tools.

I didn’t buy a tool for this. I built the system and bought the Legos. I still check the work, but I don’t need to manage it.

My test for any new tool: can my agents connect, manage it, and use it to serve my goals? I think more and more GTM tech buyers will ask this question.

That changes the work for people too. GTM engineers and marketing engineers build, manage, and improve these systems. Creative and strategic people tap into them to get massive leverage.

I think of it as a barbell. And you can learn to work on both ends. That’s what I’m doing in my own business.

You don’t have to start as an engineer. I didn’t. These things can be learned.

“We’re going to build it ourselves.”

Now I hope more GTM teams adopt this mindset. Not for everything. There are some amazing vendors out there. In many, you should buy. But you can now cover way more problems by building your own agents, skills, and workflows.

This can often be done with minimal technical skills.

So I’d encourage marketers and GTM leaders to lean into building at some level. Pick one problem or opportunity that you know well. Give an agent a small piece of it, check the work, and iterate. Then ask the agent to turn it into a system that runs on its own.

And if you’re technical, help someone else take that first step. Often they just need some basic setup and permission to experiment.

I’m going to be speaking on this exact topic at Apify RUN in San Francisco on November 10. I’ll get deeper into the frameworks on stage. If you’re there, come say hi.

What are you building? I read all replies.