The most AI-pilled growth teams I know are starting to rebuild their entire GTM stack. Some of their old tools aren’t making the cut.

Software that used to require its own interface and subscription is increasingly becoming something an agent can do with the right data, instructions and access.

Small and medium businesses are actively trying this. Larger companies have contracts, integrations and years of operational habits to work through. There’s always one workflow that only three people understand, and one of them left in 2023.

My bet is that agents will also make the migrations easier, which will lower the cost of switching. But we’re at different stages depending on which part of the stack you look at.

I wrote about this on X. Here’s the progression I’m seeing, with examples of what people are actually doing.

Your website becomes something the whole team can ship

We churned Webflow and rebuilt our website using coding agents earlier this year.

Since then, running PLG experiments, building programmatic SEO pages and shipping changes has become much easier. The speed and level of control are hard to give up once you’ve experienced them. Everyone on the team is shipping code.

Visual builders made websites accessible to people who couldn’t write code. Coding agents are making the code itself accessible to those same people.

Read that again.

The progression looks like this:

  1. You operate the website builder. You learn its editor, templates and limitations. Bigger experiments still need a developer or a workaround.
  2. You give an agent access to the code and content. The team describes a change, reviews it and ships it. The website can share infrastructure with the product.
  3. You connect the whole experiment. Research, page creation, publishing and measurement become a process the team can run repeatedly, with people reviewing the parts that matter.

This is what that looks like for us: website feedback in Slack becomes work our assistant can turn into a pull request.

Anita asking teammates for website feedback in Slack and explaining that Ava will open a pull request from their comments
From our Webflow migration: teammates leave feedback, and the assistant helps turn it into a website change.

I’m seeing teams explore headless setups with tools like Sanity, alongside newer agent-native website products like Ploy. Ploy’s site builder documentation describes creating pages through chat, using reusable sections and a shared design system. That’s a concrete example of the direction I mean.

And yes, Webflow is moving toward agents too. This isn’t a prediction that every website builder disappears. I care about whether the team can ship the experiment it wants without waiting for a platform to support it.

You probably know this, but your growth team having ideas was never the bottleneck.

The GTM engineer can rebuild their own enrichment stack

Clay helped popularize the GTM engineer: someone who understands data, enrichment, workflows and the commercial outcome they’re trying to produce.

That person is also unusually well equipped to replace parts of Clay.

They understand the logic behind a waterfall. They know which data sources matter, how to handle missing fields and when a result needs another lookup. With a coding agent, they can turn that knowledge into a pipeline they own.

This is already showing up in firsthand accounts:

Firecrawl is another example of the infrastructure moving in this direction: its web data tools and Alexandria put more sources within an agent’s reach. That doesn’t automatically make every replacement cheaper. You still need to count the data bill, model usage and maintenance.

For a useful discussion of the tradeoff, watch Finn Thormeier’s interview with Patrick Spychalski of The Kiln. Patrick describes startup GTM engineers building their own infrastructure, while making the point that reliable enrichment still needs predictable code around the agent. The transcript is here.

The state of GTM engineering’s leading edge, with The Kiln’s Patrick Spychalski. A useful discussion of where custom code helps and where Clay still earns its place.

Clay deserves credit for adapting quickly. But it helped train a generation of people to think in systems, and those people can now build more of the system themselves. Quite the plot twist.

Some workflows are becoming files

n8n and Gumloop still have a useful role. Plenty of business processes need visible state, retries, shared access and someone who owns the thing when it breaks.

But for some tasks, a well-written skills file inside an agent gets you surprisingly far.

We use this approach ourselves. In my write-up of our agent-led growth experiments, I describe a reusable writing skill that carries the research process, source requirements and review checks. The process becomes something you can inspect and improve.

Anthropic’s Agent Skills explanation describes the same underlying idea: package instructions, scripts and resources so an agent can load the expertise it needs. A skill can call ordinary code for steps that should behave consistently.

Take inbound lead qualification. Here’s what that progression could look like in practice:

  1. Build the workflow. A demo request comes in. Look up the company, check its size against your ICP, create a CRM record and notify the right rep. You wire up each step and its fallback.
  2. Turn the playbook into a skill. Give the agent your qualification criteria, a few examples and access to the relevant tools. Ask it to qualify a lead, explain its decision and draft a handoff. It can investigate missing information instead of stopping at an empty field.
  3. Give it ongoing responsibility. Ask the system to keep qualified inbound leads from going unanswered. It checks for unassigned requests, prepares follow-ups and flags stuck handoffs. You set approval rules and measure response time and conversion, then review what it should change.

Hone is exploring that third stage. Its launch write-up describes persistent systems assigned a goal, connected to company context and expected to keep working toward it. Its public onboarding process includes testing against historical work before live execution.

Hone’s full public demonstration. This shows the product’s approach, rather than an independently measured customer result.

I think Hone is going after the reliability problem with simulations and replays. In their research write-up, they describe finding issues in recorded runs, replaying the actions, proposing a fix and testing it in simulation before promoting the change. They simulate responses from people and connected tools, so the system can check what its changes might break. Across 125 scenarios, they report that replaying changes before promoting them cut regressions from 33% to 5%.

That’s the part I find interesting: giving the agent a way to test its own improvements before your live pipeline becomes the experiment.

“Get us 30% more sales” is an exciting brief. It’s also an excellent way to discover how poorly you’ve defined a qualified lead.

Search is becoming an evidence problem

Your website increasingly has another reader: an agent deciding whether your product belongs in an answer.

That makes the substance of your public content more consequential. Can someone establish what your product does, who it serves and why they should trust it?

For me, the progression is:

  1. Publish pages that answer the questions buyers ask. You need useful, findable content in the first place.
  2. Make your claims easy to check. Add documentation, real examples, comparisons, benchmarks and case studies. Specifics give both people and AI systems something to work with.
  3. Measure where you appear and fix the gaps. Look at the answers and sources being surfaced, then improve the missing or unclear information.

This doesn’t mean abandoning SEO for a secret GEO ritual. Google’s own guidance says its AI search features still rely on foundational SEO and helpful, reliable content. Important information should be available as text, and structured data should match what people can see.

I’ve liked using Gauge, but I think the strategy matters more than the monitoring tool right now. Tracking mentions can show you a gap. You still need to create something worth citing.

I wrote more about this in Make products AI agents want. My working assumption is that useful evidence will travel further than another page that says we’re the leading, innovative, next-generation solution. We’ve all read that page. None of us remember the company.

CRM will move more slowly

CRM has deeper roots than most of the rest of the stack. It contains account history, permissions, reporting conventions and processes people have built their jobs around.

The progression I expect here is more gradual:

  1. Read from the existing CRM. Give an agent access to account and deal context. Ask it which opportunities have stalled or what changed after the last call.
  2. Let it prepare and update work. Draft follow-ups, propose next steps and update records, with the right review and permissions. The team keeps its current system while changing how it uses it.
  3. Reconsider the underlying system. Once agents are doing more of the work, ask whether the data model and integrations support them well enough. That’s where a replacement becomes more interesting.

Lightfield is a concrete example of a CRM being designed for this. In its API announcement, it describes humans, internal agents and external systems working through the same core objects. Its current MCP documentation includes both reading workspace data and writing records.

That’s product evidence of the direction, rather than proof that every company is ready to migrate. I’d expect many teams to change how they work with their CRM before they change the CRM itself.

You probably know this, but nobody wants to migrate a CRM for fun. The new setup has to earn the disruption.

Growth teams will own more of the implementation

The common thread across these categories is how much a small growth team can now build and maintain.

My advice would be to start with the thing that keeps slowing you down. A website change that takes a week. An enrichment workflow you understand better than the tool does. A report someone rebuilds every Monday.

Try rebuilding that one piece. Count what it costs to run, check the output and see whether someone else on the team can use it. If it works, keep going.

Please don’t cancel twelve subscriptions on Friday and discover on Monday that you’ve become the support team for twelve internal products.

Growth is becoming an engineering problem. More of us can now do the engineering.

That’s going to make the next round of SaaS renewals very interesting.