Agent-led growth is not a marketing term. It is an architectural decision — a claim that a product can acquire, onboard, and run on behalf of a client without a human sales motion and without the friction of self-serve. The question that follows that claim immediately is: what does the machine actually do, in what order, and where do the boundaries sit?
The answer is three phases. Acquisition, Activation, Evolution. Two of them happen to the client. One happens to the product. And the line between them is not obvious until you draw it wrong a few times.
Acquisition
Acquisition ends the moment the required inputs arrive. That is the boundary — not the first touchpoint, not the click, not the sign-up. The moment the client has provisioned whatever the system needs to run for the first time: that is where acquisition ends and everything else begins.
Which means acquisition is a constraint-satisfaction problem, not a marketing problem. Given that the product needs inputs X, Y, Z to run — how do you get them at the lowest possible cost and friction? The whole acquisition architecture reduces to that question. And because the answer has to be agentic, the acquisition surface is not a sales call and not a self-serve flow. It is a surface engineered so that the zero-risk action — the action that initiates the proof — is the natural next move for someone who recognizes the outcome.
The sequence inside acquisition is always the same: put the offer in front of the right person, capture the minimum required to provision, deliver the proof, present the zero-risk action. Four slots. If something does not serve one of those four, it is not acquisition — it is either product or noise.
Agentic acquisition — the automated deployment and self-management of those acquisition assets — is a later capability. The ads can be hand-built. The post-click can be automated. The product is still ALG, because ALG is defined by how the client is onboarded, not by who ran the campaign. Automating the campaign is an internal efficiency for year two. Do not conflate them.
Activation
Activation begins the moment the inputs arrive and ends the moment the system runs for the first time without asking for anything more. It is the app's first-run state — not a separate discipline, not a peer to the application layer. Activation lives inside the application, as a phase of it, because the application has to be built knowing that phase exists.
What makes activation feel separate is that it is the only part of the application that acquisition reaches into directly. The acquisition surface makes a promise — here is your detection result, here is what we found in your database, here is the outcome we can deliver. The application has to be able to honor that promise before the client has uploaded anything, before they have signed anything, before money has moved. That shared contract between acquisition and activation — the proof artifact and the zero-risk action — is the one place the two phases are not independent. Everything else separates cleanly.
Activation ends when the thing runs. Not when it is configured. Not when the client has been walked through a tutorial. When the first real run completes. After that, the system is in steady state — the campaign is live, the contacts are moving, the agent is working. That transition has a name: the system is running. Not maintained. Not in steady state. Running. The vocabulary matters because maintenance implies decay and steady state implies stasis. Neither is true. The system runs.
Evolution
Evolution is the third phase, and it has a different subject. Acquisition and activation happen to the client. Evolution happens to the product.
In a product built the way Tower is built — where the Register is the source of truth and the app is generated from it — a signal from a running client does not have to become a ticket in a backlog. It can become a change to the Register, propagate through the methodology, and regenerate. The feedback loop closes into the build process itself, not into a sprint queue. That is what makes evolution agentic rather than just shipping updates: the loop from observed friction to changed product runs through the same passes the original build did.
Which is also why evolution was never going to be a third A in the same family as acquisition and activation. Those two describe phases of a client relationship. Evolution describes what the product does with what it learns from all of them. Different subject, different axis, sitting underneath the whole system and running continuously.
Why the boundaries matter
The reason to draw these lines precisely is not taxonomic. It is operational. When you know where acquisition ends, you know what the product owes to the acquisition surface — specifically, what it has to be able to show before any inputs have arrived. When you know where activation ends, you know when a client is truly live and what running actually means. When you understand evolution as a separate axis, you stop waiting for a sprint cycle to close feedback loops that the architecture could close automatically.
Most products blur all three. The sales team makes promises the product cannot yet honor. Onboarding runs indefinitely because nobody defined when it ends. Product updates happen on a schedule that has nothing to do with what clients are revealing. The result is a system that is always behind its own claims.
Acquisition, activation, evolution. Two you build for the client. One you build into the product itself. Know which phase you are in before you decide what to build next.