Agent-Led Growth — Issue 01
If you’ve spent any time in SaaS go-to-market circles this year, you’ve heard the term: Agent-Led Growth. It’s being positioned as the successor to Product-Led Growth, the way PLG replaced sales-led motions a decade ago.
There’s no accepted definition yet, which is part of the problem. Here’s mine — and why the conversation is still one layer short.
The Core Idea
PLG made the product the engine. Sign up, try it, find value without a rep.
Agent-led growth is the layer on top. Instead of the user learning the product well enough to reach value on their own, an agent inside the product works out what they should do next and either shows them or does it for them.
The product should be doing the work of understanding the user and telling them what to do next — not the other way around.
The output is one next best step, personalised to that user. Getting it right means grounding it in three streams, not one:
What they do in the UI — the screens they open, the actions they abandon.
What they say in the chat — the questions they ask, and the ones they ask twice.
What the agent does for them — what it suggested, what it did on their behalf, whether it landed.
Hold all three in one place, and you can answer the question that actually matters: given what this person has done, and what they still haven’t, what’s the one thing to put in front of them next?
Why “Self-Serve” Stopped Being Enough
PLG solved distribution. It never solved what happens after signup. Complex B2B tools still hand a new user a dashboard, a settings menu and a blank canvas, and call that self-serve.
At Autoplay we think of it as three walls every user hits:
They don’t know what they don’t know. They’re not sure what to ask, or which part of the product matters to them.
They don’t ask for help when they’re stuck. The friction never surfaces, because nobody on your team knows it’s happening.
They only want guidance that’s relevant to them. A tour that ignores their goal and their progress isn’t help. It’s noise.
Static onboarding hits all three at once. Documentation nobody reads, videos nobody finishes, tours that walk every user through the same steps. It’s built for the average user, and the average user doesn’t exist.
What Actually Makes Onboarding Agent-Led
The label gets applied loosely — usually to a chatbot bolted onto a legacy UI. Three things have to be true at the same time.
It has to be grounded in the whole context. Account fields — plan tier, signup date, company size — are guesswork. But live UI behaviour on its own is only a third of the picture. Without the agent’s own history, it can’t tell a step someone skipped from a step it completed for them.
It has to know what “done” means for that user. Onboarding isn’t one checklist; different users need different subsets of it. The agent needs to know which workflows are finished — by the user’s hand or its own — so it isn’t re-explaining or skipping.
It has to turn that into one next step, at the right moment. Not a summary of someone’s activity: a single recommendation. And proactive help at the wrong moment reads as intrusive, so is now the right time has to be part of the system, not something bolted onto a chat prompt.
Miss one and you have a chatbot with better marketing. This is the gap agentic onboarding is meant to close.
Where the Conversation Is Still One Step Behind
Of those three streams, almost nobody builds the third.
The current excitement is about agents generating things for users — a dashboard, a report, a first draft. Useful, but it treats “the agent acted” as the finish line. It isn’t. It’s a new event in the user’s history, and the agent has to be able to read it back.
Without that, you get an agent that repeats a suggestion the user already dismissed, contradicts its own last recommendation, tells someone to go and do a thing it did for them yesterday, and can’t tell a helpful intervention from an ignored one.
Personalisation that reads user behaviour but never reads the agent’s own history isn’t closing the loop. It’s guessing twice.
What This Means If You’re Building
Behavioural context beats account context — and behaviour means all three streams. Plan tier tells you who someone is. It doesn’t tell you they’ve opened the integrations page three times, asked about SSO twice, and let the agent wire up Slack for them.
Completion state is per-user, and it counts both routes. A step the agent finished on someone’s behalf is done, even though they never touched that screen.
Agent memory is infrastructure, not a feature. Retrofit it, and you’ll be doing it the first time a customer complains the agent keeps repeating itself.
That last one is what I’ll cover next: what it takes to track not just what a user is doing, but what the agent has already done for them — and how that changes what it should suggest.
Agent-Led Growth: FAQ
What is agent-led growth? An AI agent inside the product does part of the work of getting a user to value — reading what they do in the UI, what they ask in the chat and what it has already done on their behalf, and using all of it to suggest their next best step.
How is it different from product-led growth? PLG made the product the acquisition engine but still assumed users would teach themselves. ALG adds a layer that reads live context and intervenes.
Is it just a chatbot in the product? No. A chatbot answers what’s typed. An agent-led system also sees what the user is doing, knows which workflows they’ve completed by either route, and decides when to step in.
Why isn’t account-level data enough? Plan tier describes who a user is, not what they’re doing right now. Friction happens at the level of a specific action on a specific screen — including one the agent took for them.
What does most of the industry get wrong? Treating the agent’s action as the end of the process. Without a record of what it suggested and how the user responded, it repeats itself and can’t tell useful help from ignored noise.
Want to see this working on your own product? autoplay.ai · Quickstart docs: developers.autoplay.ai