Your Next Customer Might Be an AI Agent

The user signing up might not be a person

Your next power user might never see your UI. It authenticates through an API key, reads your docs as structured context, calls the endpoints it needs, and churns the moment a cheaper substitute clears the same task. It has no email to nurture, no seat to expand into, no colleague to invite. It is an agent, and product-led growth was not built for it.

This is the shift Elena Verna named when she asked whether MCP belongs in your ICP, and the one Kyle Poyar has been tracking as agentic customers move from novelty to line item. The provocation is simple. PLG 1.0 sold to individuals who brought the tool to work. PLG 2.0 turned that individual adoption into team and company expansion. PLG 3.0 has to serve a user that has no team, no company loyalty, and no patience for the parts of your product designed to convert humans. The playbook doesn’t extend. It breaks at three specific joints: pricing, distribution, and virality. One thing survives, and it’s the thing most teams underinvest in.

Pricing built for seats collapses when the seat is a script

Start with pricing, because it fails fastest.

Per-seat pricing assumes a human occupies the seat, uses the product some bounded number of hours a day, and expands as the org hires. An agent has no such ceiling. A single API key can drive the request volume of a hundred humans or one, and it can do it at 3 a.m. Charging that agent for a “seat” either underprices it into a margin sinkhole or overprices it out of the consideration set entirely. There is no seat to price.

The second implication is that usage-based pricing stops being one option among several and becomes the only model that survives contact with an agentic customer. If the unit of value is a completed task, the price has to attach to the task, the token, the call, or the outcome. This is not new advice for infrastructure companies. It is new pressure on the thousands of application-layer SaaS businesses that spent a decade convincing themselves per-seat was the durable model. Snowflake and Twilio priced this way from the start. Most app-layer products will have to retrofit metering they never built, and metering is hard to bolt on after the schema is set.

The third implication is the one teams miss. When the customer is an agent, price elasticity is instantaneous and total. A human tolerates a mediocre tool because switching costs are real: retraining, re-learning the UI, the friction of change. An agent has none of that. If your endpoint costs more than the next endpoint that returns the same structured result, the agent routes around you on the next call. Not next quarter. Next call. Pricing power in an agentic market comes from being the cheapest acceptable answer or the only acceptable answer. The comfortable middle, where most SaaS lives on the strength of habit and switching cost, is exactly where agents apply the most pressure.

MCP is a distribution channel, and most teams are treating it as a feature

The Model Context Protocol gets filed under “integrations” on most roadmaps. That’s the mistake. MCP is not a feature you ship so agents can call your product. It’s the surface where agents discover, evaluate, and select your product in the first place. Treating it as an integration is like treating your website as a feature in 2003.

Think about what the last three distribution surfaces actually were. Organic search rewarded the businesses that structured their content so a crawler could parse it and a ranking algorithm could trust it. SEM rewarded the ones who understood the auction. LLM-driven discovery rewards the ones whose information is legible to a model deciding what to recommend. The next surface is agentic: an agent, mid-task, deciding which tool to invoke. Being invocable is the new being findable.

That reframes the work. If MCP is distribution, then your tool descriptions are your landing pages. Your schema is your conversion funnel. The clarity with which you describe what your endpoint does, what it costs, and what it returns determines whether an agent picks you or the competitor whose description was easier to reason about. This is SEO for a reader that doesn’t skim and doesn’t forgive ambiguity. The teams that win the agentic channel will be the ones who treat their MCP server the way a growth team treats a signup page: as the highest-leverage surface in the funnel, instrumented and iterated, not shipped once and forgotten.

The viral loops that built PLG assume a human wants to look good

PLG’s growth engine ran on human social behavior. Someone invited a teammate because collaboration was the point. A document got shared and the recipient hit a signup wall. A “made with” badge sat in the footer and someone clicked it. Every one of those loops assumes a user who has colleagues, who cares about being seen using a good tool, and who responds to social proof.

Agents have no colleagues. They don’t share to collaborate; they share when a task requires it. They don’t click a “powered by” badge, because status is not a thing they have. They are immune to the entire class of growth mechanics that made PLG compound, which is most of them.

What replaces the invite loop is the recommendation loop, and it runs through a different mechanism. An agent that completes a task well remembers the tool that helped, and the orchestration layers above it, the model providers and the agent frameworks, propagate that preference. Winning here looks less like getting invited to a workspace and more like becoming the default tool a class of agents reaches for. That’s closer to a supply agreement than a viral coefficient. The compounding still exists. It just moves from the social graph to the reliability graph: the agent that trusts your endpoint routes more tasks to it, and that trust is earned by returning correct results cheaply and predictably, not by being fun to invite.

The honest counter here is that humans aren’t going anywhere. Most software will be bought and used by people for years, and the teams that abandon human onboarding to chase agents will lose the customers they actually have. That’s right, and it’s why this is PLG 3.0 and not PLG-instead-of-PLG. The human funnel stays live and supported. The point is that a second funnel is opening alongside it, with different physics, and the products that build for both will take share from the ones that pretend the second funnel is just the first with an API bolted on.

Trust is the one thing that doesn’t change

Everything above describes what breaks. Here’s what carries through intact, and it’s the reason to be optimistic rather than alarmed.

The thing that made PLG work was never the invite loop or the free tier or the per-seat expansion. Those were mechanisms. The thing underneath was trust: a user tried the product, it did what it promised, and that earned the next interaction. Compounding trust was always the actual engine, and the mechanics were just how trust converted into revenue for human users.

Agents run on trust more literally than humans ever did. A human forgives a flaky API because switching is annoying. An agent measures your reliability on every single call and reroutes the instant you fall below the bar. The product that returns correct results, at a predictable price, with a schema an agent can reason about, earns more traffic. The one that’s ambiguous, expensive, or unreliable gets designed out of the loop silently. There is no churn survey. There is just less volume, and then none.

So the strategic instruction is not “rebuild your product for robots.” It’s narrower and more demanding. Treat trust as the product, for both readers you have and the ones you can’t see. Instrument for a customer who measures you continuously and forgives nothing. Price for a customer with no switching costs. Distribute on the surface where that customer decides. The company that does this doesn’t just survive the transition to agentic customers. It gets a growth channel its competitors are still filing under “integrations.”