What Is Agent-Led Growth in SaaS?
PLG solved distribution and left onboarding untouched. Agent-led growth is the attempt to fix what happens after signup — and most of the industry is defining it one layer too shallow.
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 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.
So it repeats itself.
So the next step knows about the last.
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.