Building products is like playing Tetris or, even worse, Flappy Bird - you start, and everything goes smoothly for a short period of time, but then it gets harder and harder, and you fail almost all the time. It’s frustrating, but it’s also so addictive. You can’t stop.

Over time, you pick different tools, frameworks, ideas, and experiences, hoping they’ll help you go further than before. You keep what works for you and shape it to your specific problem.

To make the game even harder, everything around you also changes all the time. It’s like playing Tetris while crossing the street in Vietnam, or somewhere else with thousands of bikes zooming around.

Product-led growth (PLG) is one of the best ideas bootstrapped products often pick up. It’s one of those things that sound completely logical when you first hear about them. Of course, it should work like that! Like most of the best ideas, it sounds simple! It’s one of those things that makes you ask yourself, “How did I never think about that before?” But then, when you start, you are quickly reminded that simple things are often not easy.

Let’s say you managed to shape PLG the way it works for you. And everything seems perfectly balanced for a few moments. But then AI agents entered the stage and started changing how we discover new products. If you work on a product right now, you probably do not need to imagine anything.

Product-led growth for humans

I don’t think I can write anything here that you don’t already know or that your AI agent can’t explain better, so I’ll keep this part short.

And, in short, the main idea of Product-led growth is that your product is selling itself. This might sound weird if you’ve never worked on a bootstrapped or underfunded product, but it’s the only way unless you have a budget to start a sales motion. That doesn’t mean the product should automatically do cold emails or cold calls (though I am not 100% sure whether a “sales AI agent” product that sells itself is sales-led or product-led growth). Instead, the idea is to give some value for free (either via a freemium plan or a generous free trial), then wait for people to have the “Aha!” moment (realize the value of your product) and upgrade to paid plans.

Sales-led vs Product-led acquisition process

The diagram above presents PLG as a clear winner. But it’s not. There’s no universal solution for all apps. Sometimes users expect a sales process. Sometimes the app is too complicated for customers to set up on their own. Sometimes you might have everything perfect on paper, but you don’t have the product-market fit you expected (e.g., you waited a bit longer, and the idea expired). However, in many cases, it’s a pretty good fit and often the only option for bootstrapped products.

Changes in product discovery and expectations

Let’s say you did everything right, and PLG works for you. And our product lived happily ever after, right? Well, if many other stars align, yes. Until it starts to fail.

As I mentioned at the beginning, we don’t play this product game of Tetris in isolation. The world around us changes. Sometimes these changes affect us and our products, and sometimes they don’t. And a lot has happened in the past 6 years. Remember COVID?

But many of these things affected how companies and people make decisions because of fear or economics. But the new wave we are riding right now is slightly different: AI agents are now real. Looking at Alexa and Siri less than a decade ago (or even today, they are still unusable) makes the AI agents we use today pure science fiction. But they are not!

So, what changed?

If you have a problem today, instead of reading Reddit and other reviews, watching demo videos, and spending hours trying out different products, you ask your AI agent to find a solution. And the solution varies between building a custom app just for your problem, suggesting you purchase and start using an existing product, or making you reconsider your whole life and existence. These potential solutions are mostly affected by the AI agent and model you use, your communication style, and the perception of the problem/solution complexity.

In short, AI agents are either your undercover sales agents or your worst competitor.

Product discovery process options with AI agents

We used Search Engine Optimization (SEO) for Google and humans; are Answer Engine Optimization (AEO) and Generative Engine Optimization (GEO) the solution here? They help with discovery, but they are not a complete solution.

What if, in addition to optimizing our marketing websites for AI agents, we also rethink our product-led growth strategy to make AI agents actual users of our products?

Product-led growth for AI agents

I don’t search for new products the way I did in the past. Unless someone I trust gives me a really strong recommendation, I start by chatting about the problem with Claude, Grok Bot, or, in some cases, ChatGPT.

Sometimes, I end up looking for and trying new products. You probably do something similar. Most people around the world do something similar or, if they aren’t already, they’ll start doing it soon. In many cases, they won’t even use English.

AI agents are great at explaining product features (only if products explain their features clearly) and collecting reviews and general feelings about certain products online. They are also good at exploring different scenarios with us, but only based on the actual information available and discoverable online. E.g., if your product has a feature someone needs, but you do not explain it clearly in a way that an AI agent can find it, it won’t mention it, or, even worse, it’ll tell a user confidently that your product does not have that feature. We had a similar problem with humans, and we tried to solve it with SEO by publishing many different variations of landing pages for each term users search for. Yes, Claude Code or Codex can do that for you, but so many people have already tried automating it that Google changed its algorithm and started penalizing it.

But AI agents are no longer just plain LLMs that are great at generating text. They can use tools, such as browsers!

What if you let AI agents try your product and, instead of a theoretical solution, provide verified value to a user?

For example, I need an analytics tool that tracks individuals and groups in my B2B app. My AI agent signs up for PostHog, verifies it can solve my problem, sets up what it can in the free mode, and tells me I need to enable the group analytics add-on; I take over, enable the feature, and it continues setting up the full flow. This is a hypothetical scenario, but not an unimaginable one. I have a working example below. Also, Netlify and similar tools have been doing something similar for a while now (some AI agents can deploy apps to these services without human intervention).

Product-led growth for AI agents

AI agent as a user

Most of our products are built for people. Even when we sell APIs, we expect a human with email access (or a social sign-in). We also often assume that a user will have access to a credit card. That makes sense, because we want to earn money in the end. And we want real users, not spam bots.

But not all bots are spam bots anymore. Or at least some are less spammy and much more useful now.

Our apps are made for people with email addresses, and we often block temporary email addresses in the signup flow, so AI agents can’t easily sign up and become regular users today. Some creative people gave their OpenClaw, Hermes, or Grok bot agents access to a dedicated email address to solve this problem. But that does not solve the problem in all cases. However, we can also solve this problem directly in our products.

Two main blockers for agent signups today are our authentication and authorization layers and protecting our products from agent abuse (or stopping data/value extraction and freeloaders).

The first is solvable at many different levels. For example, you could do this by introducing an agent user with specific permissions; an agent signs up, and the user then takes over the account through a predefined process (e.g., a claim/magic link, etc.). Or, you could fake the signup and give an agent a real token and access to a freemium or trial account; then the account claim process sets up the user’s real email and resets the password or sends a magic link. Or, since AI agents don’t need a fancy UI, you could give them API access only, if possible. There are countless ways, each with pros and cons specific to your product.

The second blocker is even more important, and there’s no easy solution. AI agents do not have a permanent identity. If you try to limit them by IP address, you might end up blocking Anthropic’s or OpenAI’s data center. But you need to limit them, because otherwise they could sign up many times and abuse the app in many ways (some people use AI agents in very creative ways).

Each potential solution has limitations, and the answer is probably a combination of several. But the most important limitation you need to introduce is preventing AI agents from running expensive operations with temporary accounts. For example, you don’t want to allow an agent to deploy complex infrastructure or to use operations that use an LLM under the hood.

Let’s say you solved both of these problems. How do you push AI agents to sign up when they visit the website?

An obvious solution is to tell them on your landing pages. Publishing clear instructions for agents on how to create accounts and test the app should be sufficient for modern agents. They are good at reading instructions, and sometimes they even follow them.

What about MCPs? Could they help?

You probably already have an MCP server. If you don’t, I recommend adding one, as people use them more and more. But the problem with MCPs is that a human needs to install and authorize them, which defeats the purpose of product-led growth optimized specifically for AI agents. However, there’s a special kind of MCP you don’t need to install and pre-authorize: WebMCP.

WebMCP

As with most of the things Google Chrome has shipped lately, WebMCP is a proposed web standard implemented only in Google Chrome and Chromium. But the concept is quite interesting: instead of letting an agent simulate a human and click and scroll around the page, you define MCP-like tools that an agent can use on your website, without authorization. For example, instead of finding a search box, focusing the input field, typing, and then submitting the form, an AI agent uses the search WebMCP tool to search your website.

It’s probably best to show an example:

await document.modelContext.registerTool({
  name: 'search_site',
  description: 'Search this website\'s pages and articles. Returns the top matches with titles, URLs and short excerpts.',
  inputSchema: {
    type: 'object',
    properties: {
      query: { type: 'string', description: 'What to search for' },
    },
    required: ['query'],
  },
  annotations: {
    readOnlyHint: true,          // search never changes anything
    consequentialHint: false,    // safe for the agent to call freely
    untrustedContentHint: false, // results are our own content
  },
  execute: async ({ query }) => {
    const res = await fetch(`/search?q=${encodeURIComponent(query)}`);
    const { results } = await res.json();
    return results
      .map((r) => `${r.title} — ${r.url}\n${r.excerpt}`)
      .join('\n\n');
  },
});

So, you define a tool with a clear name and description (when an agent should use it), input parameters (properties), and a function (execute) that runs when an AI agent uses the tool. The execute function has the parameters that you defined in the properties section, and it’s just a simple JavaScript function, which means you can do anything you want inside it.

WebMCP can also do a few other things, such as helping users fill out forms. Check this guide for more details: https://developer.chrome.com/docs/ai/webmcp.

This sounds simple, but how do you use WebMCP? This was what blocked me from exploring them for a long time; I didn’t understand their value. But the answer is straightforward: you don’t! They are not built for us. They exist for our AI agents. Any agent with access to a real web browser can use them today (e.g., Claude Cowork, ChatGPT Work, Grok Bot, Hermes, etc.).

By building a WebMCP, you expose an AI agent-friendly interface on your website. Instead of clicking around, they can use what they are best at: words.

WebMCP

You might ask: How does this help with product-led growth for AI agents? It does! Because instead of a detailed explanation of how machines could sign up for your product, you could build a WebMCP and tell them to use it.

However, “AI agents could sign up on their own” is not the same as “AI agents sign up on their own,” and while everything I described above can be implemented today, it’s not a magical growth channel that will solve all your problems. But things often look like crazy hacks and unnecessary overengineering until one day they don’t, and until your users expect them. It’s not hard to imagine agents being regular users of our apps in the very near future, so why not prepare everything for them today?

Competitor Tracker example

As you can imagine, I tried this before writing this article, and WebMCP and agent signup are available for Competitor Tracker & Co. (https://competitortracker.io); instead of just showing you the result, I’ll walk you through my process of adding this capability.

Competitor Tracker & Co. is another product my cofounder, Lav, and I are working on. It’s a tool that monitors your competitors, filters the changes you should care about, and emails you every Monday morning. It’s built for humans and their AI agents, and that made it a perfect playground for this experiment. If you want to read more about it, see my previous article.

I gave myself one afternoon to implement this. It’s a relatively short period, but in an early phase of the product, I don’t want to waste days on experiments.

I started by defining what an AI agent can do once they sign up. Tracking a few competitors and listing the key changes they made recently would be the best way to show the value. However, tracking a competitor we’ve never seen before involves a bunch of LLM calls in our system (the expensive action). It also takes at least 15 minutes (we pull a current version and a snapshot from the Web Archive from a few months ago, then compare them and filter changes). An AI agent doesn’t want to wait 15 minutes, and I don’t want to let an AI agent run expensive actions. But what’s the other option?

We track more than 3000 companies, mostly for marketing and archiving purposes. We use these as a source for our Quarterly Industry reports (not all of them are published yet). We have already paid for LLM calls for these companies, and we picked popular companies and industries. Allowing an agent to track any of these would be almost free and instant (changes are already in our database). So, I decided to allow up to 3 competitors from our list.

The next step was an agent signup. Everything in Competitor Tracker & Co. is available through the API, so the API was a natural place for the agent signup. The signup process is described in detail here: https://competitortracker.io/docs/agent-signup/. Once the agent signs up, it can list the changes (get a value from our product) and provide a “claim the account” link to a human. If no one claims the agent account, we delete it in 4 days.

Finally, it was time for a WebMCP. I added 10 read tools (5 for website navigation and 5 for exploring the data section that we publish) and a tool for signing up and tracking competitors. Here’s the “signup and start tracking” tool:

import { registerTools } from './register.js'; // probes document.modelContext ?? navigator.modelContext

const API_URL = 'https://api.competitortracker.io/v1/agent-signups';

registerTools([
  {
    name: 'start_tracking_competitors',
    description:
      'Set up competitor tracking for the person browsing this page, before they have an ' +
      'account, and hand them a link to take it over.\n\n' +
      'Name the companies they care about, by name or by domain. We match them against the ' +
      'companies we already track and the first three you list go on file, with their change ' +
      'history readable straight away. We do not fetch an address you supply: a company we do ' +
      'not track yet comes back in shortfalls, which is not a failure — it is something the ' +
      'person can add themselves once they have claimed.\n\n' +
      'Nothing is charged to anyone, no email is sent and the organization is removed after ' +
      'four days unless someone claims it. The claim link comes back in the response and ' +
      'travels no further, so show it to them and tell them what went on file and what did not.',
    inputSchema: {
      type: 'object',
      properties: {
        companies: {
          type: 'array',
          items: { type: 'string' },
          minItems: 1,
          maxItems: 20,
          description:
            'Company names or domains, in the order they matter to the person the agent ' +
            'is acting for. Order is preserved and decides which three go on file first.',
        },
      },
      required: ['companies'],
    },
    async execute({ companies }) {
      const list = companies.slice(0, 20).map((c) => String(c));

      let res;
      try {
        res = await fetch(API_URL, {
          method: 'POST',
          headers: { 'content-type': 'application/json' },
          body: JSON.stringify({
            companies: list,
            // A tag on the claim link back to where the ask came from — never a credential.
            sessionId: `webmcp-${crypto.randomUUID()}`,
          }),
        });
      } catch {
        return {
          status: 'network_error',
          message:
            'The request never reached the API — nothing was created and nothing was ' +
            'judged missing. This says nothing about which companies are tracked. Try again shortly.',
        };
      }

      const body = await res.json().catch(() => null);

      // Transient read failure. MUST NOT be rendered or spoken as "we don't
      // track that" — nothing was created, nothing was judged missing.
      if (res.status === 503 || body?.status === 'catalog_unavailable') {
        return {
          status: 'catalog_unavailable',
          message:
            'The company catalog could not be read just now. Nothing was created and ' +
            'nothing was judged missing — do not tell the person any company is ' +
            'untracked based on this. Try again shortly.',
        };
      }

      // Restate, don't summarize: the body travels whole, with reading
      // guidance layered beside it rather than over it.
      if (res.ok && body?.status === 'created') {
        return {
          ...body,
          how_to_read_this: {
            subscribed: 'What actually went on file — change history is readable straight away.',
            shortfalls:
              'What did not go on file, and why: "unpublished" means not in the published ' +
              'catalog yet (addable by the person once they claim — not a failure); ' +
              '"over_cap" means beyond the first three listed.',
            claim: 'Show claim.url to the person and tell them what went on file and what did not. The link travels no further.',
            expiry: 'Unclaimed organizations are removed after four days. No email was sent, nothing was charged.',
          },
        };
      }

      return {
        status: 'error',
        http_status: res.status,
        body,
        message: 'Unexpected API response. Nothing should be assumed created; the person can sign up at /pricing/.',
      };
    },
  },
]);

It’s not perfect, and it’s mostly AI-generated with just a few minor modifications. But it’s good enough to test this hypothesis.

So far, signups haven’t exploded, but that’s expected as Competitor Tracker & Co. is still in its early phase.

Here’s a short demo video:

What’s next

AI agents have changed the way our users search for products. My current hypothesis is that our apps now need to evolve so that AI agents can sign up and show users the value of our product before they even visit our app. This looks like a natural extension of the current state of product-led growth: provide value in minutes, then let an AI agent sell the “Aha!” moment to the user. Combining APIs, MCPs, and WebMCPs can help us accomplish that.

I’ll probably test this hypothesis in a slightly different shape in other products we are working on.